A data protection impact assessment is the GDPR’s structured method for identifying and mitigating risks before high-risk processing begins. Article 35 makes it mandatory in defined situations, Article 35(7) fixes the minimum content, and Article 36 adds a duty to consult the regulator when risk cannot be mitigated. Regulators treat a missing DPIA as evidence that the organization never considered the people affected.
| Regulation | GDPR, Articles 35 and 36 |
|---|---|
| Max penalty | EUR 10M or 2% of global turnover (Art. 83(4)) |
| Enforcing authority | National supervisory authorities, coordinated by the EDPB |
| Official text | EUR-Lex CELEX 32016R0679 |
When a DPIA is required
Article 35(3) names three always-required cases: systematic and extensive automated evaluation of people (including profiling) that produces legal or similarly significant effects, large-scale processing of special category or criminal conviction data, and systematic monitoring of publicly accessible areas at large scale.
Beyond those, the Article 29 Working Party’s nine criteria (endorsed by the EDPB) define “likely high risk”: scoring or predicting, automated decisions with significant effects, systematic monitoring, sensitive data, large scale, matched or combined datasets, vulnerable subjects, innovative technology, and processing that blocks people from rights or services. Two or more criteria generally means do the DPIA. National authorities also publish binding blacklists under Article 35(4); several include employee monitoring, biometric identification, and location tracking.
The method
- Describe the processing. Data categories, sources, flows, recipients, retention, and the technology involved. A data flow diagram catches risks prose misses.
- Test necessity and proportionality. Could the purpose be achieved with less data, shorter retention, or less intrusive means? Document the alternatives you rejected and why.
- Assess risks to individuals. Not risks to the company. Work through what could go wrong for the people whose data is processed: discrimination, financial loss, distress, loss of control.
- Define mitigations. Pseudonymization, access restriction, retention limits, transparency measures. Assign owners and dates; a DPIA with unowned mitigations is a wish list.
- Conclude on residual risk. If it remains high, trigger Article 36 prior consultation before going live.
- Review on change. A DPIA is versioned documentation, not a one-time gate. Revisit when purposes, vendors, or technology change.
Common failures
The recurring audit findings are predictable: DPIAs written after the system launched, risk registers that only consider security breaches while ignoring fairness and transparency harms, and assessments signed off without the DPO’s documented advice. The fix for all three is procedural: make the DPIA a required artifact in project intake, before procurement or build.
If your project involves AI, our AI impact assessment guide covers combining a DPIA with EU AI Act obligations. And for the website-facing portion of any project, a free scan documents current tracker behavior, useful baseline evidence for the processing description.