A Data Protection Impact Assessment (DPIA) is more than a compliance checkbox—it's a powerful tool for identifying and mitigating privacy risks before they become problems. Required by Article 35 of UK GDPR for high-risk processing, DPIAs help you build privacy into your projects from the start. This guide explains when you need one, how to conduct one effectively, and how to turn the process into a genuine benefit for your organisation.

What is a DPIA?

A Data Protection Impact Assessment is a structured process for systematically analysing and minimising the data protection risks of a project or processing activity. It's part of the broader principle of "data protection by design and by default" enshrined in Article 25 of UK GDPR.

A DPIA should:

  • Describe the nature, scope, context, and purposes of the processing
  • Assess necessity, proportionality, and compliance measures
  • Identify and assess risks to individuals
  • Identify measures to mitigate those risks

Think of it as a structured conversation about privacy risks—one that involves the right stakeholders and produces documented evidence of your thinking.

DPIA vs PIA

You may hear the terms "DPIA" and "PIA" (Privacy Impact Assessment) used interchangeably. While similar in concept, a DPIA specifically refers to the assessment required under GDPR/UK GDPR with particular legal requirements. A PIA is a more general term that predates GDPR.

When is a DPIA Required?

Article 35 requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." But what does that mean in practice?

Mandatory DPIA Triggers

A DPIA is always required when your processing involves:

🔴 Systematic Profiling with Significant Effects

Automated processing including profiling that produces legal or similarly significant effects on individuals

🔴 Large-Scale Special Category Data

Processing special category data or criminal conviction data on a large scale

🔴 Systematic Public Monitoring

Systematic monitoring of publicly accessible areas on a large scale (e.g., CCTV)

🔴 ICO's Published List

Any processing that appears on the ICO's list of processing operations requiring a DPIA

The ICO's Must-Do List

The ICO has published specific types of processing that require a DPIA in the UK:

  • Using new technologies combined with any Article 35(3) criteria
  • Denial of service decisions (e.g., credit, insurance, employment screening)
  • Large-scale profiling
  • Biometric data for identification
  • Genetic data (beyond healthcare)
  • Data matching or combining datasets beyond reasonable expectations
  • Invisible processing (without knowledge or consent)
  • Tracking location or behaviour
  • Targeting children or other vulnerable individuals
  • Risk of physical harm if data is misused

Two-or-More Rule

Even if not on the mandatory list, a DPIA is likely needed if your processing involves two or more of these criteria:

🟡 Evaluation or Scoring

Including profiling and predicting behaviour

🟡 Automated Decision-Making

With legal or similar significant effect

🟡 Systematic Monitoring

Observation, monitoring, or control of data subjects

🟡 Sensitive Data

Special categories or highly personal data

🟡 Large Scale

Large number of data subjects or volume of data

🟡 Dataset Matching

Combining datasets from different sources

🟡 Vulnerable Subjects

Children, employees, patients, elderly

🟡 Innovative Technology

New tech with unknown privacy implications

🟡 Preventing Rights

Processing that prevents exercising rights or accessing services

Practical Examples

HR Performance Analytics Platform

A company wants to implement AI-powered software that analyses employee communications and productivity to identify "high performers" and "flight risks."

Criteria triggered: Evaluation/scoring, systematic monitoring, vulnerable subjects (employees), innovative technology, automated decision-making

DPIA Required
Customer Loyalty Programme

A retailer launches a loyalty card that tracks purchase history to offer personalised discounts.

Criteria triggered: Potentially large scale, evaluation/scoring

DPIA Recommended
Internal Staff Directory

An organisation creates an internal directory with employee names, job titles, and work contact details.

Criteria triggered: None

DPIA Not Required

When to Conduct a DPIA

Timing is crucial. A DPIA should be conducted:

  • Early in the project lifecycle — When you can still influence design decisions
  • Before processing begins — Not retrospectively
  • As an ongoing process — Reviewed when circumstances change

Ideally, build DPIA screening into your project governance process. Every new project involving personal data should trigger a quick assessment of whether a full DPIA is needed.

Don't Retrofit

A DPIA conducted after a system is already built and deployed loses most of its value. You'll have limited ability to make changes, and it becomes a rubber-stamping exercise rather than genuine risk management. If you find yourself in this position, conduct the DPIA anyway—but plan for how you'll address any issues identified.

The DPIA Process: Step by Step

DPIA Workflow Overview

1
Identify need for DPIA (screening)
↓
2
Describe the processing
↓
3
Assess necessity and proportionality
↓
4
Identify and assess risks
↓
5
Identify mitigation measures
↓
6
Sign off and record outcomes
↓
7
Review and revisit as needed

1 Screening: Do You Need a DPIA?

Before launching into a full assessment, conduct a quick screening exercise:

  • What personal data will be processed?
  • Does it involve any mandatory DPIA triggers?
  • How many of the "two-or-more" criteria apply?
  • Is this genuinely low-risk routine processing?

Document your screening decision. Even if no DPIA is required, recording why demonstrates accountability.

2 Describe the Processing

Create a comprehensive picture of what you're planning to do:

  • Nature: What will you actually do with the data? Collection, storage, analysis, sharing?
  • Scope: What data, how many people, how long, geographic area?
  • Context: What's the relationship with individuals? What are their expectations? Any vulnerabilities?
  • Purpose: Why are you processing this data? What are you trying to achieve?

Include data flow diagrams if helpful. The clearer your picture, the better your risk assessment will be.

3 Assess Necessity and Proportionality

