Data Protection Impact Assessments are one of the most frequently misunderstood requirements in a privacy programme. Many organisations know that they may be legally required, but are less clear on exactly when, what they must contain, who should be involved, and what happens if the assessment identifies a serious risk.

The confusion often starts with the language. Some teams use the term Privacy Impact Assessment, or PIA. Others use Data Protection Impact Assessment, or DPIA. Some use both as if they mean the same thing. In practice, there is overlap, but the terms are not identical.

A PIA is a broader privacy risk assessment. A DPIA is the specific legal assessment required under Article 35 of the UK General Data Protection Regulation, usually called UK GDPR, when processing is likely to result in a high risk to individuals.

This guide explains the DPIA vs PIA difference, when a DPIA is legally required, how to run one step by step, and how to make DPIAs part of project governance rather than paperwork completed after a system is already live.

What is the difference between a Privacy Impact Assessment and a Data Protection Impact Assessment?

A Privacy Impact Assessment and a Data Protection Impact Assessment are both used to identify and reduce privacy risk. The difference lies in scope, legal status, and how they are used.

PIA: the broader, pre-regulatory concept of assessing privacy risk systematically

A privacy impact assessment explained simply is a structured review of how a project, system, process, or change may affect people’s privacy. PIAs existed before GDPR and are still used in some organisations as a general privacy risk tool.

A PIA may assess risks beyond strict data protection compliance. It may consider reputational risk, ethical concerns, customer trust, surveillance concerns, fairness, transparency, or wider privacy expectations. For example, an organisation may run a PIA for a new workplace monitoring tool, even before deciding whether a formal DPIA is legally required.

DPIA: the specific legal obligation under GDPR Article 35 — when it applies and what it requires

A DPIA is a specific legal requirement under Article 35 UK GDPR. It is required when personal data processing is likely to result in a high risk to the rights and freedoms of individuals.

The GDPR Article 35 requirements mean a DPIA must describe the processing, assess necessity and proportionality, identify risks to individuals, and set out measures to address those risks. If a Data Protection Officer, or DPO, has been appointed, their advice should be sought.

A DPIA is not just a form. It is evidence that the organisation considered risk before processing began.

When organisations use PIAs, DPIAs, or both — and how to decide which is appropriate

Some organisations use a PIA as an early screening tool and a DPIA for legally high-risk processing. Others use the term DPIA for all privacy assessments and apply a lighter or fuller process depending on risk.

A practical approach is to begin every significant project with a DPIA screening threshold assessment. If high-risk triggers are present, complete a full DPIA. If not, document why a full DPIA is not required. This gives you accountability evidence even when the project does not meet the DPIA threshold.

When is a DPIA legally required under UK GDPR?

The central rule is simple: a DPIA is required where processing is likely to result in high risk to individuals. Applying that rule is where the challenge begins.

The three primary triggers under Article 35 that make a DPIA mandatory

UK GDPR identifies three types of processing where a DPIA is particularly required. These include systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions have legal or similarly significant effects; large-scale processing of special category data or criminal offence data; and systematic monitoring of publicly accessible areas on a large scale.

In practical terms, this may include automated credit decisions, employee monitoring, facial recognition, health data platforms, behavioural profiling, or location tracking at scale.

The ICO’s published list of processing operations that always require a DPIA in the UK

The ICO has also published examples of processing likely to result in high risk. The DPIA mandatory processing list ICO guidance includes areas such as innovative technology, large-scale profiling, invisible processing, tracking, biometric data, genetic data, data matching, children’s data, and other high-risk scenarios.

Organisations should not rely only on the three Article 35 examples. The ICO list and wider guidance should be built into project screening.

The screening or threshold assessment: how to determine whether a DPIA is needed for your project

A screening assessment asks structured questions before the project begins. Does the project involve special category data? Children’s data? Automated decision-making? Profiling? Large-scale processing? New technology? Monitoring? Data sharing? International transfers? Vulnerable individuals? Significant effects?

