Data Protection Impact Assessment (DPIA)
Also known as: DPIA, data protection impact assessment, privacy risk assessment, Article 35 assessment
A Data Protection Impact Assessment (DPIA) is a formal privacy risk assessment required under Article 35 of the EU General Data Protection Regulation (GDPR) whenever a proposed processing activity is likely to result in a high risk to individuals' rights and freedoms.
It is a structured process that identifies the data processing activity, the necessity and proportionality of the processing, the risks to individuals, and the measures taken to mitigate those risks. DPIAs must be completed before the high-risk processing begins and must involve the Data Protection Officer (DPO) where one is appointed.
Data Protection Impact Assessment (DPIA), explained at three levels
At home
A DPIA is a written checklist that organizations must complete before starting certain risky uses of personal data. Under GDPR, 'high risk' includes things like processing medical records, tracking people's locations, or using automated systems to make decisions about people (like loan approvals). The DPIA asks: What data are we collecting? Why do we need it? What are the risks to the people whose data we have? What are we doing to reduce those risks? If the risks cannot be reduced enough, the organization must consult the data protection authority before proceeding.
At work
A DPIA is required under GDPR whenever processing is 'likely to result in a high risk to the rights and freedoms of natural persons'. Triggers include: systematic and extensive profiling with legal or similarly significant effects, large-scale processing of special category data (health, racial origin, biometrics, etc.), systematic monitoring of publicly accessible areas (CCTV), use of new technologies, and processing that matches any of the nine EDPB criteria. When in doubt, conducting a DPIA is always defensible; failing to conduct one when required is a GDPR violation.
At home
A DPIA has four core elements: a description of the processing (what data, for what purpose, who processes it, what systems are involved), an assessment of necessity and proportionality (is the processing necessary for the stated purpose? is it proportionate to the risk?), a risk assessment (what risks does the processing create for individuals? how likely and how severe?), and risk mitigation measures (what technical and organizational measures reduce the identified risks? what residual risk remains after mitigation?). The DPIA must be reviewed if the processing activity changes.
At work
The DPIA process requires consultation with the Data Protection Officer (DPO) where one is appointed, and must seek the views of data subjects or their representatives where appropriate. If the residual risk after mitigation remains high and cannot be brought to an acceptable level through additional measures, the organization must consult the supervisory authority (data protection authority) before proceeding with the processing. The supervisory authority has eight weeks to provide a written consultation opinion.
At home
DPIAs are not a one-off exercise. The GDPR requires organizations to review DPIAs when the processing changes in a way that could affect the risk level: for example, adding a new data category, expanding the scope of processing, or introducing a new technology. Well-governed organizations maintain a DPIA register linking each processing activity to its DPIA, tracking review dates, and flagging when re-assessment is due. The DPIA should be part of the project intake process, not an afterthought completed after build.
At work
From a practitioner standpoint, the most common DPIA failure is completing it as a paper exercise: describing processing accurately but assessing risk in superficial terms ('risk is low because we have security measures in place') without genuinely evaluating individual-level harm. An effective DPIA risk section identifies specific harm scenarios (a data breach exposes health records of 50,000 patients to public disclosure), assesses likelihood and severity from the data subject's perspective, and documents how specific mitigations address each scenario. Residual risk should be documented honestly, not assessed as 'low' to avoid a supervisory authority consultation.
Real-world examples
At home
Fatima works for a local authority that wanted to introduce facial recognition cameras in a town centre. Before deploying them, the privacy team conducted a DPIA: they identified that the technology would process biometric data (special category under GDPR), assessed the risk of misidentification and discriminatory impact, and concluded the residual risk was too high to proceed without supervisory authority consultation. The project was redesigned to use conventional CCTV instead.
At work
The privacy team at a large hospital network conducted a DPIA before deploying an AI diagnostic tool that would process patient MRI scans. The DPIA identified risks from potential algorithmic bias, data sharing with the AI vendor, and patient de-identification failures. Mitigations included a data processing agreement with the vendor, ongoing bias monitoring, and technical controls preventing the vendor from retaining patient data. The residual risk was documented, reviewed by the hospital's Data Protection Officer, and formally accepted by its leadership.
How it compares
| Feature | DPIA | Privacy Impact Assessment (PIA) | Data Protection Audit |
|---|---|---|---|
| Legal basis | Mandatory under GDPR Article 35 for high-risk processing | Best practice; mandatory under some national laws (UK, Canada) | No specific mandate: part of compliance programs |
| When required | Before high-risk processing begins | Varies, often before implementing new systems involving personal data | Periodically or when triggered by incidents |
| Scope | Specific processing activity | System, project, or organizational practice | Broader review of privacy program |
| Output | Documented risk assessment with mitigations and residual risk | Privacy risk report with recommendations | Audit findings and remediation plan |
| Regulator involvement | Required if residual risk remains high | Not typically required | May be initiated by regulator after an incident |
A DPIA is a legally required, processing-specific risk assessment under GDPR. A PIA is a broader best-practice assessment not tied to a specific legal trigger. A data protection audit reviews the overall privacy compliance program. All three are complementary rather than interchangeable.
For analysts
DPIAs are a core BA deliverable for projects involving personal data processing in GDPR-applicable contexts. BAs are well-positioned to lead the processing description section: data flow diagrams, entity-relationship models, and processing purpose documentation are natural BA artefacts. When conducting requirements elicitation for a new system, identify whether the processing meets any DPIA trigger criteria early in the project: a DPIA initiated during requirements gathering is far less disruptive than one initiated during UAT. Useful practice: include a DPIA initiation gate in the project intake checklist for any project processing personal data.
History & origin
DPIAs (previously called Privacy Impact Assessments in most pre-GDPR frameworks) were formalized in EU law with GDPR's Article 35, which came into force in May 2018. Before GDPR, the UK ICO promoted PIAs as best practice from 2007, and a 2008 Cabinet Office review made them mandatory for central government departments. The concept originated in regulatory impact assessments used in environmental law and technology policy. The Article 29 Working Party (now the European Data Protection Board) published detailed guidance (WP248) on what constitutes high-risk processing and when a DPIA is required, listing nine criteria.