Before assessing risks, confirm the processing is justified:

  • Lawful basis: What's your lawful basis? Is it appropriate?
  • Necessity: Is all the processing genuinely necessary for your purpose?
  • Proportionality: Is the intrusion proportionate to the benefit?
  • Data minimisation: Are you collecting only what you need?
  • Accuracy: How will you keep data accurate and up to date?
  • Retention: How long will you keep it? Is this justified?
  • Transparency: How will individuals be informed?
  • Rights: How will you handle data subject rights requests?

4 Identify and Assess Risks

This is the heart of the DPIA. Consider risks to individuals (not to your organisation) across three dimensions:

  • Confidentiality risks: Could data be accessed by unauthorised parties?
  • Integrity risks: Could data be altered inappropriately?
  • Availability risks: Could data be lost or become inaccessible?

For each risk, assess:

  • Likelihood: How probable is this risk materialising?
  • Severity: How serious would the impact be on individuals?

Risk Assessment Matrix

Use a simple matrix to categorise and prioritise risks:

Low Severity Medium Severity High Severity
High Likelihood Medium High High
Medium Likelihood Low Medium High
Low Likelihood Low Low Medium

5 Identify Mitigation Measures

For each risk identified, consider what measures could reduce it:

  • Eliminate: Can you avoid the risk entirely by changing your approach?
  • Reduce: Can you lower the likelihood or severity?
  • Accept: Is the residual risk acceptable given the benefits?

Common mitigation measures include:

  • Encryption (at rest and in transit)
  • Pseudonymisation or anonymisation
  • Access controls and authentication
  • Data minimisation (collect less)
  • Retention limits (keep less long)
  • Staff training
  • Audit logging
  • Contractual protections with processors
  • Enhanced transparency measures
  • Giving individuals more control

Document the residual risk after mitigation measures are applied.

6 Consult and Sign Off

DPO consultation: If you have a DPO, you must seek their advice on the DPIA. Document their input and whether you followed their recommendations.

Data subject views: Where appropriate, seek the views of affected individuals or their representatives. This isn't always required but can be valuable.

Sign-off: The DPIA should be approved by someone with appropriate authority—typically a senior manager or project sponsor who accepts responsibility for the identified risks.

7 Review and Revisit

A DPIA isn't a one-time exercise. Review it when:

  • There are significant changes to the processing
  • New risks emerge
  • The technology or context changes
  • There's been a relevant security incident
  • Periodically (e.g., annually) for ongoing processing

When to Consult the ICO

If your DPIA identifies high risks that you cannot mitigate sufficiently, you must consult the ICO before proceeding with the processing. This is called "prior consultation" under Article 36.

The ICO will assess your DPIA and can:

  • Provide written advice
  • Require you to make changes
  • Prohibit the processing (in extreme cases)

The ICO has 8 weeks to respond (extendable to 14 weeks for complex cases). Don't start processing until you receive their response.

Prior Consultation is Rare

If you find yourself needing prior consultation, it may indicate that the processing is fundamentally problematic. Consider whether there's a different approach that would achieve your goals with lower risk. The ICO's published statistics show very few prior consultations occur—most organisations manage to mitigate risks sufficiently.

What Should a DPIA Contain?

Article 35(7) specifies minimum requirements. Your DPIA must include:

Mandatory DPIA Contents

  • Systematic description of the processing operations and purposes
  • Assessment of the necessity and proportionality of the processing
  • Assessment of risks to the rights and freedoms of data subjects
  • Measures envisaged to address the risks
  • Safeguards, security measures, and mechanisms to ensure protection
  • Evidence of compliance with UK GDPR

In practice, most DPIA templates also include:

  • Project/processing activity name and reference
  • Date and version number
  • Author and approver details
  • DPO advice and response
  • Data subject consultation (if conducted)
  • Review date and triggers

Common DPIA Mistakes

  • Conducting it too late: When the system is already built, you can't influence design decisions
  • Focusing on organisational risk: DPIAs assess risks to individuals, not reputational or financial risks to your organisation
  • Box-ticking mentality: Treating it as paperwork rather than genuine risk analysis
  • Insufficient detail: Vague descriptions that don't allow meaningful risk assessment
  • No follow-through: Identifying risks but not implementing mitigation measures
  • Set and forget: Not reviewing DPIAs when circumstances change
  • Missing stakeholders: Not involving technical, operational, and privacy expertise
  • Ignoring DPO advice: Seeking DPO input but not seriously considering it

Practical Tips for Effective DPIAs

Best Practices

  • Integrate DPIA screening into your project initiation process
  • Use a consistent template across your organisation
  • Involve the right people: privacy, IT security, business owners
  • Be specific about risks—"data breach" isn't enough; describe the scenario
  • Consider data flows and all parties involved
  • Use data flow diagrams to visualise processing
  • Document your reasoning, not just your conclusions
  • Track mitigation actions to completion
  • Maintain a DPIA register for oversight
  • Consider publishing summaries of DPIAs (good transparency practice)

Templates and Resources

The ICO provides a DPIA template and guidance:

You don't have to use the ICO's template—any format that covers the required elements is acceptable. Many organisations develop templates tailored to their specific context and risk appetite.

Conclusion

DPIAs are one of the most powerful tools in your data protection toolkit. Done well, they help you:

  • Identify problems before they become incidents
  • Build privacy into systems from the start
  • Demonstrate accountability to regulators
  • Build trust with individuals whose data you process
  • Make better decisions about new technologies and processes

The key is to see DPIAs not as bureaucratic hurdles but as opportunities for genuine risk management. Start early, involve the right people, think critically about risks, and follow through on mitigation measures. Your future self (and your DPO) will thank you.

"A DPIA is a process designed to help you systematically analyse, identify and minimise the data protection risks of a project or plan."

— Information Commissioner's Office