If the answer to one or more of these is yes, a full DPIA may be required. If the answer is no, record the decision and the reasons.

The nine high-risk criteria and how to apply them to a specific processing activity

Many privacy teams use nine high-risk criteria originally developed in European guidance. These include evaluation or scoring, automated decisions with significant effects, systematic monitoring, sensitive data, large-scale processing, matched or combined datasets, data about vulnerable people, innovative technology, and processing that may prevent individuals exercising a right or using a service.

You do not need every criterion to be present. In many cases, two or more can indicate high risk. Some processing may require a DPIA even where only one criterion is strong enough.

The regulatory and financial consequences of failing to carry out a mandatory DPIA

Failing to carry out a mandatory DPIA can create regulatory risk. It may show that the organisation did not assess high-risk processing properly or did not apply data protection by design. If the processing later causes harm, the absence of a DPIA can make the organisation’s position harder to defend.

A missed DPIA can also create commercial problems: delayed launch, rework, procurement delays, customer complaints, regulator scrutiny, and loss of trust.

How do you conduct a DPIA effectively — step by step?

A strong DPIA should shape the project. It should not merely describe decisions already made.

Step 1 — Describe the processing: what data, what purpose, what systems, what third parties

Start by explaining the project in plain language. What is being built or changed? What personal data is involved? Who are the individuals? What is the purpose? Which systems are used? Which suppliers are involved? Where is data stored? Who can access it? How long is it kept?

A good DPIA template UK GDPR should force clarity at this stage. If the team cannot explain the processing clearly, the project is not ready for approval.

Step 2 — Assess necessity and proportionality: is the processing justified by the purpose it serves?

Next, test whether the processing is necessary and proportionate. Is the data needed for the stated purpose? Could the same outcome be achieved with less data? Is the lawful basis appropriate? Are individuals informed? Are rights supported? Are retention periods justified?

This step is where many projects improve. Teams often discover they can remove fields, reduce access, shorten retention, or change design choices before launch.

Step 3 — Identify and assess the risks to individuals: nature, likelihood, and severity

DPIAs focus on risks to individuals, not only risks to the organisation. These may include loss of confidentiality, discrimination, financial harm, distress, loss of control, exclusion from services, unfair profiling, surveillance, identity fraud, or reputational damage.

Assess both likelihood and severity. A low-likelihood risk may still matter if the harm would be severe.

Step 4 — Identify risk mitigation measures: technical controls, organisational safeguards, and contractual protections

Mitigation measures may include data minimisation, encryption, pseudonymisation, access controls, audit logs, privacy notices, opt-outs, human review, staff training, vendor contracts, retention limits, testing, and incident response procedures.

The DPIA should clearly show which risks are reduced, how they are reduced, and what residual risk remains.

Step 5 — Consult the DPO, sign off residual risk, and document the decision

If the organisation has a DPO, they should be consulted during the DPIA. Their advice should be recorded, especially if the project team decides not to follow it.

The final decision should identify who accepts residual risk. High-risk decisions should not be left to a junior project manager or product owner. They need appropriate governance.

Step 6 — Prior consultation with the ICO: when it is mandatory and what to submit

Prior consultation ICO DPIA obligations apply where a DPIA identifies a high residual risk that cannot be reduced by mitigation measures. In that situation, the organisation must consult the ICO before proceeding.

This is not optional. The processing should not go ahead until consultation has taken place. The submission should include the DPIA, details of responsibilities, purposes and means of processing, safeguards, and the DPO’s advice where applicable.

What are the most common mistakes organisations make with DPIAs?

DPIA failures are often process failures, not legal knowledge failures.

Running the DPIA after the project has already launched — and the legal problem this creates

A DPIA should be carried out before processing begins. Running it after launch defeats the purpose because risk has already gone live. It also makes it harder to change design decisions because budgets, contracts, timelines, and user journeys may already be locked in.

