How to Run a DPIA That Actually Protects You
A Data Protection Impact Assessment is the one GDPR artefact regulators ask for by name after something goes wrong. Done well, it’s evidence you saw the risk and handled it. Done as a checkbox, it’s evidence you knew — and shipped anyway. Here’s the walkthrough we’d actually follow.
Step 0 — Do you even need one?
Article 35 requires a DPIA where processing is “likely to result in a high risk” to individuals. In practice, screen every new project against the triggers: systematic profiling or scoring; large-scale processing of special-category data; systematic public monitoring; new technologies (that AI feature counts); matching datasets; processing children’s data; or anything on your regulator’s published must-DPIA list (the ICO and most EU authorities maintain one). Two or more triggers? Do the DPIA. Borderline? Do it anyway — a short DPIA is cheaper than arguing with a regulator about why you skipped it.
The walkthrough
| Step | What good looks like |
|---|---|
| 1. Describe the processing | Data categories, subjects, volumes, flows, retention, recipients, and the tech involved — a diagram beats a paragraph. |
| 2. Establish necessity | What’s the purpose, the lawful basis, and why can’t you achieve it with less data? “Marketing wanted it” is not necessity. |
| 3. Consult stakeholders | DPO input is mandatory where you have one. Talk to the people building it — and where practical, the people affected. |
| 4. Assess risks to individuals | Not risks to the company. Score likelihood × severity of harms: discrimination, financial loss, distress, loss of control, physical harm. |
| 5. Identify mitigations | Concrete measures per risk: minimisation, pseudonymisation, access controls, retention limits, human review of automated decisions. |
| 6. Record residual risk & sign off | A named owner accepts the residual risk. If it stays high after mitigation, prior consultation with the regulator is mandatory — not optional. |
| 7. Integrate & revisit | Mitigations become tracked actions with owners; the DPIA is reviewed when the processing changes materially. |
The mistakes that make a DPIA worthless
- Writing it after the build is finished — a DPIA that can’t change the design is documentation, not assessment.
- Assessing risk to the business (fines, reputation) instead of risk to the individuals affected.
- Mitigations with no owner, deadline or follow-up — regulators check whether you actually did what the DPIA promised.
- Treating “we have consent” as a mitigation. Consent is a lawful basis, not a safeguard.
- One DPIA per company instead of one per processing activity — a single gigantic document assesses nothing.
Make it a habit, not a heroic effort
The teams that do this well wire the screening questions into project intake: every new feature or vendor answers five trigger questions, and only the flagged ones get the full assessment. That keeps DPIAs rare, fast and genuinely useful — and it means the register of completed DPIAs builds itself, ready for the day a regulator, enterprise customer, or auditor asks to see it.
Track DPIAs, risks and mitigations in one register
Cyber Horizon links privacy assessments to your risk register and control library — so DPIA actions become tracked, owned and evidenced work, not forgotten PDFs.
Book a Demo