A Privacy Impact Assessment (PIA) is a structured process for identifying and mitigating privacy risks in data processing activities, with its GDPR-specific form — the Data Protection Impact Assessment (DPIA) — legally mandatory under Article 35 for processing likely to result in high risk to individuals' rights and freedoms.
A single data processing activity — launching a new HR analytics platform, deploying facial recognition at building entrances, or migrating customer records to a new CRM — can expose your organisation to regulatory enforcement, reputational harm, and individual harm if privacy risks aren't identified early. The Privacy Impact Assessment (PIA) and its GDPR-specific variant, the Data Protection Impact Assessment (DPIA), are the structured processes that catch these risks before they materialise.
Under the GDPR, a DPIA is legally mandatory for processing that is "likely to result in a high risk to the rights and freedoms of natural persons" (Article 35). Beyond the GDPR, privacy impact assessments are required or recommended by frameworks worldwide — from the UK Data Protection Act 2018 to Canada's PIPEDA, Australia's Privacy Act, and the EU AI Act's Fundamental Rights Impact Assessment.
This guide provides a complete, practical methodology for conducting privacy impact assessments that satisfy GDPR Article 35, align with supervisory authority guidance, and genuinely reduce privacy risk.
Quick Reference
Details
Legal basis (GDPR)
Article 35 — Data Protection Impact Assessment
When mandatory
Processing likely to result in high risk to individuals' rights and freedoms
Key triggers
Systematic profiling, large-scale sensitive data, systematic monitoring, new technology
Minimum content
Description of processing, necessity/proportionality, risk assessment, mitigation measures
Who conducts it
Data controller (with DPO advice if applicable)
DPO consultation
Mandatory where a DPO is designated (Article 35(2))
Supervisory authority consultation
Required when high risk cannot be sufficiently mitigated (Article 36)
Maximum penalty for non-compliance
EUR 10 million or 2% of global annual turnover
Review frequency
When processing changes materially, or at least every 3 years
Share article
Need help with compliance?
Contact us for a free consultation
Key Takeaways
A Privacy Impact Assessment (PIA) is a broad risk assessment methodology for any privacy risk; a DPIA is the GDPR-specific, legally mandated version
GDPR Article 35 makes DPIAs mandatory for high-risk processing — not conducting one when required is itself a compliance violation
The Article 29 Working Party (now EDPB) identified 9 criteria for when processing is likely high-risk — if your processing meets 2 or more, a DPIA is almost certainly required
A proper DPIA covers four pillars: description of processing, necessity and proportionality, risk assessment, and mitigation measures
You should conduct a screening assessment (threshold check) for every new or changed processing activity to determine whether a full DPIA is needed
Supervisory authority consultation (Article 36) is required when your DPIA reveals high risk that you cannot sufficiently mitigate
DPIAs are living documents — they must be reviewed and updated whenever processing changes materially
A well-conducted DPIA is a powerful accountability tool that demonstrates GDPR compliance to regulators, auditors, and data subjects
General privacy best practice; various national frameworks
GDPR Article 35
Legal mandate
Recommended (sometimes required by national law)
Mandatory when processing is likely high-risk under GDPR
Scope
Any privacy risk, any jurisdiction
Specifically risks to individuals' rights and freedoms under EU law
Methodology
Flexible — varies by framework
Must include: description, necessity/proportionality, risks, mitigations
DPO involvement
Recommended
Required where a DPO is designated
Regulatory consequence
Varies
Non-compliance = fine up to EUR 10M or 2% turnover
Terminology usage
Common in US, Canada, Australia, UK (pre-GDPR)
EU/EEA and jurisdictions that adopted GDPR-style laws
In practice, many organisations use the terms interchangeably. If you're subject to the GDPR, use "DPIA" and ensure your process meets Article 35 requirements. If you operate in multiple jurisdictions, design a single PIA methodology that satisfies GDPR DPIA requirements — it will exceed most other jurisdictions' expectations.
When Is a DPIA Mandatory Under GDPR?
Article 35(1) states: "Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in ahigh riskto the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data."
Explicitly Required (Article 35(3))
The GDPR explicitly lists three situations where a DPIA is always required:
Scenario
Example
Systematic and extensive profiling with significant effects
Automated credit scoring that determines loan eligibility
Large-scale processing of special category data (Art. 9) or criminal conviction data (Art. 10)
Hospital processing millions of patient health records
Systematic monitoring of a publicly accessible area on a large scale
City-wide CCTV with facial recognition
Explicitly Not Required
A DPIA is not required when:
Processing is not likely to result in high risk
A very similar DPIA already exists (you can reference it)
The processing was authorised by law and a DPIA was conducted during the legislative process
Processing is on the supervisory authority's "whitelist" (Article 35(5))
The 9 Criteria for High-Risk Processing
The Article 29 Working Party (WP248 rev.01, now endorsed by the EDPB) identified 9 criteria. If your processing meets 2 or more, you should generally conduct a DPIA:
#
Criterion
Example
1
Evaluation or scoring
Credit scoring, behavioural profiling, predictive health analytics
2
Automated decision-making with legal or significant effects
Facial recognition, IoT, AI/ML, blockchain for personal data
9
Processing that prevents data subjects from exercising a right or using a service/contract
A bank screening customers against a fraud database before opening accounts
Rule of thumb: 2 or more criteria = DPIA almost certainly required. 1 criterion = assess carefully; a DPIA is still good practice. 0 criteria = DPIA likely not required, but document your reasoning.
National Supervisory Authority Lists
Each EU/EEA supervisory authority publishes a list of processing types that require a DPIA (Article 35(4)) and may publish a list of processing types that do not require one (Article 35(5)). Check your relevant authority's list.
Country
Authority
DPIA-Required List Available
Croatia
AZOP (Agencija za zaštitu osobnih podataka)
Yes — published 2019
Germany
DSK (Datenschutzkonferenz)
Yes — comprehensive list
France
CNIL
Yes — plus free PIA tool
Netherlands
Autoriteit Persoonsgegevens
Yes
Ireland
DPC
Yes
Italy
Garante
Yes
Spain
AEPD
Yes — plus risk assessment tool
Tip: If you process data in multiple EU countries, check each relevant authority's list. A processing activity might be on France's mandatory list but not Germany's.
DPIA Screening: The Threshold Assessment
Before conducting a full DPIA, perform a screening assessment (also called a threshold assessment or pre-DPIA check). This is a quick evaluation that determines whether a full DPIA is needed.
Screening Checklist
For each new or materially changed processing activity, answer these questions:
#
Question
If Yes
1
Does the processing involve evaluation, scoring, or profiling?
+1 criterion met
2
Does the processing involve automated decision-making with legal/significant effects?
+1 criterion met
3
Does the processing involve systematic monitoring of individuals?
+1 criterion met
4
Does the processing involve special category data (health, biometric, political opinions, etc.)?
+1 criterion met
5
Is the processing large-scale?
+1 criterion met
6
Does the processing involve matching or combining datasets?
+1 criterion met
7
Does the processing concern vulnerable data subjects?
+1 criterion met
8
Does the processing involve innovative technology?
+1 criterion met
9
Could the processing prevent individuals from exercising a right or using a service?
+1 criterion met
10
Is this processing on your supervisory authority's mandatory DPIA list?
Full DPIA required
Score: 0 criteria — DPIA not required (document your reasoning)
Score: 1 criterion — Consider a DPIA; it may still be good practice
Score: 2+ criteria — DPIA is almost certainly required
DPIA Step-by-Step Methodology
Here is a complete 7-step methodology that satisfies GDPR Article 35 and aligns with EDPB guidance:
The first step is to provide a comprehensive description of the processing activity. Article 35(7)(a) requires a "systematic description of the envisaged processing operations and the purposes of the processing."
Information to Document
Element
What to Include
Name of processing activity
Descriptive title (e.g., "Employee Performance Analytics Platform")
Employees, customers, website visitors, patients, etc.
Categories of personal data
Name, email, health data, location data, biometric data, etc.
Special category data?
If Article 9 data is involved, specify which categories
Data sources
Where data comes from (directly from individuals, third parties, public sources)
Recipients
Who receives the data (internal teams, processors, third countries)
International transfers
Whether data leaves the EU/EEA; transfer mechanism used
Retention periods
How long data is kept; criteria for determining retention
Technical infrastructure
Systems, databases, cloud services involved
Data flows
How data moves through the system (create a data flow diagram)
Data Flow Diagram
Always include a visual data flow diagram. It doesn't need to be complex — a clear diagram showing data collection, storage, processing, sharing, and deletion is sufficient.
Step 2: Assess Necessity and Proportionality
Article 35(7)(b) requires "an assessment of the necessity and proportionality of the processing operations in relation to the purposes."
Key Questions
Question
What You're Assessing
Is this processing necessary to achieve the stated purpose?
Could the purpose be achieved with less data or less intrusive processing?
Is there a less privacy-invasive alternative?
Could you use aggregated/anonymised data instead of personal data?
Is the legal basis appropriate and valid?
If relying on legitimate interest, have you conducted a balancing test?
Is the data minimised?
Are you collecting only what's needed?
Are retention periods justified?
How long do you truly need the data?
Are data subjects adequately informed?
Privacy notice covering all Article 13/14 requirements?
Can data subjects exercise their rights effectively?
Data processing agreements, standard contractual clauses, consent mechanisms, privacy notices
Architectural
Privacy by design, data segregation, on-premises processing for sensitive data, edge computing to avoid central collection
After applying mitigations, reassess residual risk. If residual risk remains high, you must either:
Apply additional mitigations to reduce risk further, or
Consult the supervisory authority under Article 36
Step 5: Document and Sign Off
The DPIA document should include:
Section
Content
Processing description
From Step 1
Necessity and proportionality assessment
From Step 2
Risk assessment
From Step 3, including risk scores
Mitigation measures
From Step 4, with residual risk levels
DPO advice
DPO's written opinion on the DPIA (Article 35(2))
Controller decision
Whether to proceed, proceed with conditions, or not proceed
Sign-off
Senior management approval with date
Review date
Next scheduled review date
Sign-Off Authority
The DPIA should be signed by someone with authority to accept residual risks — typically the data controller representative (e.g., CISO, CPO, or business unit head). The DPO's role is to advise, not to approve or reject. If the controller decides to proceed against the DPO's advice, document the reasoning.
Step 6: Consult the Supervisory Authority (If Required)
If, after applying all reasonable mitigations, the residual risk remains high, Article 36 requires you to consult the supervisory authority before beginning the processing.
What to Include in a Consultation Request
The DPIA (complete document)
Description of the respective responsibilities of the controller and any processors
The purposes and means of the processing
The measures and safeguards to protect data subjects' rights
Contact details of the DPO
Any other information requested by the supervisory authority
The supervisory authority has 8 weeks to respond (extendable by 6 weeks for complex cases). They may:
Confirm that the processing may proceed
Require additional mitigations
Prohibit the processing
Important: Supervisory authority consultation is relatively rare. Most DPIAs conclude with residual risk reduced to an acceptable level. But knowing the process exists — and being prepared to use it — is essential.
Step 7: Review and Update
DPIAs are not one-off documents. You must review and update them when:
The processing activity changes materially (new data types, new recipients, new technology)
The risk landscape changes (new threats, new attack vectors)
Relevant law or supervisory authority guidance changes
An incident occurs that reveals previously unidentified risks
Periodically, as good practice (at least every 3 years)
Include a review log in your DPIA document tracking all reviews and updates.
DPIA Risk Assessment Matrix
Use this matrix to score risks consistently across all your DPIAs:
Likelihood Scale
Score
Level
Description
1
Remote
Very unlikely to occur; no history of occurrence; strong controls in place
2
Unlikely
Could occur in exceptional circumstances; rare historical occurrence
3
Possible
Could occur; has happened before in similar organisations
4
Likely
Expected to occur in most circumstances; regular historical occurrence
Severity Scale (Impact on Individuals)
Score
Level
Description
1
Negligible
Minor inconvenience; easily remedied; no lasting impact
2
Limited
Some inconvenience or distress; overcome with some effort
Discriminatory outcomes (gender, ethnicity, age bias), lack of transparency to candidates, inaccurate assessments
Key mitigations
Human review of all decisions, bias testing before deployment and quarterly, transparent communication to candidates, right to contest automated decisions, regular accuracy audits
Residual risk
Medium after mitigations — human oversight is critical
DPIA for AI Systems and the AI Act
The EU AI Act (Regulation 2024/1689) introduces additional impact assessment requirements for AI systems, which interact with GDPR DPIAs:
Aspect
GDPR DPIA
AI Act FRIA
Combined Approach
Focus
Risks to individuals' data protection rights
Risks to fundamental rights broadly (including non-discrimination, access to services, environmental impact)
Single assessment covering both
Trigger
High-risk processing of personal data
High-risk AI system as classified under AI Act
Conduct when AI system processes personal data
Legal basis
GDPR Article 35
AI Act Article 27 (for deployers of high-risk AI in certain contexts)
Reference both legal bases
Content overlap
~60–70% overlap in risk assessment methodology
Broader scope (fundamental rights beyond data protection)
DPIA as foundation + FRIA addendum for non-data-protection rights
Practical recommendation: If your AI system processes personal data, conduct a combined DPIA + FRIA rather than two separate assessments. Use the DPIA as the foundation and extend it to cover the AI Act's broader fundamental rights scope.
Violates Article 35 requirement for "prior to the processing"; undermines the purpose
Build DPIA into your project lifecycle — trigger it during planning/design phase
2
Assessing risks to the organisation, not to individuals
Misses the entire point of a DPIA; won't satisfy regulators
Always ask "What harm could this cause to data subjects?" — not "What fine could we face?"
3
Not involving the DPO
Article 35(2) violation; missing expert input
Establish a workflow that routes all DPIAs through the DPO for advice
4
Treating it as a box-ticking exercise
Superficial assessment that misses real risks
Use genuine risk assessment methodology with scoring matrices and worked examples
5
Not reviewing existing DPIAs
Outdated assessments that don't reflect current processing
Set calendar reminders for review; trigger reviews when processing changes
6
Failing to consult the supervisory authority when required
Article 36 violation if residual risk remains high
If post-mitigation risk is still high and you can't reduce it further, consult the authority
7
No sign-off from senior management
No accountability; decisions not properly authorised
Require sign-off from someone with authority to accept residual risk
8
Conducting a DPIA in isolation
Missing perspectives from IT, business, legal
Involve cross-functional stakeholders: IT, legal, business owner, DPO, CISO
9
Ignoring the data flow diagram
Incomplete understanding of where data goes and who has access
Always create a data flow diagram — it reveals risks that narrative descriptions miss
10
Not documenting the decision not to conduct a DPIA
Can't demonstrate you considered the requirement
Always document your screening/threshold assessment, even when the conclusion is "DPIA not required"
Frequently Asked Questions
How long does a DPIA take to complete?
A straightforward DPIA for a well-understood processing activity (e.g., new email marketing platform) can be completed in 1–2 weeks, including stakeholder consultation. A complex DPIA for high-risk processing (AI system, large-scale health data, cross-border transfers) may take 4–8 weeks. The key factors are the complexity of the processing, the number of stakeholders involved, and whether technical testing (bias audits, security assessments) is needed.
Who is responsible for conducting a DPIA?
The data controller is legally responsible. In practice, DPIAs are typically led by the privacy/DPO team with input from the business owner of the processing activity, IT/security for technical controls, and legal for regulatory analysis. The DPO must be consulted (Article 35(2)) but does not approve or reject the DPIA — that's the controller's decision.
Do I need a DPIA for every processing activity?
No. You need a DPIA when processing is likely to result in a high risk to individuals. For routine, low-risk processing (e.g., employee payroll, standard email communication), a DPIA is not required. However, you should conduct a screening assessment for every new or materially changed processing activity to determine whether a full DPIA is needed, and document your reasoning.
Can I use one DPIA for multiple similar processing activities?
Yes. Article 35(1) states that a "single assessment may address a set of similar processing operations that present similar high risks." For example, if you deploy the same employee monitoring software across 10 offices, one DPIA can cover all deployments — as long as the processing is substantively the same.
What happens if I don't conduct a required DPIA?
Non-compliance with DPIA requirements (Article 35) can result in fines of up to EUR 10 million or 2% of global annual turnover under Article 83(4). Several supervisory authorities have issued fines specifically for failure to conduct DPIAs. Beyond fines, processing without a required DPIA means you may be unaware of significant risks — which increases the likelihood of a data breach or rights violation.
How does a DPIA relate to a Data Protection Officer (DPO)?
The DPO has a specific role in the DPIA process: Article 35(2) requires the controller to "seek the advice of the data protection officer" when carrying out a DPIA. Article 39(1)(c) gives the DPO the task of providing advice on DPIAs and monitoring their performance. The DPO advises on methodology, risk assessment, and mitigations, but the controller makes the final decision.
Should I publish my DPIA?
The GDPR does not require publication. However, the Article 29 Working Party recommends publishing DPIAs as a demonstration of transparency and accountability — at least in summary form. Public authorities are particularly encouraged to publish. Even when not published, you must make the DPIA available to the supervisory authority on request.
How does a DPIA fit into Privacy by Design?
A DPIA is a key implementation tool for Privacy by Design (Article 25). By conducting a DPIA during the design phase of a new product, system, or process, you identify privacy risks early — when it's cheapest and easiest to address them. The DPIA informs design decisions: what data to collect, how to store it, what controls to implement, and how to enable data subject rights. Together, Privacy by Design and DPIAs form the core of proactive data protection.
Related Resources
GDPR Compliance Guide — Complete GDPR guide covering all obligations, including DPIAs in the broader compliance context
AI Risk Assessment Guide — For AI-specific impact assessments combining DPIA and FRIA methodology
A Privacy Impact Assessment or GDPR Data Protection Impact Assessment is far more than a compliance checkbox. When done well, it's a decision-making tool that helps you identify, evaluate, and mitigate privacy risks before they harm individuals or expose your organisation to enforcement action. The key is to embed DPIAs into your project lifecycle — not as a bureaucratic afterthought, but as a design input that shapes how you build products, deploy systems, and process personal data. For a structured, phased approach to implementing DPIAs alongside all other GDPR obligations, see our GDPR Compliance Checklist.
Need help with DPIAs? Vision Compliance provides end-to-end support for privacy impact assessments — from screening and methodology design to conducting complex DPIAs for AI systems and high-risk processing. Schedule a free consultation →
Sources: GDPR (Regulation 2016/679) Article 35–36, Article 29 Working Party Guidelines on DPIAs (WP248 rev.01), EDPB Guidelines, EU AI Act (Regulation 2024/1689), CNIL PIA Methodology
Ivana Ludiga, mag. iur., is an Associate at Vision Compliance focused on data protection, GDPR implementation, and regulatory advisory. She supports compliance projects for organizations across healthcare, financial services, and technology sectors.
