What Is a DPIA? The Complete GDPR Data Protection Impact Assessment Guide

What Is a DPIA and Why Does It Matter?

A Data Protection Impact Assessment (DPIA) is a structured process for identifying and minimising the data protection risks of a project, system, or processing activity. Under the General Data Protection Regulation (GDPR), DPIAs are not optional — Article 35 makes them a legal requirement whenever processing is likely to result in a high risk to the rights and freedoms of individuals.

Think of a DPIA as a risk assessment specifically focused on personal data. It forces your organisation to answer three questions before you start processing: What are we doing with the data? What could go wrong for the people whose data it is? And what are we doing to prevent that?

Despite being mandatory since 2018, DPIAs remain one of the most poorly understood GDPR obligations. Supervisory authorities across Europe cite missing or inadequate DPIAs as a top finding in audits — and enforcement actions have followed. The Irish Data Protection Commission, the French CNIL, and the Norwegian Datatilsynet have all issued fines partly based on missing DPIAs.

When Is a DPIA Legally Required?

Article 35(1) sets the general rule: a DPIA is required when processing is "likely to result in a high risk to the rights and freedoms of natural persons." But what does "high risk" mean in practice?

The European Data Protection Board (EDPB) guidelines (WP248 rev.01) provide nine criteria. If your processing meets two or more, a DPIA is required:

1. Evaluation or scoring — Profiling, predictive analytics, or behavioural analysis of individuals
2. Automated decision-making with legal effects — Processing that produces legal or similarly significant decisions about people without human intervention
3. Systematic monitoring — Observation, tracking, or surveillance of individuals, including CCTV and employee monitoring
4. Sensitive data or data of a highly personal nature — Special category data under Article 9, criminal conviction data, financial data, location data, or private communications
5. Data processed on a large scale — High volume of data subjects, data items, geographic scope, or duration of processing
6. Matching or combining datasets — Merging data from two or more sources in a way data subjects would not reasonably expect
7. Data concerning vulnerable subjects — Children, employees, elderly, patients, asylum seekers, or any group with a power imbalance relative to the controller
8. Innovative use of technology — Fingerprint recognition, facial recognition, IoT devices, AI/ML systems, or any novel technology applied to personal data
9. Processing that prevents data subjects from exercising a right or using a service — Including credit checks, insurance screening, or access control systems

Each EU member state's supervisory authority also publishes its own list of processing activities that always require a DPIA. Check your national authority's published list — it is legally binding in your jurisdiction.

Common Scenarios That Trigger a DPIA

In practice, these are the processing activities most organisations encounter that require a DPIA:

• Deploying an AI or machine learning system that processes personal data
• Implementing employee monitoring software (screen recording, keystroke logging, productivity scoring)
• Launching a customer loyalty programme that builds behavioural profiles
• Migrating personal data to a new cloud provider or SaaS platform
• Installing CCTV or biometric access controls in a workplace
• Processing health data at scale (clinical trials, health apps, telemedicine platforms)
• Using personal data for marketing segmentation or ad targeting
• Cross-border data transfers to jurisdictions without adequacy decisions

How to Conduct a DPIA — Step by Step

Article 35(7) specifies the minimum content of a DPIA. Here is a practical, step-by-step approach that satisfies the legal requirements and produces a document that actually reduces risk.

Step 1: Describe the Processing

Document exactly what you are doing with personal data. Be specific:

• What personal data is collected (categories, not just "personal data")
• From whom — data subjects and their relationship to your organisation
• How it is collected — directly, observed, or inferred
• What you do with it — storage, analysis, sharing, automated processing
• Who receives it — internal teams, processors, third parties, cross-border recipients
• How long you keep it — retention periods and deletion processes
• Legal basis — which Article 6 (and if applicable, Article 9) ground applies

This is where most DPIAs fail. Vague descriptions like "we process customer data for service delivery" are not sufficient. Supervisory authorities expect granular detail.

Step 2: Assess Necessity and Proportionality

Demonstrate that the processing is necessary and proportionate to the purpose. Answer these questions:

• Is there a less invasive way to achieve the same objective?
• Are you collecting only the data you actually need (data minimisation)?
• Is the retention period justified, or could it be shorter?
• Is the legal basis valid and documented?
• How will data subjects exercise their rights (access, rectification, erasure, portability)?

Step 3: Identify and Assess Risks

Map the risks to data subjects — not to your organisation. A DPIA is about protecting people, not protecting your business from fines. For each risk, assess:

• Likelihood — How probable is the risk event? (Remote, possible, likely, almost certain)
• Severity — What is the impact on the individual? (Negligible, limited, significant, maximum)
• Overall risk level — Combine likelihood and severity into a risk rating

Common risk categories to evaluate include:

• Unauthorised access or data breach
• Inaccurate data leading to wrong decisions about individuals
• Excessive data collection beyond what is needed
• Lack of transparency — data subjects unaware of the processing
• Inability for data subjects to exercise their rights
• Re-identification of pseudonymised or anonymised data
• Function creep — data used for purposes beyond the original scope
• Discrimination or bias from automated processing

Step 4: Identify Mitigating Measures

For every risk rated above "low," document specific measures to reduce it. Measures fall into four categories:

• Technical measures — Encryption, access controls, pseudonymisation, audit logging, automated deletion
• Organisational measures — Staff training, data protection policies, role-based access, vendor due diligence
• Legal measures — Data processing agreements, privacy notices, consent mechanisms, standard contractual clauses
• Design measures — Data minimisation by design, privacy-by-default settings, purpose limitation in architecture

