Data Protection Impact Assessments

Article 35 UK GDPR risk assessments for processing likely to result in a high risk

Download the Bratby Law DPIA template: a general-form Article 35 framework with a 5×5 risk register and the Article 36 prior consultation gateway.

DPIA advice for UK organisations processing personal data

Rob Bratby, Managing Partner
Last updated: August 2026

A controller must carry out a data protection impact assessment before beginning processing that is likely to result in a high risk to individuals (Article 35 UK GDPR). The assessment records what the processing does, what could go wrong and what the controller has done about it. Completed before the project is built, it can still change the design.

Where the DPIA covers an AI or automated decision-making system, the wider regulatory context, including Articles 22A to 22D UK GDPR, is set out at UK AI Regulation: What the Law Actually Says.

When a DPIA becomes necessary

A controller must carry out a DPIA where a type of processing is likely to result in high risk to the rights and freedoms of individuals (Article 35 UK GDPR). Article 35(3) names three types of processing that always require one: systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the individual; large-scale processing of special category data or of criminal offence data; and systematic monitoring of a publicly accessible area on a large scale. Beyond those, the ICO has published a list of ten further operations under Article 35(4), some of which require a DPIA on their own and some only in combination with another factor. They include innovative technology, data matching across multiple sources, and use of the personal data of children or other vulnerable individuals for marketing, profiling or other automated decision-making.

Where you deploy new technology, particularly technology you have not used before, the first question is whether the processing is likely to result in high risk. Artificial intelligence and automated decision-making systems almost always require assessment, whether you build them yourself or use third-party tools. A restricted transfer does not of itself require a DPIA. Cross-border processing and a chain of processors in several jurisdictions do, though, often carry one of the ICO's Article 35(4) factors, and they make the risk to data subject rights harder to assess, so test the Article 35(1) threshold rather than assuming it is not met. Where you materially change existing processing, by expanding its scope, using new categories of data or changing the way you analyse it, you should reassess.

The Data (Use and Access) Act 2025 left Article 35 substantively untouched. The lists of processing that does, and does not, require a DPIA remain the ICO's to make under Article 35(4) and Article 35(5), and the ICO has not made a list under Article 35(5). The test is therefore still Article 35(1), read with the Article 35(3) categories and the ICO's Article 35(4) list. What the Act did change is the surrounding law a DPIA has to describe, in particular the lawful bases and the automated decision-making provisions, and the ICO's DPIA guidance is under review for that reason.

Why DPIAs matter now

In my experience the absence of a DPIA, where one was required, is among the first things the ICO looks for when it investigates a breach or another compliance failure, and it colours everything that follows. A contemporaneous DPIA is the record of what you assessed, when, and on what evidence.

Where you deploy a novel algorithm or a predictive model on personal data and the processing is likely to result in high risk, the DPIA must be completed before the system goes live. The EU AI Act can reach a UK organisation, but not because it processes the personal data of EU residents. Article 2(1) turns on placing an AI system on the market or putting it into service in the Union, on being a deployer established or located in the Union, or on the output of the system being used in the Union. Where it does apply, Article 27(4) provides that a fundamental rights impact assessment complements a data protection impact assessment carried out under Article 35, rather than duplicating it.

Where DPIAs fail

A DPIA of 50 or 60 pages that describes the processing in detail, lists generic risks with stock mitigations and concludes that every risk is “acceptable” or “mitigated” does not do what Article 35 requires. The assessment has to identify what could go wrong in this processing, and reach a conclusion on whether it should proceed.

A template applied across several projects carries assumptions that may not hold for any of them. A DPO asked to review a finished draft has not been consulted while the design was still open. A DPIA completed after the processing has begun cannot change the processing. A DPIA that is not revisited when the processing changes materially no longer describes what the organisation does. A DPIA that records high residual risk without reaching a conclusion leaves open both the decision to proceed and the question of consultation with the ICO under Article 36.

Where no DPIA was carried out and the processing was likely to result in high risk, the breach of Article 35 stands whether or not the ICO ever asks.

What a good DPIA looks like

A good DPIA is proportionate to the actual risk. For straightforward, low-risk processing such as routine data management for existing business purposes, a DPIA can be brief and focused. For complex or novel processing, including an AI system or large-scale profiling, it needs to go further.

Describe the processing accurately. Set out what data you collect, from where, how you use it, who has access to it and how long you retain it. This is not a privacy notice: it should be technical, specific and complete. Where the processing has changed or grown since it was last described, that should be evident at this stage.

Name the risks that are possible given your processing, your data subjects and your control environment. They commonly include unauthorised access, loss or corruption of data, discrimination through a biased algorithm, rights of individuals not being met, and unintended secondary uses. Do not record a risk as “mitigated” without the evidence. Separate the risks that exist before you add controls from the risks that remain after you add them.

Describe what you will do to reduce each risk, and be specific: not “implement security controls” but “implement encryption at rest using AES-256, and enforce multi-factor authentication for administrative access”. Some measures are technical, such as encryption or access controls; others are organisational, such as staff training or the terms you agree with a processor.

State what level of risk remains after mitigation. At low risk you can proceed. At moderate risk you should monitor and reassess regularly. At high risk you must decide whether the processing should proceed at all, whether different controls would reduce the risk further, or whether to consult the ICO under Article 36.

You must consult the ICO under Article 36 where the DPIA indicates that the processing is likely to result in a high risk you cannot adequately mitigate. Where your DPIA concludes that residual risk is high and cannot be reduced further, that consultation must happen before you go live.

