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 |
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
Table of Contents
- PIA vs. DPIA: What's the Difference?
- When Is a DPIA Mandatory Under GDPR?
- The 9 Criteria for High-Risk Processing
- National Supervisory Authority Lists
- DPIA Screening: The Threshold Assessment
- DPIA Step-by-Step Methodology
- Step 1: Describe the Processing
- Step 2: Assess Necessity and Proportionality
- Step 3: Identify and Assess Risks
- Step 4: Identify Mitigation Measures
- Step 5: Document and Sign Off
- Step 6: Consult the Supervisory Authority (If Required)
- Step 7: Review and Update
- DPIA Risk Assessment Matrix
- DPIA Template
- Real-World DPIA Examples
- DPIA for AI Systems and the AI Act
- Common DPIA Mistakes
- Frequently Asked Questions
- Related Resources
PIA vs. DPIA: What's the Difference?
| Aspect | Privacy Impact Assessment (PIA) | Data Protection Impact Assessment (DPIA) |
|---|---|---|
| Origin | 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 a high risk to 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 | Automated loan approval/rejection, automated CV screening |
| 3 | Systematic monitoring | Employee email monitoring, website tracking, location tracking |
| 4 | Sensitive or highly personal data | Health data, biometric data, financial data, communications content |
| 5 | Large-scale processing | Processing data of a large number of data subjects (city population, national database) |
| 6 | Matching or combining datasets | Combining CRM data with social media data; merging datasets from different controllers |
| 7 | Data concerning vulnerable individuals | Children, employees, patients, elderly, asylum seekers |
| 8 | Innovative use or new technology | 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:
┌─────────────────────────────────────────────────┐
│ DPIA METHODOLOGY │
│ │
│ Step 1: Describe the processing │
│ ↓ │
│ Step 2: Assess necessity & proportionality │
│ ↓ │
│ Step 3: Identify and assess risks │
│ ↓ │
│ Step 4: Identify mitigation measures │
│ ↓ │
│ Step 5: Document and sign off │
│ ↓ │
│ Step 6: Consult supervisory authority │
│ (if residual risk remains high) │
│ ↓ │
│ Step 7: Review and update │
│ (ongoing / when processing changes) │
└─────────────────────────────────────────────────┘
Step 1: Describe the Processing
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") |
| Data controller | Organisation name, contact details, DPO contact |
| Purpose(s) of processing | Clear statement of why data is being processed |
| Legal basis | Article 6 basis (consent, contract, legitimate interest, etc.) |
| Categories of data subjects | 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? | Access, rectification, erasure, portability, objection mechanisms? |
| Are data quality measures in place? | Accuracy, completeness, currency of data? |
| If relying on consent, is it freely given, specific, informed, and unambiguous? | Granular consent options, easy withdrawal? |
If you cannot demonstrate that the processing is necessary and proportionate, you should not proceed — regardless of risk mitigations.
Step 3: Identify and Assess Risks
This is the core of the DPIA. You're assessing risks to the rights and freedoms of data subjects — not to the organisation. Common risks include:
Risk Categories
| Category | Example Risks |
|---|---|
| Unauthorised access | Data breach exposing personal data to unauthorised parties |
| Unlawful processing | Processing data without valid legal basis; mission creep beyond stated purposes |
| Excessive data collection | Collecting more data than necessary for the stated purpose |
| Inaccurate data | Decisions based on incorrect personal data (especially with automated processing) |
| Discriminatory effects | Profiling that disproportionately affects certain groups |
| Loss of control | Data subjects unable to exercise their rights effectively |
| Re-identification | Pseudonymised or aggregated data being re-identified |
| Chilling effect | Monitoring that inhibits free expression or association |
| Physical harm | Security data breach leading to physical safety risks |
| Financial harm | Fraud, identity theft, or discriminatory pricing |
| Reputational harm to individuals | Personal data published or shared inappropriately |
Risk Assessment Factors
For each identified risk, assess:
- Likelihood — How probable is this risk materialising?
- Severity — If it materialises, how serious is the impact on individuals?
Step 4: Identify Mitigation Measures
For each identified risk, determine appropriate measures to reduce it. Measures can be:
| Type | Examples |
|---|---|
| Technical | Encryption, pseudonymisation, access controls, data minimisation at collection, automated deletion, audit logging |
| Organisational | Policies, training, data handling procedures, DPO oversight, regular audits, breach response plans |
| Legal/Contractual | 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 |
| 3 | Significant | Substantial harm — financial loss, discriminatory effects, damage to reputation, physical harm |
| 4 | Maximum | Irreversible harm — life-threatening, severe financial ruin, long-term psychological damage |
Risk Score Matrix
| Negligible (1) | Limited (2) | Significant (3) | Maximum (4) | |
|---|---|---|---|---|
| Likely (4) | 4 — Medium | 8 — High | 12 — Very High | 16 — Very High |
| Possible (3) | 3 — Low | 6 — Medium | 9 — High | 12 — Very High |
| Unlikely (2) | 2 — Low | 4 — Medium | 6 — Medium | 8 — High |
| Remote (1) | 1 — Low | 2 — Low | 3 — Low | 4 — Medium |
Risk Levels and Required Actions
| Risk Level | Score Range | Required Action |
|---|---|---|
| Low | 1–3 | Accept; document reasoning; monitor |
| Medium | 4–6 | Mitigate; implement additional controls; document treatment |
| High | 8–9 | Mitigate urgently; senior management review; consider not proceeding |
| Very High | 12–16 | Do not proceed without significant risk reduction; consult supervisory authority if risk remains after mitigation |
Worked Example
Processing activity: Deploying an AI-powered employee performance monitoring tool
| Risk | Likelihood | Severity | Score | Level |
|---|---|---|---|---|
| Inaccurate performance assessment due to biased algorithm | 3 (Possible) | 3 (Significant) | 9 | High |
| Chilling effect on employee behaviour/expression | 4 (Likely) | 2 (Limited) | 8 | High |
| Unauthorised access to performance data | 2 (Unlikely) | 3 (Significant) | 6 | Medium |
| Discriminatory outcomes for protected groups | 3 (Possible) | 4 (Maximum) | 12 | Very High |
| Employee unable to challenge automated decisions | 3 (Possible) | 3 (Significant) | 9 | High |
Conclusion: Multiple high/very high risks — significant mitigations required before proceeding.
DPIA Template
Use this template structure for your DPIAs:
Section 1: Processing Overview
| Field | Content |
|---|---|
| DPIA Reference | [Unique ID, e.g., DPIA-2026-001] |
| Processing Activity Name | [Descriptive name] |
| Business Owner | [Name, role] |
| Date Initiated | [Date] |
| DPO Consulted | [Yes/No — Name, date] |
| Status | [Draft / Under Review / Approved / Rejected] |
Section 2: Processing Description
- Purpose of processing
- Legal basis (Article 6 + Article 9 if applicable)
- Categories of data subjects
- Categories of personal data
- Data sources
- Recipients and transfers
- Retention periods
- Data flow diagram
Section 3: Necessity and Proportionality
- Why this processing is necessary
- Less invasive alternatives considered and why they were rejected
- Data minimisation measures
- How data subjects are informed
- How data subjects can exercise their rights
Section 4: Risk Assessment
- Risk identification table (risk, likelihood, severity, score, level)
- Pre-mitigation risk heat map
Section 5: Mitigation Measures
- For each risk: measure(s), owner, deadline, residual risk after mitigation
Section 6: Residual Risk Assessment
- Post-mitigation risk scores
- Overall residual risk level
- Whether supervisory authority consultation is required
Section 7: Sign-Off
- DPO advice (written opinion)
- Controller decision (proceed / proceed with conditions / do not proceed)
- Approver name, role, signature, date
Section 8: Review Log
- Date | Reviewer | Changes Made | Next Review Date
Real-World DPIA Examples
Example 1: Customer Loyalty Programme with Profiling
Processing: Retailer collecting purchase history, preferences, and behavioural data to create personalised offers and customer segments.
| DPIA Element | Analysis |
|---|---|
| Criteria met | Evaluation/scoring (1), large-scale (5), combining datasets (6) = 3 criteria → DPIA required |
| Key risks | Discriminatory profiling, excessive data collection, lack of transparency |
| Key mitigations | Granular consent, anonymisation of analytics data, opt-out from profiling, regular bias audits |
| Residual risk | Medium — acceptable with mitigations |
Example 2: Workplace CCTV with Facial Recognition
Processing: Employer deploying facial recognition cameras at building entrances for access control.
| DPIA Element | Analysis |
|---|---|
| Criteria met | Biometric data (4), systematic monitoring (3), employees as vulnerable (7), new technology (8) = 4 criteria → DPIA required |
| Key risks | Disproportionate surveillance, chilling effect, biometric data breach, bias in recognition accuracy |
| Key mitigations | Alternative access methods offered, local processing (no cloud), strict retention (24 hours), regular accuracy testing across demographics |
| Residual risk | High — consider whether facial recognition is truly necessary vs. less intrusive alternatives (access cards) |
Example 3: AI-Powered Recruitment Screening
Processing: Using AI to screen CVs and rank candidates before human review.
| DPIA Element | Analysis |
|---|---|
| Criteria met | Evaluation/scoring (1), automated decisions with significant effects (2), vulnerable individuals (7, job seekers), new technology (8) = 4 criteria → DPIA required |
| Key risks | 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.
For detailed guidance on AI risk assessment: AI Risk Assessment Guide
Common DPIA Mistakes
| # | Mistake | Consequence | How to Avoid |
|---|---|---|---|
| 1 | Conducting the DPIA after processing has started | 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
- Data Protection Officer Guide — The DPO's role in DPIA processes and beyond
- EU AI Act Compliance Guide — Understanding AI Act requirements that interact with DPIAs
Related Articles
- GDPR Compliance: The Complete Guide for Organisations in 2026 — Full guide to GDPR obligations and compliance
- Data Mapping for GDPR Guide — Building ROPA and mapping personal data flows
- Data Protection Officer (DPO) Guide — DPO appointment, duties, and outsourced services
Conclusion
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.