Most data protection problems are not caused by people ignoring the rules. They happen because nobody asked, early enough, what could go wrong. A Data Protection Impact Assessment is the GDPR's answer to that: a written, structured account of what you intend to do with personal data, what could go wrong for the people concerned, and what you are doing about it. Article 35 makes it mandatory in specific situations, but the discipline pays off well beyond them. Here is how to run one without drowning in paperwork.
Is a DPIA Required?
The trigger in Article 35(1) is processing that is likely to result in a high risk to the rights and freedoms of individuals, particularly when it uses new technologies and taking account of the nature, scope, context and purposes of the processing. That is a deliberately broad test, so the regulation gives you three practical routes to an answer.
First, Article 35(3) names three situations outright: systematic and extensive automated evaluation of personal aspects (including profiling) where decisions produce legal effects or similarly significant effects; large-scale processing of special category data or data on criminal convictions and offences; and systematic monitoring of a publicly accessible area on a large scale. Second, each supervisory authority publishes a list of processing types that always require a DPIA. Third, and most useful in day-to-day work, the European Data Protection Board's nine criteria act as a screening tool: meet two or more and you should normally carry out an assessment.
The Nine Criteria That Usually Settle the Question
- Evaluation or scoring, including profiling and predicting behaviour, health or performance.
- Automated decision-making with a legal or similarly significant effect on someone.
- Systematic monitoring of individuals, such as tracking, CCTV or continuous location data.
- Sensitive or highly personal data, such as health, biometrics, ethnicity or precise financial detail.
- Large scale processing — a judgment call based on volumes, geographic reach and duration.
- Matching or combining datasets from sources people would not expect to be joined.
- Vulnerable data subjects: children, employees, patients, asylum seekers, people in care.
- Innovative use of technology, where the risks are not yet well understood.
- Blocking a right or a service, for example screening that prevents someone accessing a contract.
You do not need a DPIA where a similar assessment already covers the processing and nothing material has changed, or where the processing has a legal basis in law and an assessment was carried out during the legislative process. Record that reasoning, briefly, and move on.
Step One: Describe the Processing Honestly
Before anyone can judge risk, they need a clear picture. Write down the purposes, the categories of data and of data subjects, the sources, the lawful basis, who can access what, which processors are involved, any international transfers, retention periods and how deletion actually happens. A simple flow diagram usually beats three pages of prose.
Two things get skipped most often. The first is the secondary use — the analytics feed, the model training set, the marketing list that grows out of a support tool. The second is consulting people. Article 35(9) expects you to seek the views of data subjects where appropriate, which in practice may mean works councils for employee monitoring or patient representatives for a clinical system. Their input changes decisions more often than teams expect.
Step Two: Test Necessity and Proportionality
Risk assessment comes second, not first. Ask whether the processing is actually necessary for the stated purpose, and whether a less intrusive option would work. Could you collect a postcode instead of a full address? Aggregate the data instead of keeping it tied to individuals? Shorten retention from five years to eighteen months? Every reduction in scope reduces the risk you then have to manage. Document the alternatives you considered and why you rejected them — this section protects you later.
Step Three: Assess and Mitigate Risk
Risk here means the likelihood and severity of harm to people, not to your organisation. Score likelihood and severity separately, then combine them; a simple low, medium, high scale is enough if you explain your reasoning. Think about discrimination, identity theft, financial loss, reputational damage, loss of confidentiality, physical harm, and the chilling effect that surveillance has on behaviour. Then apply each risk to specific groups rather than "users" in general.
In most real assessments the serious risks are mundane: overly broad access rights, exports emailed to personal accounts, indefinite retention, a vendor without a proper contract. Consider what happens when someone makes an honest mistake, not only when an attacker is clever. For each risk, name the measure, who owns it, and when it will be in place. Then re-score the risk to show the residual position. If a control is "planned", say so plainly rather than claiming it already exists.
Step Four: Document It So It Stands Up Later
There is no prescribed template, but Article 35(7) sets out what the record must contain: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks, and the measures envisaged to address them, including safeguards and security measures. Add a version number, dates, the name of the person who signed it off, and who was consulted.
Two habits make these documents credible. First, be honest about residual risk — a DPIA that concludes everything is fine reads like box-ticking. Second, keep it readable. Regulators, auditors and your own colleagues will read it years later, and clarity is what makes it defensible. Where high risk remains after mitigation, Article 36 requires you to consult the supervisory authority before starting the processing, so build time for that into your project plan.
A Short Pre-Launch Routine
Run a 30-minute screening at project kick-off using the nine criteria, and keep the result even if it says "no DPIA needed". Assign the assessment to someone who understands the actual process, not only the policy. Involve your data protection officer from the start — their advice is required under Article 35(2). Set a review date and revisit the DPIA when the purpose, the data or the technology changes, because a DPIA is a living document, not a launch certificate.
If your processing involves sensitive data, automated decisions with real consequences, or a genuinely novel use of technology, it is worth having a data protection lawyer or an experienced DPO review the assessment before you rely on it. The cost of that review is small compared with the cost of rebuilding a system after a complaint.
Photo: RDNE Stock project / Pexels