A DPIA is a working document: start it early, revise it as the project develops and refresh it when the processing changes materially. It should inform the design and control decisions rather than record them afterwards. Where processing is continuing, review the DPIA at least annually and update it when the business or technical context changes materially.

When to instruct specialist DPIA support

Many organisations have internal Data Protection Officers who handle routine DPIAs. Where you are deploying artificial intelligence or an automated decision-making system, particularly one that profiles individuals or takes decisions about them, an external specialist can test your assessment of algorithmic risk, discrimination and the transparency obligations.

Synthetic data, advanced analytics platforms and edge computing introduce processing patterns that are new to the organisations adopting them, and a specialist can put the technical detail into risk terms and identify control gaps. Processing involving children’s data carries heightened risk and tighter regulatory requirements. Cross-border processing, particularly where data flows between the UK and the EU or beyond, requires assessment of dual compliance obligations and adequacy decisions.

Where a DPIA indicates high residual risk, take advice on the remediation options and on whether to consult the ICO under Article 36. An external reader also tests the assumptions the project team has stopped questioning.

Frequently asked questions about data protection impact assessments

Do we need a DPIA for every processing activity we undertake?

No. DPIAs are required only for processing that is likely to result in high risk to individuals. Routine processing such as employee records management, ordinary email communications, or customer billing does not normally require a DPIA unless you introduce elements that increase risk, such as profiling employees or cross-border data transfers.

Can we use a template for every DPIA, or does each one need to be tailored?

Templates can provide useful structure, but each DPIA must be genuinely tailored to the specific processing and context. A template that works for payroll processing will not adequately address the risks of a new AI system. Use a template as a starting point rather than a standard document, and rewrite the substantive sections to reflect the actual processing and the actual risks.

What happens if we complete a DPIA and find that residual risk is high?

You should not ignore high residual risk. Your options are to redesign the processing to reduce risk, add additional controls, or consult the ICO under Article 36 before proceeding. Consultation does not mean the ICO will block the processing, but it gives the regulator a chance to review your assessment and advise on whether they believe risk can be adequately mitigated. Proceeding without consultation when your own DPIA suggests high risk is a material compliance failure.

How often should we review and update an existing DPIA?

At minimum, you should review a DPIA annually and update it if the processing, the technologies you use, or your control environment change materially. If you introduce a new data processor, expand the scope of the processing, or adopt new tools such as analytics platforms, the DPIA should be refreshed. DPIAs are not one-off compliance events: they are part of ongoing governance.

Who should be involved in a DPIA?

A DPIA should involve the business owner who is responsible for the processing, the technical team who will implement it, your Data Protection Officer or internal data privacy contact, and any relevant external advisors. Article 35(2) requires the controller to seek the advice of the data protection officer, where one is designated, and that is not a box-tick. The DPO should be genuinely involved in challenging the processing design and the risk assessment, not simply reviewing a finished document.

What is the difference between a DPIA and an ICO prior consultation under Article 36?

A DPIA is a document and process that you must complete before processing begins if processing is likely to result in high risk. An Article 36 consultation is a request to the ICO for advice when a DPIA indicates that high risk remains despite mitigation efforts. Prior consultation does not delay implementation indefinitely. Where the ICO takes the view that the intended processing would infringe the UK GDPR, it must give written advice within a period of up to eight weeks of receiving the consultation request, and that period may be extended by six weeks taking into account the complexity of the intended processing (UK GDPR Article 36(2)). You should initiate a DPIA early so that you have time for prior consultation if the DPIA indicates high risk.

Advice on a Data Protection Impact Assessment

Schedule an initial call

Representative experience

Recent and representative matters include:

Prepared DPIAs for an AI-enabled customer analytics platform processing behavioural data, usage patterns and inferred preferences across a telecoms customer base.
Advised a connected vehicle manufacturer on the Article 35 DPIA requirement for processing vehicle telemetry, geolocation and driver behaviour data, including consultation with the ICO on high residual risks.
Conducted a DPIA for a financial services firm deploying automated creditworthiness scoring using alternative data sources, assessing the implications under Articles 22A to 22D UK GDPR (inserted by the Data (Use and Access) Act 2025) of solely automated decision-making.
Reviewed and updated existing DPIAs for a health-tech company following changes to its data processing operations, ensuring continued compliance with the ICO’s screening criteria.
Advised a public sector body on the interaction between the DPIA obligation and the Equality Act 2010 public sector equality duty in the context of algorithmic decision-making.

Rob Bratby has conducted and advised on DPIAs for telecoms, payments and technology businesses, including in his General Counsel roles. The Lexology Index recognises Rob Bratby as a Global Elite Thought Leader for telecoms and media, and as a Thought Leader for data privacy and protection.

Related data protection pages

See also our other data protection pages:

Data Protection
UK GDPR Compliance
Lawful Basis and Legitimate Interests
Data Governance, Transfers and Accountability
UK/EU Data Protection Divergence
AI and Automated Decision-Making
The EU AI Act: what UK businesses need to know
Sector-Specific Data Protection
Data Breach Response and ICO Notification
PECR and ePrivacy

Independent directory rankings

Our specialist expertise is recognised in major independent legal directories:

Chambers & Partners: Rob Bratby is ranked as a Band 2 lawyer in the UK Guide 2026 in the “Telecommunications” category: Chambers
The Legal 500: Rob Bratby is listed as a Leading Partner for Telecoms in London (TMT: IT and Telecoms). The Legal 500
Lexology: Rob Bratby is recognised in the Lexology Index as a Global Elite Thought Leader for telecoms and media, and as a Thought Leader for data privacy and protection: Lexology