Data Protection Risk Management and Impact Assessments
Domain 3 - Risk management and impact assessments
This domain tests whether you can scope a DPIA, assess risks to data subjects' rights and freedoms, and decide when prior consultation is required. It also tests the difference between privacy risk, security risk, and transfer risk.
Core rules
- A DPIA (Art. 35) is required when processing is likely to result in a high risk. Indicators include systematic monitoring, large-scale special-category data, innovative technology, matching datasets, vulnerable subjects, and automated decisions with legal effects.
- A DPIA must describe the processing, assess necessity and proportionality, identify risks, define mitigations, seek DPO advice, and consult data subjects where appropriate. Review it when the processing changes.
- Risk is commonly assessed as likelihood × severity to individuals, not just harm to the organization. Residual high risk triggers prior consultation (Art. 36).
- Security risk (Art. 32) is one input, not the whole DPIA. Transfer impact assessments are separate but can feed the DPIA.
Worked example
A hospital plans AI triage that scores patients using health data, age, and postcode. A DPIA is required: large-scale special-category data, innovative technology, and potentially significant effects. The assessment examines necessity, bias and accuracy, transparency, human review, retention, and access controls. If residual risk remains high after mitigation, the hospital must consult the supervisory authority before starting. The reasoning is not that AI alone equals high risk; it is the combination of scale, sensitivity, and impact.
Traps
Running a DPIA as an IT security checklist; doing one DPIA for all processing; ignoring data subject views; failing to review after change; assuming processor documentation replaces the controller's DPIA; treating prior consultation as optional.