What is a DPIA? Data protection impact assessment step by step

A DPIA is required whenever processing is likely to result in a high risk to individuals. We show when it's triggered, and how to complete one without it becoming a paper exercise.

A data protection impact assessment is a written analysis of what a planned processing activity does to people's rights, and what you intend to do about it. Article 35 of the GDPR makes it mandatory whenever processing is likely to result in a high risk to the rights and freedoms of individuals, and it has to be done before the processing starts.

That last clause causes most of the trouble. By the time someone asks whether a DPIA is needed, the system has often been chosen, the contract signed and the launch date announced. At that point the assessment can only describe decisions already made, which is a reasonable description of how a DPIA becomes a formality rather than a tool for making informed decisions.

Done at the right moment it works differently. It gives you a documented reason for the choices you make about a system, and occasionally it changes them.

Key takeaways

• Article 35 requires a DPIA before processing begins whenever that processing is likely to result in a high risk to individuals.
• Three situations always trigger one under Article 35(3): systematic and extensive automated evaluation of personal aspects, large-scale processing of special category data, and systematic monitoring of publicly accessible areas on a large scale.
• The European Data Protection Board's nine criteria are the practical test. Two or more usually means a DPIA is required.
• Article 35(7) sets out four things the assessment has to contain, and a DPIA missing any of them is incomplete regardless of how long it is.
• If high risk remains after mitigation, Article 36 requires you to consult your supervisory authority before you start.

When a DPIA is required

The general rule in Article 35(1) is open-ended on purpose: a DPIA is required when processing is "likely to result in a high risk," taking into account its nature, scope, context and purposes, and particularly where new technology is involved.

Three cases are named explicitly in Article 35(3). A systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal or similarly significant effects. Large-scale processing of special category data or data about criminal convictions. And systematic monitoring of a publicly accessible area on a large scale.

Beyond those, each supervisory authority publishes a national list of processing types that always require one. Denmark's Datatilsynet, Sweden's IMY and Norway's Datatilsynet all maintain their own, and they don't match each other. A Nordic group running one process across four countries should check all four lists rather than assume the Danish one covers it.

Here's a view some practitioners will push back on: the national lists are worth less than the screening criteria. Lists are finite and age quickly, while the criteria below cover processing nobody had thought of when the lists were drawn up. Treat the lists as a backstop and the criteria as the test you actually run.

Those criteria come from the Article 29 Working Party guidelines adopted in 2017 and endorsed by the EDPB. Two or more of them normally means a DPIA.

How are you using the data?

• Evaluation or scoring. Profiling people, predicting their behavior or assessing their performance, such as credit scoring or employee performance analytics.
• Automated decisions with legal or significant effect. Decisions made without human involvement that affect someone materially, such as automatically rejecting an application.
• Matching or combining datasets. Merging data that was collected for different purposes, such as joining CRM data with third-party enrichment.

What data is it, and whose?

• Sensitive or highly personal data. Special categories, criminal data, financial records or location history, such as health records or union membership.
• Vulnerable data subjects. People in a position where there’s a power imbalance, such as employees, children or patients.
• Large-scale processing. Measured by volume, geographic reach, duration and number of people, such as a nationwide customer database.

How does the processing work?

• Systematic monitoring. Observation people can’t easily avoid, such as camera surveillance or network activity monitoring.
• Innovative use or new technology. Methods whose effects aren’t well understood yet, such as AI-based assessment or biometric access control.
• Processing that blocks a right or a service. Where the outcome decides whether someone gets access, such as automated fraud screening that denies an account.

Employee monitoring tends to hit three at once. So does almost any AI system that touches personal data which is why the EU AI Act's fundamental rights impact assessment and the DPIA increasingly land on the same project.

Also read: Your practical guide to the EU AI Act

What the assessment has to contain

Article 35(7) sets a minimum of four elements, and auditors read for all four.

A systematic description of the processing and its purposes, including the controller's legitimate interest where that's the legal basis. An assessment of whether the processing is necessary and proportionate in relation to those purposes. An assessment of the risks to the rights and freedoms of data subjects. And the measures you intend to apply to address those risks, including safeguards and security measures.

The second one gets skipped most often. Necessity and proportionality is a question about whether you could achieve the same purpose with less data, shorter retention or a narrower population and answering it honestly sometimes means changing the plan. A DPIA that never considered a smaller version of the processing hasn't really done this step.

You also have to seek the advice of your data protection officer where one is appointed, under Article 35(2), and record that you did.

How to turn your DPIA into meaningful action

Three things make the difference between a DPIA that drives decisions and one that simply documents them.

Start it while the design is still movable. The useful window is during requirements and vendor selection, not after the contract. If you can't change anything as a result of the assessment, you're writing a justification.

Involve the people who know how the processing actually works. The DPO advises, but the system owner, the supplier manager and whoever handles the data day to day are the ones who know retention is set to seven years because nobody changed the default.

Tie the risk assessment to the method you already use. Running DPIAs on a scale and vocabulary that nobody else in the organisation recognises makes them hard to compare and easy to ignore. Your existing risk methodology usually transfers with minor adjustment.

And keep it alive. A DPIA describes a processing activity at a point in time. When the supplier changes, the purpose expands or the data set grows, the assessment needs revisiting which is easier if DPIA review sits in the same annual cycle as your other recurring compliance work.

When the risk stays high

Sometimes the mitigations aren't enough. If the DPIA shows the processing would still result in a high risk without measures to reduce it, Article 36 requires prior consultation with the supervisory authority before processing begins.

This is rarer than people fear. Most high risks come down to something manageable with access controls, retention limits, pseudonymisation or a different supplier arrangement. The cases that reach prior consultation usually involve processing that was genuinely novel, or a controller who couldn't find a proportionate version of what they wanted to do.

The authority has up to eight weeks to respond, extendable by six. Build that into the timeline if there's any chance you'll need it.

Where DPIAs go wrong

The failure modes repeat across organisations.

The assessment runs too late to influence anything. Risks are described from the organisation's point of view rather than the individual's, which is the perspective Article 35 actually asks for. Nobody owns the mitigation actions, so they stay as intentions. The DPIA is written once for a system that then changes substantially. Or most common of all no screening happens, so nobody knows which processing activities should have had one.

That last point is worth a process of its own. A short, documented screening on every new processing activity, including the ones that turn out not to need a DPIA, is cheap and answers the question a regulator will ask first. Denmark's Datatilsynet has made exactly that expectation clear in supervisory cases: that organisations map which activities require an assessment and plan how to get through them.

Skipping a required DPIA sits under Article 83(4) of the GDPR, with fines up to 10 million or 2% of global annual turnover. In Denmark there's an additional layer worth knowing about the Danish Data Protection Act attaches criminal liability to breaches of Articles 25 to 39, with fines or imprisonment of up to six months.

Where to start

If you're building this or reviewing what exists:

• Every new processing activity gets a short screening, and the screening is written down even when the answer is no
• You've checked the national lists for each country you operate in, not just your home market
• DPIAs begin during design or vendor selection, with a named owner from the business side
• All four Article 35(7) elements are present, including necessity and proportionality
• Risks are described from the data subject's perspective
• Mitigations have owners and deadlines, and somebody verifies they happened
• Existing DPIAs are reviewed when the processing changes, on a fixed cycle

Screening first. Everything else in the list depends on knowing which activities you're dealing with, and most organisations can build that into their existing intake process in an afternoon.

Cerivo's data protection platform runs DPIAs as a structured process rather than a document screening built into how new processing is registered, the Article 35(7) elements captured consistently, mitigations tracked with owners, and a complete audit trail from first assessment to final decision.