When Should a DPIA Be Completed? UK GDPR Guide

A DPIA is a structured process for identifying and reducing the data protection risks of a project before it goes live. Article 35 of the UK GDPR defines it, and it applies to any data controller whose processing is “likely to result in a high risk” to the rights and freedoms of individuals.

A valid DPIA has to describe the processing and its purpose, assess whether it's necessary and proportionate, assess the risk to people's rights and freedoms, and set out the safeguards that address that risk, demonstrating UK GDPR compliance in the process.

A DPIA is a living document, reviewed whenever the nature, scope, context, or purpose of the processing changes materially.

You have to complete a DPIA before starting any processing “likely to result in a high risk” to individuals. The ICO's position, consistent with Article 35(1), is that this happens at the planning stage, before processing starts.

The Three Automatic Triggers

Article 35(3) names three types of processing that always require a DPIA, whatever else is true about the project:

Fall into any of these three, and a DPIA is mandatory, with no discretion involved.

The ICO's Ten Additional Categories

Beyond the three automatic triggers, the ICO has published a list of ten processing operations it considers likely to result in high risk. Some trigger a DPIA automatically; others need combining with one of the nine criteria from the European Data Protection Board's guidelines (WP248rev01):

1. New or emerging technology: AI, machine learning, connected vehicles, IoT, wearables. Needs an EDPB criterion alongside it.
2. Denial of service: automated decisions about access to products, services, or benefits, credit checks and insurance applications among them. Automatic trigger.
3. Large-scale profiling: profiling individuals at scale, social media platforms and smart meter data included. Automatic trigger.
4. Biometric data: processing to uniquely identify individuals, facial recognition and fingerprint access included. Needs an EDPB criterion alongside it.
5. Genetic data: any processing outside direct healthcare. Needs an EDPB criterion alongside it.
6. Data matching: combining or comparing datasets from multiple sources, fraud prevention and direct marketing included. Automatic trigger.
7. Invisible processing: collecting personal data not directly from the individual, where a privacy notice is impossible or disproportionate. Needs an EDPB criterion alongside it.
8. Tracking: geolocation or behavioural tracking, online or offline, employee location data and loyalty schemes included. Needs an EDPB criterion alongside it.
9. Targeting children or vulnerable individuals: marketing, profiling, or online services aimed at children or other vulnerable groups. Automatic trigger.
10. Risk of physical harm: processing where a breach could threaten physical health or safety, whistleblowing systems and social care records included. Automatic trigger.

If your project touches AI tools, employee monitoring, health data, or records pulled together from different systems, there's a strong chance a DPIA applies. Screen for these as soon as a project is proposed.

The Two-Criteria Rule

Not every activity that touches a sensitive category needs a DPIA automatically. The EDPB sets out nine criteria for spotting processing “likely to result in high risk”:

1. Evaluation or scoring of individuals
2. Automated decision-making with legal or significant effects
3. Systematic monitoring
4. Sensitive data or data of a highly personal nature
5. Data processed on a large scale
6. Matching or combining datasets
7. Data concerning vulnerable data subjects
8. New or untested use of technology or organisational methods
9. Processing that prevents data subjects from exercising a right or using a service

Meeting two or more of these will, in most cases, require a DPIA. That's the general principle, and it's a useful starting point for screening.

But the ICO's own guidance goes further: “You may consider in your case that just meeting one criterion could require a DPIA” (ICO, Data protection impact assessments). Treat the two-criteria rule as a screening aid. Ask the question anyway when only one applies and the risk looks serious enough on its own.

Even where processing falls short of the mandatory threshold, the ICO recommends completing a DPIA for any major new project involving personal data. Doing so can signal accountability to the ICO and to the people whose data is involved.

Good practice calls for a DPIA when you're:

1. Launching a new product, service, or system that involves personal data, even where the risk looks low
2. Significantly expanding an existing processing activity, through new data types, new geographies, or new recipients
3. Onboarding a new third-party supplier that will process personal data on your behalf
4. Migrating data to a new platform or cloud environment
5. Introducing AI-assisted tools into existing workflows, even where the AI isn't making decisions on its own

A DPIA completed proactively tends to read as evidence of accountability; one done only after regulatory pressure often reads as a sign the gap was already there.

The Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025, and several of its provisions are now in force, with further changes commencing through 2026. The ICO has confirmed that its DPIA guidance is currently under review in light of the Act, so treat the specifics in this guide as the current position and check for ICO updates before finalising a borderline screening decision.

A DPIA completed at project inception doesn't stay valid forever. The ICO expects a new one whenever there's a material change to the nature, scope, context, or purposes of the processing.

Beyond change-triggered reviews, many privacy teams set a regular review point for their highest-risk processing activities, ahead of any trigger event, to confirm the assessment still reflects actual operations and that the mitigating controls still hold.

One of the most common failures is completing the initial DPIA and never returning to it. Processing activities evolve; a DPIA that was accurate in year one can mislead by year three if nobody's maintained it.

The ICO identifies two narrow circumstances where a DPIA may not be required, even for high-risk processing.

Processing on the Basis of Legal Obligation or Public Task

You may be exempt if all four conditions hold:

1. You're not subject to other legislation that specifically requires a DPIA, the Digital Economy Act 2017 among them
2. You have a clear statutory basis for the processing
3. The legal provision specifically provides for and regulates the processing operation in question
4. A data protection risk assessment was carried out when the legislation was adopted

If you can't clearly confirm that a prior assessment happened as part of the legislative process, the ICO's own advice is to err on the side of caution and complete a DPIA anyway.

You've Already Completed a Substantially Similar DPIA

Demonstrate that a prior DPIA covers processing of the same nature, scope, context, and purposes, and a new one may not be required. This exemption is narrower than it sounds: minor differences on any of those four dimensions can invalidate it.

Neither exemption is a shortcut. Both require documented reasoning, and if the ICO investigates and the exemption claim doesn't hold up, the absence of a DPIA gets treated as a compliance failure.

Failing to complete a required DPIA is a breach of UK GDPR, with consequences that show up as fines, enforcement action, and delay.

Article 35 sits in the lower tier of UK GDPR fines under Article 83(4): up to £8.7 million or 2% of global annual turnover, whichever is higher. That's a separate, lower band from the £17.5 million/4% tier that applies to breaches of the core processing principles and data subject rights, a distinction worth knowing before you quote a fine figure to a board.

Beyond fines, the ICO can:

1. Issue enforcement notices requiring you to stop processing
2. Require prior consultation before you proceed. This applies where a DPIA identifies a high residual risk that can't be mitigated
3. Publish details of the enforcement action, with direct reputational consequences

Prior consultation is a separate, easily missed obligation. If your DPIA flags a high risk you can't reduce through mitigating measures, you're legally required to consult the ICO before starting the processing. The ICO aims to respond within eight weeks, extendable to a maximum of 14 weeks for complex cases, and you can't begin the processing until that consultation is complete.

The cost of completing a DPIA that turns out not to be strictly required is low. The cost of skipping one that was required can run into millions.

For organisations running multiple projects at once, managing DPIAs by hand can be one of the highest-friction jobs in a privacy programme. A spreadsheet can capture a single DPIA. It can't track a portfolio of them, flag review triggers on its own, or connect DPIA outcomes to a wider risk register and control framework.

The operational problem shows up after the first DPIA is done:

1. Knowing which projects across the business need screening
2. Tracking the status of assessments still in progress
3. Keeping completed DPIAs current as processing changes
4. Demonstrating to auditors and regulators that the process is consistent and repeatable
5. Linking DPIA findings to the controls and risks they're meant to mitigate

Processing activities can go unrecorded, and DPIAs that do get completed rarely get revisited once the project has shipped. A spreadsheet won't catch that on its own.

SureCloud's Data Privacy Management product, powered by Gracie AI Agents with Personas and Skills, tracks each DPIA against the risk register and control framework directly. When a DPIA flags a risk, a dedicated Persona checks whether the linked control has been tested, and raises it the moment the two drift apart, keeping the mitigation on record matched to what's actually true in practice.

Privacy teams end up spending less time chasing evidence and more time on the risk decisions that need a person's judgment, cutting the time spent finding evidence during audits by 80% and DSAR completion time in half. An auditor or regulator can see the same picture without extra prep beforehand.