A data protection impact assessment is the GDPR's answer to a simple question: before you start processing personal data in a way that could seriously affect people, did you stop and think about it, and can you show your work. Article 35 makes it mandatory where processing is likely to result in a high risk to individuals. Article 83 makes not doing one when you should a fineable offence, in the lower tier, up to 10 million euro or 2 percent of worldwide turnover.
The obligation is widely known and unevenly met. Most organisations either do far too many DPIAs, turning a risk tool into a form-filling reflex, or do none, because nobody decided who triggers them. Here is how to decide, and how to write one that a supervisory authority or an auditor will accept.
When it is required
Article 35(3) names three cases outright: systematic and extensive profiling with legal or similarly significant effects; large-scale processing of special-category data or criminal-offence data; and systematic large-scale monitoring of publicly accessible areas.
Beyond those, the Article 29 Working Party (now the EDPB) set out nine criteria in its 2017 guidelines, and the rule of thumb is that processing meeting two or more of them is likely high risk:
- Evaluation or scoring, including profiling and predicting.
- Automated decision-making with legal or similarly significant effect.
- Systematic monitoring.
- Sensitive data or data of a highly personal nature.
- Data processed on a large scale.
- Matching or combining datasets in a way people would not expect.
- Data concerning vulnerable data subjects: children, employees, patients, asylum seekers.
- Innovative use or application of new technological or organisational solutions.
- Processing that prevents data subjects from exercising a right or using a service or contract.
Each supervisory authority also publishes a list of processing operations that always require a DPIA in its jurisdiction, under Article 35(4), and some publish a list of operations that do not. Check the lists for the authorities you answer to; they differ.
Two examples make the criteria concrete. An HR system that scores candidates with an algorithm meets criteria 1, 2 and 7: DPIA required. A newsletter tool holding a few thousand email addresses meets none: not required, though a short record of why is still good practice.
What a DPIA must contain
Article 35(7) sets the minimum content:
- A systematic description of the processing and its purposes, including any legitimate interest relied on.
- An assessment of the necessity and proportionality of the processing in relation to the purposes.
- An assessment of the risks to the rights and freedoms of data subjects.
- The measures envisaged to address the risks, including safeguards and mechanisms to ensure protection and demonstrate compliance.
The controller must seek the advice of the data protection officer where one is designated (35(2)), and where appropriate seek the views of data subjects or their representatives (35(9)). Both are things an auditor will ask to see evidence of.
A structure that works
The best DPIAs read as a narrative rather than a spreadsheet. A structure that supervisory authorities have accepted repeatedly:
1. Description. What data, about whom, from where, for what purpose, shared with whom, kept how long, on what legal basis. A data flow diagram earns its place here. Name the processors and the international transfers.
2. Necessity and proportionality. Why this processing, and why this much of it. Could the purpose be achieved with less data, less retention, less linkage. What are the data subjects told, and how do they exercise their rights. This section is where most weak DPIAs fail, because they describe the processing without questioning it.
3. Risk assessment. For each risk to individuals (not to the organisation), the likelihood and the severity, and the resulting level. Risks to think about: unauthorised access, loss, inaccurate data leading to wrong decisions, discrimination, loss of control, chilling effects, physical harm. Use a scale you can apply consistently, and record the reasoning, not just the score.
4. Measures. For each significant risk, what you will do about it, and what the residual risk is afterwards. Measures include technical controls, minimisation, pseudonymisation, retention limits, access controls, transparency, and human review of automated decisions.
5. Conclusion and sign-off. The DPO's advice, the decision taken, who approved it, and the review date. If residual risk remains high, Article 36 requires prior consultation with the supervisory authority before processing starts, and the authority has eight weeks, extendable, to respond.
Keeping it alive
A DPIA is not a one-off. Article 35(11) requires a review where there is a change in the risk represented by the processing. In practice that means the DPIA is revisited when the purpose changes, new data or data subjects are added, a new processor or transfer is introduced, an incident reveals a risk that was missed, or the technology changes. A review date on the document, and a change-control step that asks "does this affect a DPIA", are how organisations keep the obligation without relying on memory.
What an audit checks
A GDPR audit, or the privacy criterion of a SOC 2, or the ISO 27701 privacy extension to 27001, all look at DPIAs the same way:
- Is there a documented screening process that decides when a DPIA is required, and is it applied? The auditor picks recent projects and checks whether screening happened.
- For each DPIA, does it contain the Article 35(7) elements, and is the necessity section more than a restatement of the description?
- Was the DPO consulted, and is the advice recorded?
- Are the measures actually implemented? The auditor traces a measure into the system or the process and looks for it.
- Where residual risk was high, was the authority consulted?
- Are DPIAs reviewed, and is there a link from change management?
The last point is the one most often missed. A stack of well-written DPIAs from the year the GDPR came into force, none reviewed since, tells the auditor the process ran once and stopped.
The short version
Screen everything, assess the high-risk minority properly, question necessity as hard as you describe the processing, involve the DPO, implement the measures you wrote down, and review when things change. Done that way, the DPIA is not paperwork; it is the record that you made a considered decision, which is exactly what the regulation, and anyone auditing you against it, wants to see.