What Is a DPIA, and When Does GDPR Require One?

A data protection impact assessment is the assessment GDPR Article 35 requires before you start a type of processing that is "likely to result in a high risk to the rights and freedoms of natural persons". Article 35(1) sets the trigger in terms of the processing itself, "in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing" (Article 35 GDPR; the text is reproduced by Intersoft Consulting, a firm that sells data protection services, so read it as a convenience copy of the Regulation rather than as commentary). The contrarian consequence people miss: nothing in that trigger is about your headcount or your revenue. A twelve-person company running systematic automated evaluation of individuals owes a DPIA. A thousand-person company processing ordinary payroll for its own staff generally does not.

This article covers what Article 35 actually says, the three cases where a DPIA is always required, the national lists that change the answer in a specific country, what must be inside the assessment, what happens when the risk cannot be mitigated, and why the US state equivalent is a different instrument that happens to look similar.

Key takeaways

• The test is the processing, not the organization. Size, sector and revenue do not appear in Article 35(1).
• Three cases in Article 35(3) always require one: systematic and extensive automated evaluation with legal or similarly significant effects, large-scale processing of special category or criminal offence data, and large-scale systematic monitoring of a publicly accessible area.
• Supervisory authorities publish their own lists of processing that requires a DPIA, and may publish lists of processing that does not. Those lists are jurisdiction-specific and they are the first thing to check after the three cases.
• Article 35(7) fixes the minimum contents: describe the processing, assess necessity and proportionality, assess the risks, and set out the measures that address them.
• If the DPIA still shows high risk after your mitigations, Article 36 requires you to consult the supervisory authority before processing. That is a hard stop, not a formality.

What Article 35 actually says

Article 35(1) states the obligation: where a type of processing is "likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data".

Two words in that sentence do most of the work. Prior: the assessment precedes the processing, which makes a DPIA a design activity, not a documentation activity performed after launch. And likely: the standard is not certainty of harm, it is likelihood of high risk, which is a lower bar than teams usually assume when they talk themselves out of one.

Article 35(2) adds that the controller "shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment". Where designated is doing real work there: if you have no DPO, you still owe the DPIA. Whether you need a DPO at all is a separate test under Article 37, which we treat separately from this one.

Article 35(9) adds a step that is skipped almost universally: "Where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of processing operations." It is qualified by "where appropriate", but the qualification is not "where convenient".

The three cases that always require one

Article 35(3) names three types of processing where a DPIA "shall in particular be required":

1. Systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the person or similarly significantly affect them.

2. Processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10.

3. Systematic monitoring of a publicly accessible area on a large scale.

Case 1 is the one that has grown fastest, because automated evaluation with significant effects now describes a large share of what teams build with machine learning: credit and eligibility decisions, fraud scoring that blocks accounts, automated content moderation with account consequences, workforce analytics that feed performance decisions. If a model's output changes what happens to a specific person, you are in the neighbourhood of case 1 and you should work through it rather than around it.

Case 2 turns on two thresholds, "large scale" and the Article 9 special categories: health data, biometric data used for identification, genetic data, racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life and sexual orientation. Health-adjacent products reach this faster than their founders expect.

Case 3 is the CCTV and public-space analytics case, and it also reaches physical retail analytics and some connected-vehicle telemetry.

These three are floors, not ceilings. Article 35(3) says a DPIA shall "in particular" be required in those cases; processing outside them can still meet the Article 35(1) test.

The lists nobody reads

Article 35(4) requires each supervisory authority to "establish and make public a list of the kind of processing operations which are subject to the requirement for a data protection impact assessment", and to communicate those lists to the European Data Protection Board. Article 35(5) allows an authority to also publish a list of processing operations "for which no data protection impact assessment is required".

This is where a general answer stops being useful. The mandatory-DPIA list is published per jurisdiction, so the same product can trigger a DPIA obligation in one member state and not in another, and the practical answer for a given deployment comes from the list published by the authority that supervises you. Checking the relevant authority's list is a ten-minute task that is skipped in most of the privacy programs we review, and it is the single cheapest way to discover an obligation before someone else discovers it for you.

We are deliberately not reproducing any national list here. Those lists are amended, and a stale copy of a regulator's list in a consultancy article is worse than no copy at all.

What has to be in it

Article 35(7) sets the minimum contents. The assessment shall contain at least:

• a systematic description of the envisaged processing operations and the purposes of the processing, including where applicable the legitimate interest pursued by the controller;
• an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
• an assessment of the risks to the rights and freedoms of data subjects; and
• the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with the Regulation.

The second bullet is the one that separates a real DPIA from a form. Necessity and proportionality is not a security question. It asks whether you need this data, at this granularity, for this long, for this purpose, and whether a less intrusive design would achieve the same objective. A DPIA that leaps straight from a description of the system to a list of encryption controls has skipped the assessment and gone to the mitigation.

Article 35(11) then makes it a living document: "Where necessary, the controller shall carry out a review to assess if processing is performed in accordance with the data protection impact assessment at least when there is a change of the risk represented by processing operations." A DPIA signed once and filed is not what the Article contemplates.

When the risk will not go away: Article 36

If, after your mitigations, the DPIA still indicates high risk, Article 36(1) is unambiguous: "The controller shall consult the supervisory authority prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk."

