← Insights

Data protection

When you must run a DPIA, and how to do it properly

July 2026 · 6 min read

A Data Protection Impact Assessment is one of those obligations that people either over-run out of nervousness or skip out of ignorance, and both cost you. Skip one you needed and you have a gap the ICO can point to; run one on every trivial change and the process gets a reputation for slowing everything down, so people route around it. The skill is knowing exactly when the law demands one, then doing it with enough rigour that the document defends the decision on its own.

Under UK GDPR Article 35 a DPIA is required whenever a type of processing is likely to result in a high risk to the rights and freedoms of individuals. That is the whole test, and the word doing the work is "likely" - you assess the risk before you build, not after something goes wrong.

What actually triggers one

You do not have to guess. The regulator publishes a list of criteria, and in practice a DPIA is expected whenever your processing hits one or more of them. The common triggers:

• Systematic and extensive profiling with significant effects - automated decisions that shape whether someone gets credit, a job, or a service.
• Large-scale processing of special category data - health, biometrics, ethnicity, or criminal-offence data held at volume.
• Systematic monitoring of a public area - CCTV, tracking, or anything that observes people who did not choose to be observed.
• New technologies whose privacy implications are not yet well understood, and combining or matching datasets in ways the individual would not expect.
• Processing that could deny someone a service or a right, and data about vulnerable people including children and employees.

The honest rule of thumb: if you are launching a new system, starting a new use of personal data, or doing something at a scale you have not done before, screen it. A quick screening step that returns "no DPIA needed, here is why" is itself a useful record - it shows you considered the question.

The screening step

Screening is a short set of yes or no questions drawn from the high-risk criteria. Any single yes means a full DPIA is required. This is deliberately a low bar, because the assessment is cheap relative to getting the risk wrong. Run the screening at the design stage, while decisions are still cheap to change - a DPIA that arrives the week before go-live can only rubber-stamp choices already made, which is the opposite of its purpose.

Record the screening even when the answer is no. "We asked, none of the criteria applied, dated and signed" is a far stronger position than a silence you have to reconstruct later.

Describing the processing

Article 35(7) sets out what a DPIA must contain, and it is best treated as a set of headed sections you fill in rather than a free essay:

• Nature, scope, context and purposes - what data, whose, how much, how long, why, and who it is shared with. Be specific; vagueness here hides the risk.
• Necessity and proportionality - is this processing actually needed for the purpose, or could you achieve the same outcome with less data? This is where you justify the lawful basis and show you considered a lighter-touch option.
• Consultation - who you asked, including, where appropriate, the people whose data it is.

Scoring the risk twice

The part that separates a real DPIA from a form is scoring each risk to individuals on a likelihood-by-severity scale, then scoring it again after your mitigations are in place. The second score is the point of the whole exercise. A risk that starts high and lands low tells you your controls are earning their keep; a risk that barely moves tells you the mitigation is decorative and you need a better one before you proceed.

Score risks to individuals, not to the business. The fine is a business risk; the harm to a person whose data leaks is the thing Article 35 is about. Keep the two straight and the assessment stays honest.

Recording the decision

A DPIA ends in a decision, and the decision needs an owner. Record the DPO's advice, the residual risk that remains after mitigation, who accepted that residual risk, and the date. If any residual risk is still high after everything you can reasonably do, that is the trigger to consult the ICO before you start - the DPIA is the document that shows you reached that point deliberately rather than blundering past it.

A DPIA is finished when every identified risk has a before score, an after score, a named mitigation, and a signed decision that someone owns.

None of this needs a consultant for a straightforward system. It needs a structure that carries you from the screening question through to sign-off without leaving a section out, and the discipline to score the after-mitigation risk honestly. A DPIA does not replace legal or professional judgement on a genuinely novel or high-stakes processing activity - for those, get your DPO or a solicitor across it. But for the everyday new-system assessment, a good structure gets you most of the way in an afternoon.