A DPIA assesses risk to individuals, not risk to your organisation. That single reframing is what separates a useful assessment from a security review with a privacy label, and it is the most common reason DPIAs read as inadequate when a regulator examines one.
When one is mandatory
A DPIA is required where processing is likely to result in high risk to individuals' rights and freedoms - in particular:
- Systematic and extensive automated evaluation or profiling with legal or similarly significant effects.
- Large-scale processing of special category data - health, biometrics, religion, political views - or criminal offence data.
- Systematic monitoring of a publicly accessible area at scale.
Supervisory authorities publish their own lists of operations always requiring one, which typically add innovative technology use, combining datasets from different sources, tracking location or behaviour, and processing children's data. Check your regulator's list - they differ.
Timing is a compliance requirement, not a preference: the DPIA must be done before processing starts. A DPIA written after launch is itself evidence of a failure, and no amount of quality in the document fixes the date on it.
Where you conclude a DPIA is not required, record that screening decision briefly. "We considered it and concluded low risk because..." is a defensible position; silence is not.
The template
1. Description of the processing
Nature, scope, context and purposes. Concretely: what data, about whom, how much, how often, for how long, from where, shared with whom, and using what technology. Include a data flow - a diagram usually communicates more than three paragraphs. Vagueness here undermines everything after it, because you cannot assess risk in processing you have not described.
2. Necessity and proportionality
The section most often reduced to a sentence, and the one a regulator reads most closely. It must address:
- Lawful basis, and why it applies.
- Whether the processing actually achieves the purpose - stated plainly.
- Whether a less intrusive alternative exists. This is the heart of it. If you could achieve the same outcome with less data, coarser data, shorter retention or on-device processing, you are expected to have considered it and to say why you did not choose it.
- Data minimisation and retention decisions.
- How individual rights are supported in practice - access, objection, erasure.
- Processors and international transfers, with safeguards.
Keep privacy assessments with the rest of your evidence
GRC Copilot tracks DPIAs, processing records and the controls that mitigate each risk in one place - so privacy work is auditable rather than scattered across documents.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
3. Consultation
Who you consulted - the DPO (mandatory where one is appointed), information security, the business owner, processors, and where appropriate the individuals affected or their representatives. That last one is an explicit expectation that most organisations skip; if you did not seek those views, record why.
4. Risks to individuals
Assess likelihood and severity of harm to people. Useful prompts:
- Loss of control over their data, or inability to exercise rights.
- Discrimination, exclusion, or unfair treatment from automated decisions.
- Identity theft or fraud; financial loss.
- Reputational damage, distress, or physical harm - relevant where data reveals location, health or protected characteristics.
- Re-identification of supposedly anonymised data.
- Chilling effects on behaviour from monitoring.
Note what is not a risk to individuals: regulatory fines, reputational damage to you, and project delay. Those belong in your corporate risk register.
5. Measures to reduce risk
For each risk: the measure, its effect (eliminated, reduced, accepted), the residual risk, and whether it is approved. Measures span technical controls, minimisation, retention limits, transparency, contractual terms and governance - not encryption alone.
6. Outcome and sign-off
Residual risk, DPO advice (and if you departed from it, why), approval by someone with authority, the date, and a review trigger. If high risk remains after mitigation, you must consult your supervisory authority before processing - a step with a real timeline attached, so discovering it late is expensive.
Keeping it alive
A DPIA is not a one-time artefact. Review it when purpose, scope, technology, data sources, processors or transfer arrangements change - and periodically regardless. An assessment describing a system as it was two rewrites ago provides no protection.
Frequently asked questions
Who should write it?
The business owner of the processing, with support from privacy and security. The DPO advises and reviews but should not own it - they cannot independently review their own work.
Do we publish DPIAs?
Not required, though publishing a summary can build trust, particularly for public bodies or sensitive processing.
Do we need one for AI systems?
Usually yes where personal data is involved - profiling, automated decisions and novel technology all point toward high risk, and other AI regulation may impose its own assessment on top.
What if the DPO disagrees with proceeding?
You may proceed, but you must record the DPO's advice and your reasons for departing from it. That record is exactly what a regulator will ask to see.
Key takeaways
- Assess risk to individuals - fines and reputational damage belong elsewhere.
- Necessity and proportionality is the section regulators read first; address less intrusive alternatives.
- It must be completed before processing begins, and reviewed when things change.
- Residual high risk triggers prior consultation with the regulator - plan for the delay.