Data Protection Impact Assessment: the ICO's 7 Steps

A data protection impact assessment is not a form you fill in after the fact. Under Article 35(1) of the UK GDPR it is a legal obligation that bites before you start processing, whenever a type of processing "is likely to result in a high risk to the rights and freedoms of natural persons". The Information Commissioner's Office sets out a seven-step process for doing one, a list of ten processing operations that trigger it, and a hard rule for what happens when a high risk survives your mitigations. This guide walks through all three, and it matters more than usual in 2026, because the Data (Use and Access) Act has put the ICO's own DPIA guidance under review.

The general rule, and what "high risk" actually means

Article 35(1) is the source: "Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data."

Two words in that sentence do most of the work. "Prior" means before, not alongside and certainly not after go-live. And "likely to result in" sets a screening test, not a conclusion. As the ICO puts it, the question at this stage "is not whether the processing is actually high risk or likely to result in harm, that is the job of the DPIA itself to assess in detail". You are looking for red flags, not proving harm.

Risk here means the potential for significant physical, material or non-material harm to individuals, judged on both the likelihood and the severity of that harm. A single assessment can cover a set of similar processing operations presenting similar risks, so you do not need a separate DPIA for every campaign that uses the same pipeline.

When a DPIA is legally required

The three automatic triggers in Article 35(3)

• Systematic and extensive profiling with significant effects: automated evaluation of personal aspects on which decisions are based that produce legal effects or similarly significantly affect the person.
• Large scale use of sensitive data: special category data under Article 9(1), or criminal offence data under Article 10.
• Public monitoring: systematic monitoring of a publicly accessible area on a large scale.

The ICO's list of ten

Article 35(4) requires the ICO to publish its own list, and it has ten entries. Some require a DPIA on their own; others require one when combined with a criterion from the European guidelines below.

1. Innovative technology, including AI, or a novel application of existing technology. In combination.
2. Denial of service: decisions about access to a product, service, opportunity or benefit based to any extent on automated decision-making or involving special category data.
3. Large-scale profiling of individuals.
4. Biometrics: any processing of biometric data. In combination.
5. Genetic data, other than by an individual GP or health professional providing care direct to the patient. In combination.
6. Data matching: combining, comparing or matching personal data from multiple sources.
7. Invisible processing: personal data not obtained from the individual where you consider Article 14 compliance impossible or disproportionate. In combination.
8. Tracking of geolocation or behaviour, online or offline. In combination.
9. Targeting of children or other vulnerable individuals for marketing, profiling or automated decision-making, or offering online services directly to children.
10. Risk of physical harm, where a breach could jeopardise the physical health or safety of individuals.

The nine European criteria

The Article 29 working party published nine indicators, endorsed by the European Data Protection Board: evaluation or scoring; automated decision-making with legal or similar significant effect; systematic monitoring; sensitive or highly personal data; data processed on a large scale; matching or combining datasets; data concerning vulnerable subjects; innovative use of new technological or organisational solutions; and preventing people from exercising a right or using a service or contract.

The rule of thumb is that a combination of two of these indicates the need for a DPIA. That is not absolute. You can justify a decision not to do one if you are confident the processing is nevertheless unlikely to be high risk, provided you document your reasons. Sometimes a single factor is enough. The ICO's own position is that if you are in any doubt, do the DPIA.

The seven steps

The ICO's process is deliberately scalable. It should begin early in the life of a project and run alongside development rather than waiting for a finished design.

Step 1: Identify the need

Ask your data protection officer first if you have one. Screen against the automatic triggers, the ICO's ten and the European criteria. If you decide a DPIA is not needed, document that decision and the reasons, including the DPO's advice. The ICO is explicit that this "does not have to be a burdensome paperwork exercise"; an annotated copy of the screening checklist is enough.

Step 2: Describe the processing

Your description must cover "the nature, scope, context and purposes of the processing". Nature is what you plan to do with the data: how you collect, store, use and share it, who has access, whether processors are involved, retention periods, security measures and which screening criteria you flagged. Scope is what it covers: the type, volume, variety and sensitivity of the data, the frequency and duration, the number of people affected and the geography. Context is the wider picture, including the source of the data and people's reasonable expectations. Purposes are why you are doing it at all.

Step 3: Consider consultation

Consult individuals, or their representatives, where appropriate, and record why if you decide not to. Internally, involve the business owner of the project, your DPO, information security, any processors and legal or specialist advisers.

Step 4: Assess necessity and proportionality

This is the step organisations skip, and it is the one regulators read first. Could you achieve the same outcome with less data, shorter retention or a less intrusive method? If yes, the current design is not necessary, and the DPIA should say so.

Step 5: Identify and assess risks

Score each risk on likelihood and severity of harm to individuals, not harm to the organisation. Reputational damage to you is not the test.

Step 6: Identify mitigating measures

Then re-score. What remains after mitigation is the residual risk, and it decides what happens next.

