A data protection impact assessment is not paperwork you produce after the fact to justify a decision already made. It is a design-stage exercise, and its whole value lies in being done early enough that the answer can still change what you build.
Done late, it is a formality. Done on time, it occasionally kills a feature — which is the point.
When it is mandatory
Article 35 requires a DPIA where processing is likely to result in a high risk to the rights and freedoms of individuals, and specifically calls out three cases:
- Systematic and extensive evaluation based on automated processing, including profiling, on which decisions with legal or similarly significant effects are based
- Large-scale processing of special-category data or criminal-conviction data
- Large-scale systematic monitoring of a publicly accessible area
Because "high risk" is vague, regulators published nine criteria. The working rule most supervisory authorities apply: if processing meets two or more, do a DPIA.
- Evaluation or scoring, including profiling and prediction
- 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 (children, employees, patients)
- Innovative use or applying new technological or organisational solutions
- Processing that prevents data subjects from exercising a right or using a service
Read criterion 8 carefully. "Innovative use of new technology" is exactly where most AI features land — and criterion 1 catches scoring and prediction. A new AI feature that scores users is two criteria on its own.
What has to be in it
Article 35(7) sets the minimum:
- a systematic description of the processing, its purposes, and the legitimate interest pursued
- an assessment of the necessity and proportionality of the processing relative to the purpose
- an assessment of the risks to the rights and freedoms of data subjects
- the measures envisaged to address those risks — safeguards, security measures, and mechanisms to demonstrate compliance
The second one is the one teams skip, and it is the one that does the work. Necessity and proportionality asks: could you achieve the same purpose with less data, less intrusion, or a shorter retention? If the answer is yes and you did not, the DPIA has just told you the processing is unlawful — and writing it down anyway is worse than not having asked.
What happens if the risk stays high
This is the part almost nobody knows.
If, after all your mitigations, the residual risk is still high, Article 36 requires you to consult the supervisory authority before you start processing. Not notify. Consult — and wait.
The regulator has up to eight weeks to respond, extendable by six. Which means that for a feature in this category, prior consultation is not a compliance formality; it is a release blocker with a multi-month lead time, and it needs to be on the roadmap rather than discovered a fortnight before launch.
The correct response to a high residual risk is usually to change the design until the risk is no longer high.
Making it survivable
Three things separate a DPIA process that works from one that becomes theatre:
Trigger it from the product process, not the compliance calendar. A DPIA should be raised when a feature is specified, not when someone remembers. If it is not in the definition-of-ready, it will be done retrospectively and be worthless.
Connect it to the risk register. The risks a DPIA surfaces do not vanish when the document is signed. They become live risks with owners, mitigations, and residual ratings that someone has to accept.
Write down what you decided not to do. The rejected, more intrusive design is evidence of proportionality — and it is the single most useful thing to have when a regulator asks why you built it this way.
Skipping a required DPIA is itself an infringement, and it is easy for a regulator to prove: the feature exists, the assessment does not.