For each measure, document who is responsible for implementing it and the deadline. A DPIA without assigned actions is a risk register, not a risk management tool.

Step 5: Document the DPO's Advice

Article 35(2) requires you to seek the advice of the Data Protection Officer when carrying out a DPIA. Document:

• What advice the DPO provided
• Whether the DPO agrees with the risk assessment and proposed measures
• Any areas where the DPO's advice was not followed, and the reasons why

Step 6: Record the Decision

After completing the DPIA, make an explicit decision:

• Proceed — Residual risk is acceptable after mitigating measures
• Proceed with conditions — Additional measures must be implemented before or during processing
• Consult the supervisory authority — Article 36 requires prior consultation if residual risk remains high after mitigation
• Do not proceed — The processing cannot be done in a way that adequately protects data subjects

DPIA Template Structure

A well-structured DPIA document typically includes these sections:

1. Project overview — Name, owner, date, version, DPO reviewer
2. Processing description — Data categories, data subjects, purposes, legal bases, recipients, retention, transfers
3. Necessity and proportionality assessment — Justification for data collection scope and methods
4. Stakeholder consultation — Input from data subjects or their representatives (Article 35(9))
5. Risk assessment matrix — Risks mapped by likelihood and severity with current controls
6. Mitigating measures — Actions, owners, deadlines, and status tracking
7. DPO advice — Formal opinion and whether it was followed
8. Decision and sign-off — Senior management approval with date
9. Review schedule — When the DPIA will be reviewed (at minimum, when processing changes)

Common DPIA Mistakes That Trigger Enforcement

Supervisory authorities have been clear about what they consider an inadequate DPIA. Avoid these mistakes:

1. Not Doing a DPIA at All

The most common failure. Many organisations skip the DPIA because they don't realise their processing meets the threshold. If in doubt, do one — the GDPR penalises missing DPIAs but not unnecessary ones.

2. Conducting the DPIA After Processing Has Started

Article 35(1) is clear: the DPIA must be carried out before the processing begins. A retroactive DPIA is better than none, but it demonstrates non-compliance with the timing requirement.

3. Focusing on Organisational Risk Instead of Individual Risk

A DPIA that only assesses reputational damage or financial loss to the organisation misses the point. The assessment must focus on risks to the individuals whose data is being processed.

4. Vague Risk Descriptions

"There is a risk of data breach" is not a useful risk statement. Specify: What data could be breached? Through what vector? Affecting how many data subjects? With what consequences for them?

5. No Follow-Through on Mitigating Measures

Identifying risks and listing measures is only half the job. If the measures are never implemented, the DPIA is a paper exercise. Supervisory authorities check for evidence of implementation.

6. Treating the DPIA as a One-Time Exercise

A DPIA is a living document. Article 35(11) requires you to review the DPIA when the nature, scope, context, or purposes of processing change. Set a review schedule and stick to it.

DPIA vs PIA — What Is the Difference?

You may encounter the term Privacy Impact Assessment (PIA). While DPIAs and PIAs overlap significantly, there is an important distinction:

• A DPIA is a specific legal requirement under GDPR Article 35 with defined content requirements and triggers
• A PIA is a broader risk assessment methodology used in many privacy frameworks (including NIST, ISO 27701, and Canadian PIPEDA) that predates GDPR

If you are subject to GDPR, use the term DPIA and ensure your process meets Article 35 requirements. A well-done PIA can satisfy DPIA requirements, but a DPIA labelled as such demonstrates GDPR awareness to regulators.

When to Consult the Supervisory Authority

Article 36 requires prior consultation with your supervisory authority if the DPIA indicates that processing would result in a high risk that you cannot mitigate. This is not optional — failing to consult when required is a separate compliance failure.

In practice, prior consultation is rare because most organisations can identify sufficient mitigating measures. But if your DPIA concludes that residual risk remains high after all reasonable measures, you must consult before proceeding.

The supervisory authority has up to 8 weeks (extendable to 14 weeks for complex cases) to provide written advice. They may require changes to the processing or prohibit it entirely.

Building DPIAs Into Your Compliance Programme

The most effective approach is to integrate DPIAs into your existing project governance:

• Screening questionnaire — Add a short DPIA screening checklist to your project initiation process. Five to ten questions can determine whether a full DPIA is needed.
• Standardised template — Use a consistent DPIA template across the organisation so reviewers know where to find information and comparisons are possible.
• Central register — Maintain a register of all completed DPIAs with their review dates. This demonstrates systematic compliance during audits.
• Training — Project managers and product owners should understand when a DPIA is triggered, even if the DPO conducts the assessment.
• Integration with ROPA — Link each DPIA to the relevant entry in your Record of Processing Activities (Article 30) for a complete compliance picture.

Get Started With Your DPIA

A DPIA does not need to be a 50-page document. For straightforward processing activities, a well-structured 5–10 page assessment is sufficient. What matters is thoroughness, honesty about risks, and genuine follow-through on mitigating measures.

If your organisation processes personal data under GDPR and you haven't conducted DPIAs for your high-risk processing activities, start now. The cost of a missing DPIA — both in regulatory fines and in actual harm to individuals — far outweighs the effort of conducting one.

Need a structured starting point? The GRCadia GDPR Compliance Toolkit includes a ready-to-use DPIA template with screening questionnaire, risk matrix, and mitigating measures tracker — along with 20+ other GDPR documentation templates to build your complete compliance programme.