Article 36(2) then sets the authority's response: where it considers the intended processing would infringe the Regulation, "in particular where the controller has insufficiently identified or mitigated the risk", it "shall, within period of up to eight weeks of receipt of the request for consultation, provide written advice to the controller and, where applicable to the processor, and may use any of its powers referred to in Article 58" (Article 36 GDPR). That period can be extended, and the Article provides for suspension of the clock while the authority obtains information.

Put in planning terms: prior consultation is a multi-week gate on a launch date, and it is triggered by your own assessment. Teams that discover this late tend to discover it as a slipped quarter. Teams that run the DPIA early enough usually find a design change that removes the residual high risk instead.

The US state analogue is a different instrument

Several US state privacy laws require an assessment for high-risk processing, and the resemblance to a DPIA is real but partial. The obligations sit under their own names, thresholds and triggers: our US state privacy laws guide covers the state-by-state picture, including which states require data protection assessments for activities such as targeted advertising, sale of personal data, profiling and processing of sensitive data.

Two cautions follow. GDPR terminology does not govern those assessments, so an Article 35(7) structure is a reasonable working template but not a compliance answer under a state law. And the applicability thresholds are entirely different: a US state law typically turns on consumer counts or revenue, which is exactly the size-based test that Article 35 does not use. An organization can therefore owe a state assessment and no DPIA, or the reverse.

The overlap is still worth exploiting. If you are running the analysis once, run it in a structure that satisfies both, and keep the jurisdiction-specific trigger analysis as a separate, short section rather than blending it into the assessment.

Honest caveats

A DPIA is not a compliance artifact you produce to have one. Article 35(1) attaches it to a specific type of processing, and Article 35(11) requires review when the risk changes, so a document that describes processing you no longer perform is not evidence of anything. We have reviewed programs holding thirty DPIAs where four described the live product.

The opposite failure is more common and more expensive. Teams treat the DPIA as a legal deliverable due before launch, hand it to counsel, and get back a document that is correct and arrives too late to change the design. The value of a DPIA is almost entirely in the necessity and proportionality analysis, and that analysis is only useful while the architecture is still movable.

And against our own interest: if your processing is plainly outside Article 35(3), your supervisory authority's list does not name it, and the Article 35(1) test does not bite, then you do not need a DPIA, and buying one because a customer questionnaire asked whether you "do DPIAs" is spending on the wrong thing. Document the screening decision instead. That record, showing you considered the question and why the answer was no, is what an authority would actually want to see.

Where Top Floor fits

Our GDPR practice runs the screening test first and the assessment second, because the screening decision is cheap and the assessment is not, and because a documented negative screening is itself the artifact an authority expects when no DPIA exists. Where a DPIA is required, we structure it to Article 35(7) with the necessity and proportionality analysis done while the design can still change.

For organizations operating across several regimes at once, our global privacy work builds one assessment structure and layers the jurisdiction-specific triggers on top, rather than maintaining parallel documents that drift. Where privacy sits inside a wider control program, compliance as a service keeps the review cadence running, which is the Article 35(11) obligation most programs quietly drop after year one.

How to decide this week

Take your product roadmap for the next two quarters and mark every item that changes what personal data you collect, how automated a decision becomes, or where data goes. That list, not your existing DPIA folder, is the input.

For each marked item, run the three Article 35(3) cases as a yes or no, and then check the published list from the supervisory authority that supervises you. Write the answer down either way, with a date and a name against it.

For anything that comes back yes, schedule the assessment before the architecture review, not after it. And if you already suspect the residual risk will stay high, put the Article 36 consultation period on the launch plan now, because eight weeks discovered late is a quarter.

Finally, look at the DPIAs you already hold and check them against Article 35(11). Any that describe processing that has since changed materially are due a review, and any that describe processing you no longer do should be closed rather than carried.

Frequently asked questions

Does a small company need a DPIA?

Possibly, and company size is not the test. Article 35(1) attaches the obligation to a type of processing that is likely to result in a high risk to individuals, taking into account the nature, scope, context and purposes of that processing. There is no employee or revenue threshold anywhere in the Article. A small team building automated decision-making that significantly affects individuals, or processing special category data at scale, is squarely in scope, while a much larger organization doing ordinary low-risk processing may owe nothing.

Is a DPIA the same as a privacy impact assessment?

They are used interchangeably in conversation, and the DPIA is the specific instrument GDPR Article 35 creates, with a defined trigger and a defined minimum content set under Article 35(7). Privacy impact assessment is the older and looser term, and several US state laws require assessments of their own with different names, thresholds and triggers. Using a single template across all of them is efficient; assuming that satisfying one satisfies the others is not, because the applicability tests are genuinely different.

When must we consult the supervisory authority?

When the DPIA indicates that the processing would result in a high risk in the absence of measures taken to mitigate that risk, Article 36(1) requires consultation with the supervisory authority prior to processing. Where the authority considers the processing would infringe the Regulation, Article 36(2) gives it up to eight weeks from receipt of the request to provide written advice, a period that can be extended, and it may exercise its Article 58 powers. Treat prior consultation as a scheduled gate on the launch date rather than a background formality.

How often does a DPIA need to be reviewed?

Article 35(11) requires the controller, where necessary, to carry out a review to assess whether processing is performed in accordance with the DPIA, at least when there is a change of the risk represented by the processing operations. That is a trigger-based obligation rather than a fixed calendar, so the practical approach is to tie the review to change events you can actually detect: a new data category, a new purpose, a new processor or sub-processor, a new jurisdiction, or a material change to an automated decision. An annual sweep on top of that catches the changes nobody flagged.