Step 7: Sign off and record

Record the outcome, the DPO's advice and, where you did not follow that advice, your reasons. Integrate the outcomes back into the project plan and keep the DPIA under review as the processing changes.

The DPO's role, and who is responsible

You can decide internally who carries out DPIAs and who signs them off, and you can outsource the work to a consultancy or ask a processor to do it, but you remain responsible for it either way. If you have a DPO you must seek their advice, and document it. Under Article 39 the DPO has specific tasks in relation to DPIAs, and Recital 97 requires them to act independently, so do not hand a DPO operational ownership of the project they are meant to be advising on. DPOs must also monitor how well the agreed measures are actually implemented, not just whether they were written down.

When a high risk survives: prior consultation with the ICO

If your DPIA identifies a high risk and you cannot do anything to reduce it, prior consultation is mandatory. The ICO is direct about the consequence: "You cannot go ahead with the processing until you have consulted us." If you mitigated the risk so that it is no longer high, you do not need to consult.

Your submission must include the roles and responsibilities of any joint controllers or processors, the purposes and methods of the intended processing, the measures and safeguards protecting individuals, your DPO's contact details, and the DPIA itself.

The timetable is published:

• The ICO writes within 10 days to say whether it has accepted your DPIA for prior consultation, with reasons.
• Where it advises under prior consultation, it responds within 8 weeks of receipt.
• In complex cases that can extend to a maximum of 14 weeks, and the ICO must tell you within one month of submission if it is extending.
• If your processing affects people in EU member states, co-operation with other authorities may push it past 14 weeks.

Outcomes range from advice on further mitigation, through an official warning where the ICO is concerned the processing is likely to contravene the UK GDPR, to a limitation or a ban on the intended processing. Warnings cannot be appealed, though you can seek judicial review of how the decision was made; limitations and bans can be appealed to the First-tier Tribunal.

The 2026 caveat: the Data (Use and Access) Act

Every page of the ICO's DPIA guidance currently carries the same notice: because of changes made by the Data (Use and Access) Act, the guidance is under review and may be subject to change. The seven-step method and the statutory triggers are stable, but if you are writing an internal DPIA policy this year, build in a review point rather than hard-coding paragraph references, and check the ICO's plans for new and updated guidance before you publish it.

Making it useful rather than performative

A DPIA earns its keep when it changes the design. If every assessment your organisation produces concludes that the processing was fine as originally proposed, the process is decorative. Three practical habits help: start at the point the idea is still cheap to change, put the necessity question in front of the risk register rather than after it, and give the DPIA an owner who is allowed to say no. That is the same governance discipline described in our guides to building an AI governance framework and corporate compliance, and it is what separates a compliance artefact from a control that works.

For the wider picture of how this fits alongside your code and your ethical decision-making process, start from our business ethics pillar, or browse everything on the e-Business Ethics homepage.

Frequently Asked Questions

When is a DPIA legally required?

Whenever a type of processing is likely to result in a high risk to individuals' rights and freedoms, under Article 35(1) of the UK GDPR. Article 35(3) makes three types automatic: systematic and extensive profiling with significant effects, large-scale use of special category or criminal offence data, and systematic monitoring of a publicly accessible area on a large scale. The ICO publishes a further list of ten.

What must a DPIA contain?

A description of the processing covering its nature, scope, context and purposes; an assessment of necessity and proportionality; an assessment of the risks to individuals; and the measures you will take to address those risks. The ICO's seven-step process adds consultation, sign-off and keeping the assessment under review.

Do I have to consult the ICO after a DPIA?

Only if a high risk remains after your mitigations. The test is the residual risk. Where it does remain high, prior consultation is mandatory and you cannot begin the processing until you have consulted.

How long does ICO prior consultation take?

The ICO confirms within 10 days whether it has accepted your DPIA for prior consultation, and gives written advice within 8 weeks of receipt. In complex cases that can extend to a maximum of 14 weeks, and it must tell you within one month of submission if it is extending.

Can I outsource a DPIA?

Yes. You can outsource it, or ask a processor to carry one out on your behalf, but you remain responsible for it. If you have a data protection officer you must seek their advice and document it, and record your reasons if you do not follow it.

Is the ICO's DPIA guidance changing?

It is under review. Every page of the current guidance carries a notice that changes made by the Data (Use and Access) Act mean it may be subject to change. The statutory triggers and the seven-step method are stable, but check the ICO's plans for updated guidance before writing paragraph references into an internal policy.

Sources

• ICO guidance, Data Protection Impact Assessments, including when a DPIA is needed, how to do one and prior consultation: ico.org.uk
• UK GDPR Article 35 (data protection impact assessment): legislation.gov.uk

Checked on 5 September 2026. The ICO's DPIA guidance is under review following the Data (Use and Access) Act, so verify against the live guidance before relying on paragraph-level detail.