DPIA (Data Protection Impact Assessment)

What is a DPIA?

DPIA stands for data protection impact assessment. It is a structured risk analysis you run on a data project when the processing is likely to create a high risk to people, before that processing starts.

The goal is practical: understand what could go wrong for the people in the data, decide which safeguards reduce that risk, and judge whether the risk that remains is acceptable. The obligation comes from GDPR, specifically Article 35.

A DPIA is not a form you fill in once. You start it before the project is built and keep it updated as the processing or the risk changes. The point is to find the problem on paper, not after go-live.

When is a DPIA mandatory?

Article 35(1) sets the trigger. You must carry out a DPIA when a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, taking into account its nature, scope, context and purposes, and in particular when it uses new technology.

Article 35(3) then names three cases where a DPIA is required in particular:

• Systematic, extensive automated evaluation
  Automated processing, including profiling, that produces legal effects or similarly significant effects on people. Scoring and ranking job applicants with a model is a textbook example.

• Large-scale special category data
  Processing health, biometric, ethnic, religious or other special category data (Article 9) or criminal offence data (Article 10) on a large scale. A platform combining patient records across many clinics falls here.

• Large-scale monitoring of a public space
  Systematic monitoring of a publicly accessible area on a large scale, such as camera analytics that tracks shoppers across a chain of stores.

Beyond these three, each national supervisory authority publishes its own list of processing that always needs a DPIA (Article 35(4)). The Belgian Data Protection Authority, the GBA/APD, has adopted such a list. The former Article 29 Working Party also set out risk criteria such as large scale, sensitive data, matching datasets, and evaluation or scoring; when a project ticks several of these boxes, plan for a DPIA.

For an ordinary customer mailing list you normally do not need one. For an assistant that combines support tickets, payment behaviour and customer value to rank people automatically, you should at least assess whether one is required.

What goes into a DPIA?

Article 35(7) sets the minimum content. A DPIA has to contain at least four things:

1. A description of the processing
   What data you use, whose data it is (the PII involved), where it comes from, and for what purpose.

2. Necessity and proportionality
   Is the processing actually needed for the purpose, or can it be done with less data and less impact? This is where data minimisation and retention limits get decided.

3. An assessment of the risks
   What could go wrong for the people involved: discrimination, a data breach, a wrong automated decision, or loss of control over their own data.

4. The measures to address the risks
   The safeguards you put in place, such as access controls, logging, anonymisation and pseudonymisation, human review, and encryption.

The DPO and prior consultation

Where you have a data protection officer, Article 35(2) says you must seek their advice when carrying out the DPIA. The DPO advises and reviews; the controller still owns the decision and stays accountable for it.

The harder case is residual risk. If the DPIA shows the processing would still be high risk even after your planned measures, Article 36 requires you to consult the supervisory authority before you start. The authority reviews the plan and can give written advice, ordinarily within eight weeks. In Belgium that consultation goes to the GBA/APD.

DPIA versus a security review

These two are easy to confuse, and doing one does not cover the other. A security review looks at whether systems and data are protected: access, encryption, resilience against attack. A DPIA looks at the impact on people: is the processing necessary, is it proportionate, and can the people involved still understand and control what happens to them.

A system can be well secured and still fail a DPIA. The scoring model may be locked down so only authorised staff can see it, yet still use too many sensitive variables or leave people with no understandable explanation of the outcome. A DPIA is where data governance stops being policy and applies to one real project.

What to watch out for with a DPIA

Do it before you build, and keep it alive
A DPIA written after go-live is documentation, not a decision. Article 35(11) expects you to review it when the processing or the risk changes, so treat it as a living document rather than a one-off.

Involve the right people early
Legal or the DPO cannot write it alone. You need input from the business, data, and security people who actually know the process.

Mind the AI Act if AI is involved
A DPIA covers privacy risk under GDPR. It is separate from the AI Act (EU), though both can apply to the same project. For certain high-risk AI systems the AI Act adds its own fundamental rights impact assessment, which complements the DPIA rather than replacing it (Article 27).

This is not legal advice
Whether a specific project needs a DPIA depends on context. For high-risk, sensitive or novel processing, involve privacy and legal specialists early.