Data Privacy Impact Assessment: A Training Guide
Short answer: A Data Protection Impact Assessment (DPIA) is a structured process required by GDPR Article 35 before processing that is "likely to result in a high risk" to individuals' rights and freedoms. It must systematically describe the processing, assess necessity and proportionality, evaluate risks, and document mitigation measures. Skipping a required DPIA is itself a GDPR violation, independent of whether a breach occurs.
TL;DR: A DPIA is not optional when GDPR Article 35 triggers apply. It is a four-component documented process — description, necessity/proportionality, risk assessment, and mitigation — that must be completed before processing starts, not after. If residual risk remains high, you must consult the supervisory authority before proceeding.
Key Takeaways - A DPIA is mandatory for processing "likely to result in a high risk" — supervisory authorities publish lists of processing types that always require one. - The four mandatory components are set out in GDPR Article 35(7): systematic description, necessity assessment, risk assessment, and mitigation measures. - A DPIA must be completed before processing begins — not retrospectively. - If residual risk remains high after mitigation, prior consultation with the supervisory authority is required under Article 36. - Training your DPO, legal, and product teams to identify DPIA triggers is as important as knowing how to run the process.
What is a DPIA and why does it exist?
A DPIA — sometimes called a Privacy Impact Assessment (PIA) in pre-GDPR contexts — is a risk management tool that forces controllers to think carefully about the privacy risks of a new or changed processing activity before it goes live.
GDPR mandates it because high-risk processing can cause real harm to individuals: financial damage, discrimination, reputational damage, physical harm, or loss of control over personal information. Identifying and mitigating those risks before processing begins is fundamentally less costly — to individuals and organisations — than dealing with the consequences of a breach or investigation.
The ICO's DPIA guidance describes the process as both a compliance tool and a practical instrument for building public trust.
When is a DPIA required?
The Article 35 trigger
GDPR Article 35(1) requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." Article 35(3) provides three categories that always require a DPIA:
- Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions have significant effects on individuals.
- Large-scale processing of special category data (health, biometric, genetic, racial/ethnic origin, etc.) or criminal conviction data.
- Systematic monitoring of a publicly accessible area on a large scale (e.g., CCTV, location tracking).
Supervisory authority lists
Each EU supervisory authority publishes a list of processing operations that always require a DPIA in their jurisdiction, and may also publish a list of processing types that do not. The ICO's list for the UK and the EDPB's guidelines on DPIAs are the primary reference points.
The nine criteria heuristic
The Article 29 Working Party (now the EDPB) identified nine criteria that indicate high-risk processing. Processing that meets two or more of these criteria will typically require a DPIA:
| Criterion | Example |
|---|---|
| Evaluation or scoring | Credit scoring, health risk profiling |
| Automated decision-making with legal or significant effect | Loan approval, insurance underwriting |
| Systematic monitoring | Employee monitoring, CCTV |
| Sensitive data or data of a highly personal nature | Health records, financial data, location data |
| Large-scale processing | National health database, social media platform |
| Matching or combining data sets | Cross-referencing marketing data with transaction data |
| Data concerning vulnerable individuals | Children, patients, employees |
| Innovative use or applying new technological or organisational solutions | AI-based decision tools, IoT devices |
| Processing that prevents subjects from exercising rights or using services | Biometric access control |
Source: EDPB Guidelines 9/2017 (WP248 rev.01).
The four mandatory DPIA components
GDPR Article 35(7) specifies what a DPIA must contain as a minimum.
Component 1 — Systematic description of processing
Describe the processing in detail: what data you collect, the purposes, the legal basis, the categories of data subjects, the retention periods, who receives the data (including processors and third-country recipients), and the technical and organisational measures already in place.
This section essentially documents your Record of Processing Activities (RoPA) entry for this specific activity, with additional technical detail.
Component 2 — Necessity and proportionality assessment
Assess whether the processing is necessary to achieve the stated purpose, and whether less privacy-intrusive alternatives exist. This requires honest engagement with GDPR's data minimisation (Article 5(1)(c)) and purpose limitation (Article 5(1)(b)) principles.
Ask: could we achieve the same result with less data, or a less intrusive method? If yes, use it.
Component 3 — Risk assessment
Identify risks to the rights and freedoms of data subjects from the processing itself. Risks include:
- Unauthorised access to personal data (confidentiality breach)
- Unintended modification of data (integrity breach)
- Unavailability of data when needed (availability breach)
- Misuse of data for purposes other than those declared
- Discrimination or unfair outcomes from automated processing
- Financial or reputational harm to data subjects
For each risk, assess inherent likelihood and severity, then assess residual likelihood and severity after existing controls.
Component 4 — Mitigation measures
Document the measures you will implement to address identified risks. These are the additional controls — over and above those already in place — that bring residual risk to an acceptable level.
If residual risk remains high despite mitigation, Article 36 requires prior consultation with the supervisory authority before processing can begin.
Step-by-step DPIA process
Step 1: Identify the trigger
Every new or significantly changed processing activity should pass through a privacy screening gate. Product managers, IT teams, and procurement all need to know when to raise a privacy flag. Common triggers include: new product features involving personal data, new third-party processors, new AI or automated decision-making tools, and transfers of data to new countries.
Step 2: Determine whether a full DPIA is required
Apply the two-criterion rule and check the supervisory authority's required list. Document the screening decision — if you conclude a DPIA is not required, record why.
Step 3: Consult your DPO
GDPR Article 35(2) requires the controller to seek the advice of the DPO when carrying out a DPIA. The DPO should be involved early, not handed a completed document to rubber-stamp.
Step 4: Draft the four components
Work through description, necessity, risks, and mitigations in sequence. Use a structured template — your supervisory authority will typically provide one.
Step 5: Review and sign off
The DPIA should be reviewed by the DPO, legal, and the relevant business owner. Where high-risk processing involves special category data or automated decision-making, consider involving an external privacy specialist.
Step 6: Monitor and update
A DPIA is a living document. Article 35(11) requires that the controller carry out a review to assess whether processing is carried out in accordance with the DPIA at least when there is a change in the risk represented by processing operations.
DPIA vs general privacy risk assessment
| Dimension | DPIA (GDPR Art. 35) | General privacy risk assessment |
|---|---|---|
| When required | Mandatory for high-risk processing | Good practice for all processing |
| Timing | Before processing begins | Ongoing / periodic |
| DPO involvement | Mandatory (Article 35(2)) | Recommended |
| Supervisory authority role | Prior consultation if high residual risk | Not typically required |
| Documentation | Formal record required | Varies |
| Scope | Specific processing activity | Broad / portfolio level |
How DPIA connects to ISO 27001
If your organisation operates an ISMS under ISO 27001:2022, the DPIA process integrates directly with your risk assessment and treatment methodology (Clause 6.1). The information asset register, threat identification, and risk treatment plan all feed into DPIA components 1, 3, and 4.
Control A.5.34 (Privacy and protection of PII) in ISO 27001:2022 Annex A explicitly references PIA/DPIA requirements, making the two frameworks mutually reinforcing. For a broader governance context, see our post on GRC in cybersecurity.
Frequently asked questions
Is a DPIA the same as a Privacy Impact Assessment (PIA)?
A PIA is the generic term; a DPIA is the GDPR-specific version. They follow the same logical structure, but a DPIA has legally defined mandatory components, timing requirements, and DPO involvement obligations under GDPR Article 35.
Who is responsible for carrying out a DPIA?
The controller is responsible. In practice, the data protection team or DPO typically leads the process, working with the business owner of the processing activity, IT/security, and legal.
Does a DPIA make a processing activity compliant?
No. A DPIA identifies and mitigates risks; it does not by itself authorise processing or guarantee compliance. Processing must still have a lawful basis, appropriate privacy notices, and all other GDPR obligations satisfied.
How long should a DPIA take?
For a routine medium-complexity processing activity, a thorough DPIA typically takes two to four weeks, including stakeholder consultation. Complex or novel technologies (AI, large-scale biometric processing) will take longer and may require external expertise.
Building DPIA skills across your compliance team? ThreatBlock's Global Data Privacy course covers Article 35 requirements, the full DPIA process, and practical exercises with real-world scenarios.
About the author: Samaksh is Lead Instructor at ThreatBlock and holds the OSCP, CRTP, CRTO, and CEH certifications, with expertise in cybersecurity compliance and risk management. Read more on the author page · Editorial policy.