A record of processing activities (RoPA) and a data protection impact assessment (DPIA) are different documents with different triggers. A RoPA is an inventory: it documents all of your processing, it is maintained continuously, and it contains no risk analysis. A DPIA is an assessment: it applies only to processing likely to result in a high risk to people, it must be completed before that processing starts, and its whole purpose is to analyse and mitigate risk.
Most organisations need both, and they are not alternatives. The confusion is worth resolving carefully, because treating a RoPA as though it discharged the DPIA duty leaves a gap that only appears once something has already gone live.
The short answer
- A RoPA is required by Article 30 of the General Data Protection Regulation (GDPR). It covers every processing activity, it is a living register, and it must be available to a supervisory authority on request.
- A DPIA is required by Article 35, and only where processing is likely to result in a high risk to the rights and freedoms of natural persons. It is completed before the processing begins.
- The RoPA is where DPIA candidates are found. The register tells you what you do; the assessment tells you whether one of those things is too risky to start without safeguards.
- Neither document makes processing lawful. They evidence that you identified what you do and assessed what was risky.
What a RoPA is
Article 30 requires controllers to maintain a record of processing activities containing the purposes, the categories of data subjects and personal data, the categories of recipients, third-country transfers, retention periods where possible, and a general description of security measures. Processors owe a shorter, separate record under Article 30(2).
Three characteristics define it. It is comprehensive — it covers all processing, not a selection. It is descriptive — it states what happens, not whether what happens is acceptable. And it is continuous — the register is expected to reflect current reality, which is why Article 30(4) can oblige you to produce it at any time.
The field-by-field requirements are covered in what Article 30 actually requires, and the practical build in how to create a record of processing activities.
What a DPIA is
Article 35(1) requires a DPIA where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons, taking account of the nature, scope, context and purposes of the processing.
Article 35(3) names three cases where a DPIA is required in particular:
- a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects concerning the person or similarly significantly affect them;
- processing on a large scale of special categories of data under Article 9(1), or of data relating to criminal convictions and offences under Article 10;
- systematic monitoring of a publicly accessible area on a large scale.
Article 35(7) sets the minimum content: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to rights and freedoms, and the measures envisaged to address those risks, including safeguards and security measures.
Two consequences distinguish a DPIA from any other internal document. Under Article 36, if the assessment indicates a high risk that you cannot mitigate, you must consult the supervisory authority before processing. And under Article 35(11), you must review the assessment where the risk presented by the processing changes.
The five differences that matter
Scope. A RoPA covers everything. A DPIA covers one processing operation, or a set of similar operations, that crossed the high-risk threshold.
Trigger. The RoPA duty attaches to being a controller or processor at all, subject to the narrow Article 30(5) derogation. The DPIA duty attaches to a risk assessment you have to make first.
Timing. A RoPA is maintained on an ongoing basis and is never finished. A DPIA is completed prior to the processing, then reviewed when the risk changes.
Content. The RoPA asks what. The DPIA asks whether, and at what cost, and with what safeguards. A register that contains risk conclusions has drifted into being a different document; an assessment that only describes processing has not done its job.
Consequence. An out-of-date register weakens your accountability position under Article 5(2). A missing DPIA where one was required can mean the processing itself should not have started, which is a materially worse position to be in.
How to tell whether a DPIA is required
Article 35(3) lists three clear cases, but most real decisions sit outside them. Two further sources narrow it down.
The Article 29 Working Party's DPIA guidelines, WP248 rev.01, endorsed by the European Data Protection Board, set out nine criteria that indicate high risk:
- evaluation or scoring, including profiling and predicting;
- automated decision-making with legal or similar significant effect;
- systematic monitoring;
- sensitive data, or data of a highly personal nature;
- data processed on a large scale;
- matching or combining datasets;
- data concerning vulnerable data subjects;
- innovative use, or applying new technological or organisational solutions;
- processing that prevents data subjects from exercising a right or using a service or contract.
The working rule the guidelines offer is that processing meeting two of these criteria will generally require a DPIA, while in some cases one criterion is enough. It is a threshold for thinking, not a scoring machine.
The second source is your own supervisory authority. Article 35(4) obliges each authority to publish a list of processing operations for which a DPIA is mandatory in its jurisdiction. Those lists are specific and binding in that member state, so checking yours is faster than reasoning from first principles.
Where you conclude no DPIA is needed, record why. Article 5(2) makes you accountable for the decision, and an undocumented negative conclusion is indistinguishable from never having asked.
How the two documents work together
The practical relationship runs in one direction: the register feeds the assessment.
Screening for DPIA candidates without a register means screening from memory, which reliably misses the processing nobody wrote down. With a register, the screen becomes mechanical. Read each activity against the nine criteria and your authority's list, and flag the ones that cross the threshold. Activities involving Article 9 data, large-scale profiling, monitoring, or children will surface immediately, because those are fields the register already holds.
The reverse direction is weaker but real. A completed DPIA usually improves the corresponding register entry, because the necessity and proportionality analysis forces a sharper statement of purpose than the register drafting did.
Do vendor changes trigger a new DPIA?
Usually not, and this is worth being precise about, because the answer differs from the RoPA case.
A new subprocessor changes facts the register records: the recipients under Article 30(1)(d) and, if the subprocessor is in a third country, the transfers under Article 30(1)(e). The register must be updated, and a transfer assessment may need revisiting.
A DPIA is assessed against risk, not against vendor identity. Swapping one hosting provider for another comparable one rarely changes the risk profile of the processing. But Article 35(11) requires review where the risk changes, and some vendor changes do change it: a subprocessor in a country with materially weaker protections, a new processing step such as automated analysis of content that was previously only stored, or a substantial expansion in the data a vendor receives.
The workable posture is that vendor changes always trigger a register update, sometimes trigger a transfer assessment review, and occasionally trigger a DPIA review. What matters is that a mechanism exists to notice the change at all, since all three depend on hearing about it.
Common mistakes
- Treating a completed RoPA as evidence that DPIAs were considered. They are separate duties, and the register contains no record of the screening decision unless you add one.
- Running a DPIA for everything. It devalues the exercise and consumes the attention that genuinely high-risk processing needs. Article 35 sets a threshold deliberately.
- Running a DPIA after launch. Article 35(1) says prior to the processing. A retrospective assessment cannot discharge the Article 36 consultation duty, because the decision it was meant to inform has already been taken.
- Putting risk conclusions in the register. It makes the register longer, harder to maintain, and no more useful, while still not meeting the Article 35(7) content requirements.
- Ignoring the national Article 35(4) list. It is the most authoritative answer available and it is published.
- Never reviewing a DPIA. Article 35(11) requires review when the risk changes, and risk changes when the processing or its supply chain does.
Frequently asked questions
Is a DPIA the same as a Transfer Impact Assessment?
No. A DPIA under Article 35 assesses risk to people from a processing operation. A transfer impact assessment examines whether the law and practice of a destination country undermine an Article 46 transfer safeguard, and it derives from the Schrems II judgment and Clause 14 of the 2021 Standard Contractual Clauses rather than from Article 35. A single vendor relationship can require both, neither, or one. Which situations trigger the transfer assessment is covered in when a Transfer Impact Assessment is required.
Can one DPIA cover several processing activities?
Yes. Article 35(1) refers to a type of processing, and Recital 92 contemplates a single assessment addressing several similar operations presenting similar high risks. Introducing the same technology across multiple departments is the usual case.
Do we need a DPIA if we use a processor rather than doing it ourselves?
The duty sits with the controller regardless of who operates the systems. Using a processor changes who holds the technical detail, not who owes the assessment. Article 28(3)(f) obliges the processor to assist you with your Article 35 and 36 obligations, which is the clause to rely on when you need information you do not hold.
Does a small organisation have to do DPIAs?
Yes, where the threshold is met. The Article 30(5) derogation for organisations under 250 persons applies to the record-keeping duty, not to Article 35. There is no size exemption from DPIAs, and the criteria that make processing high risk are not correlated with headcount.
Who signs off a DPIA?
The controller decides, having sought the advice of the data protection officer where one is designated, which Article 35(2) requires. Article 35(9) adds that the views of data subjects or their representatives should be sought where appropriate. The DPO advises and monitors; the DPO does not own the decision.
Where DPAFlow fits in
DPAFlow does not produce DPIAs, and it does not provide legal advice. Being clear about that boundary matters more than claiming coverage: the Article 35 assessment is a risk judgement about your own processing, and nothing in a monitoring tool can make it.
What DPAFlow holds is the layer underneath. The RoPA builder keeps your Article 30 register with owners, review states, and review dates, which is the inventory you screen against when looking for DPIA candidates — including the fields that surface them, such as special-category data and third-country transfers. The Transfer Impact Assessment module holds the separate transfer assessments described above.
Because DPAFlow monitors vendor subprocessor and legal pages on a recurring schedule and keeps dated evidence of what changed, the vendor-side events that should prompt a register update, and occasionally a wider review, reach the records they affect rather than sitting in an inbox. Deciding what any change means stays with your team.