After reading, you can decide when a DPIA is required and assess harm from the point of view of the people concerned.
Definition
Articles 24 and 32 require measures appropriate to the risk to individuals. Article 35 goes further, requiring a DPIA before any processing likely to result in a high risk.
It names three situations: systematic and extensive automated evaluation with significant effects, large-scale processing of special categories of data or criminal records, and large-scale systematic monitoring of a publicly accessible area. National authorities publish further lists.
Why it matters
This is where a security mindset can mislead. A leak might cost the company very little and still do serious harm to the people in the file, and that harm is what the GDPR measures.
The stakes rise if a DPIA finds a high risk you cannot bring down: Article 36 then requires consulting the supervisory authority before you start.
How it works
Take your record of processing and screen each activity against Article 35 and your national authority's list.
Where a DPIA is needed, describe the processing and its purposes, ask whether it is necessary and proportionate, assess the risks to individuals, and set out the measures that address them.
If you have a data protection officer, Article 35(2) requires you to seek their advice. Reopen the assessment when the processing changes.
A worked case
A clinic moves its patient files to a new cloud system. Health data at that scale calls for a DPIA. The main risk is reception opening the wrong file and disclosing a diagnosis.
The clinic restricts access by role, reviews the log of file openings each month, and trains its staff. The remaining risk is rated medium, so no prior consultation is needed.
Good practices
- Score the harm as a person would feel it: discrimination, financial loss, exposure of something private.
- Run the assessment while the design can still change. A DPIA written after go-live can only describe the problems.
- When you decide that no DPIA is needed, keep a short written reason.
- Reuse your security assessment for the controls, and keep the two questions distinct.
Common mistakes
- Scoring the fine or the damage to the company, which answers a different question from the one the law asks.
- Treating a DPIA as a security audit, so that purpose, necessity and proportionality never get examined.
- Forgetting processors and transfers outside the European Economic Area, often because procurement handled them separately.
Questions
- Is a DPIA always required?
- No, only where processing is likely to result in a high risk to people. Other processing still needs measures appropriate to its risk.
- Who carries out a DPIA?
- The controller is responsible, and seeks the advice of the data protection officer where one is designated.
- What happens if the risk stays high after the DPIA?
- The controller must consult the supervisory authority before processing, under Article 36.
- Must a DPIA be published?
- The GDPR does not require it, though publishing a summary can build trust.
- Does a processor need to carry out a DPIA?
- The duty falls on the controller. A processor helps by providing information, under Article 28.