Treating the DPIA as a tick-box exercise rather than a genuine risk management tool

A DPIA that says “risk accepted” without evidence is not useful. A good DPIA should challenge assumptions, test necessity, identify alternatives, and drive mitigation.

If the document simply approves whatever the project already planned, it is not functioning properly.

Failing to update the DPIA when the project scope, data types, or third parties change significantly

Projects change. New vendors are added. New data fields are collected. Analytics are expanded. Artificial intelligence features are introduced. Data is transferred to new locations.

A DPIA should be reviewed when significant changes occur. Otherwise, the assessment no longer reflects the real processing.

Not involving the DPO at the correct stage of the project lifecycle

Involving the DPO at the end creates frustration. The DPO may identify issues that should have been addressed earlier, causing delay or conflict.

The DPO should be involved early enough to influence design choices, procurement decisions, and risk controls.

How should DPIAs be embedded into project management and change governance?

DPIAs work best when they are part of normal project governance.

The DPIA screening question in project initiation documentation and change request forms

Every project initiation form or change request should include privacy screening questions. Does the project involve personal data? Is new data collected? Is data shared with a new supplier? Is special category data involved? Is monitoring or profiling involved?

These questions help identify DPIA triggers before the project progresses too far.

Integrating DPIAs into Agile sprint planning, product gate reviews, and procurement processes

In Agile environments, DPIA actions can be written into sprint tasks, user stories, and acceptance criteria. In waterfall or stage-gate models, DPIA completion can be a formal approval gate.

Procurement should also trigger DPIA screening when a new vendor will process high-risk personal data.

The DPIA register: how to track live, completed, and superseded assessments over time

A DPIA register should record project name, owner, screening result, full DPIA status, risk rating, DPO advice, approval date, review date, and whether the DPIA has been superseded.

This helps privacy teams monitor risk across the organisation and demonstrate accountability.

Using DPIA outputs as design instructions — not compliance paperwork to file after the fact

A DPIA should produce actions. For example, “remove free-text field”, “disable default location tracking”, “add user-facing explanation”, “update vendor contract”, “introduce access control”, or “reduce retention period”.

The project team should treat these as design instructions, not optional comments.

FAQs

Can a DPIA be completed retrospectively after a project has already launched?

A retrospective DPIA may be better than no assessment at all, especially if it identifies and reduces live risk. However, it does not fix the fact that the DPIA should have been completed before processing began. Organisations should treat retrospective DPIAs as remediation and improve project governance to prevent repeat issues.

What happens if a DPIA identifies a risk that cannot be sufficiently mitigated?

If a high residual risk remains after mitigation, the organisation must consult the ICO before proceeding. The project should not simply accept the risk and launch. Senior decision-makers, the DPO, and legal or compliance teams should be involved.

Is a DPIA required for a processing activity that involves employee data only?

It can be. Employee data may create high risk, especially where processing involves monitoring, profiling, special category data, automated decision-making, workplace surveillance, disciplinary decisions, or large-scale HR analytics. The fact that the data is employee data does not remove the need for a DPIA.

Conclusion

A well-run DPIA is one of the most powerful tools in a privacy programme. It creates evidence of accountability, identifies design problems before launch, and gives the DPO meaningful influence over projects rather than a retrospective audit role.

The most effective organisations do not treat DPIAs as compliance paperwork. They treat them as project quality control. A DPIA helps teams build safer systems, choose better vendors, reduce unnecessary data use, and make privacy risks visible before they become live incidents.

Stop running DPIAs as compliance exercises. Our Privacy Impact Assessments PIA And DPIA Practical Workshop gives you a repeatable process that actually reduces risk and satisfies the ICO.

For related learning, explore Data Mapping And Records Of Processing Activities ROPA, Vendor Risk And Data Processing Agreements For Privacy, and Privacy For FinTech Product Managers.