When Is a DPIA Required and How to Do One

A Data Protection Impact Assessment is the one GDPR document with a statutory deadline of "before". Before the biometric readers are installed. Before the monitoring tool goes live. Before the contract is signed. Miss that timing and no amount of retrospective paperwork fixes it, because the entire point of Article 35 is to change the processing while it can still be changed.

In July 2024 the ICO reprimanded Chelmer Valley High School in Essex for exactly this: the school switched its canteen payments to facial recognition and only thought about a DPIA afterwards. The technology worked fine. The compliance failure was the sequencing.

This guide covers when a DPIA is mandatory, what one actually contains, and where they go wrong in practice. If you want the wider context on how DPIAs sit alongside your other GDPR obligations, start with RoPA vs DPIA vs DSAR.

The law names three triggers. The ICO's list is longer.

Article 35(3) makes a DPIA mandatory in three situations: systematic and extensive profiling that produces legal or similarly significant effects, large-scale processing of special category or criminal offence data, and systematic monitoring of publicly accessible areas at scale.

Those three are the floor, not the test. The general rule in Article 35(1) is that any processing "likely to result in a high risk to the rights and freedoms of natural persons" needs an assessment, and the ICO has published a list under Article 35(4) of processing types where it expects one: innovative technology, biometric or genetic data, invisible processing, data matching, tracking of location or behaviour, decisions that deny people a service or benefit, and processing that targets children or other vulnerable people.

The practical shortcut comes from the European guidelines the ICO adopted. They set out nine risk indicators, including evaluation and scoring, sensitive data, large scale, matching datasets, and innovative use. Hit two or more, and you should assume a DPIA is required. One alone can be enough.

Screening is a half-hour job, do it every time

Because "likely to result in a high risk" is a judgement, the ICO provides a screening checklist that turns it into a short structured exercise: a page of yes/no questions against the trigger list. It is worth running for every new project, vendor, or system that touches personal data, for two reasons.

First, it is cheap insurance. Thirty minutes at project kickoff versus retrofitting an assessment after launch.

Second, a documented "no" is itself an accountability artefact. If the ICO asks why you did not conduct a DPIA for a given activity, a dated screening record showing the reasoning is a defensible answer. Silence is not.

The screening only works if it fires at the right moment, which means wiring it into the events that create new processing: procurement signing a vendor, IT onboarding a SaaS tool, a product team scoping a feature. The same update triggers that keep your Record of Processing Activities current should raise the DPIA question too.

The document has four parts, and necessity does the heavy lifting

Article 35(7) prescribes the minimum content, which resolves into four working sections.

A systematic description of the processing. What data, from whom, flowing where, stored how long, shared with which recipients, under which transfer safeguards. If your Article 30 records are current, this section is largely an extract rather than an investigation.

An assessment of necessity and proportionality. This is where weak DPIAs collapse. It is not enough to assert that the processing serves a legitimate purpose. You have to show why less intrusive alternatives are insufficient, and that the data collected is the minimum the purpose requires. A regulator reading this section is asking one question: did anyone genuinely consider not doing this?

Identification of risks to individuals. Not risks to the organisation. Risks to the people in the data: discrimination, financial loss, identity theft, loss of control, chilling effects. Rate each for likelihood and severity, and write the harm concretely enough that a mitigation can be tested against it.

Measures to address those risks. Specific controls mapped to specific risks, with the residual risk stated after each. Encryption, retention limits, access controls, human review of automated decisions, an alternative route for people who decline. Vague mitigations ("appropriate technical measures") signal that the risk analysis was vague too.

You must also seek the views of your DPO if you have one, and, where appropriate, of the people affected or their representatives. Skipping consultation was one of the specific failures the ICO cited at Chelmer Valley.

A worked example: fingerprint entry at head office

A 120-person financial services firm wants to replace keycards with fingerprint readers, using Suprema hardware integrated with its Paxton Net2 access control system. Keycards get shared and lost; the firm wants certainty about who entered the building.

Screening takes minutes. Biometric data used to uniquely identify people is special category data under Article 9 and sits explicitly on the ICO's Article 35(4) list. DPIA required, before any hardware is ordered.

The description section establishes facts that change the risk picture: the readers store mathematical templates, not fingerprint images; templates live on the local controller, not in the cloud; enrolment happens in the office; templates are deleted through the leaver process.

Necessity is the hard section, and honestly so. Is biometric entry necessary, or merely convenient? Keycards with PINs address most of the pass-sharing problem at zero intrusion. The firm's defensible answer is narrower than its starting ambition: biometrics for the server room and client-file archive, keycard-plus-PIN for general access. The DPIA changed the design. That is it working.

Risks: a template breach is irrevocable, because nobody can reissue a fingerprint; consent is unreliable as a basis given the employer-employee power imbalance; and function creep looms, since the same logs that control access can silently become attendance monitoring. Mitigations: encrypted on-device templates, a genuinely equivalent alternative for staff who decline, a documented purpose limitation excluding time-and-attendance use, and deletion tied to offboarding.

Residual risk after mitigation: low. Processing can begin, with a review trigger if scope ever widens.

If residual risk stays high, the ICO comes before the launch

Suppose the mitigations had not worked, and the assessment ended with high residual risk the firm could not reduce. Article 36 then requires prior consultation with the ICO before processing starts. The ICO has up to eight weeks to respond, extendable by six more, and can advise, warn, or in serious cases block the processing.

In practice, prior consultation is rare, because most projects can be redesigned until residual risk is acceptable. But the route exists precisely so that "we could not make it safe" leads to a conversation with the regulator rather than a quiet launch. Proceeding with an unmitigated high-risk assessment on file is the worst position available: documented knowledge of the risk, and processing anyway.

The RoPA tells you what you do. The DPIA tells you whether you should.

The two documents are often confused and genuinely symbiotic. Your RoPA is the factual register of processing as it exists. The DPIA is the evaluative judgement applied to one activity before it exists.

A current RoPA collapses the discovery phase of every DPIA, because the data categories, recipients, transfers, and retention periods are already recorded. A completed DPIA feeds back the other way: the new activity, its safeguards, and its retention rules become RoPA entries. Teams that maintain one document well tend to produce the other quickly. Teams with a stale register start every DPIA with an archaeology project.

Jersey and the AI Act have made the obligation wider, not different

Two extensions matter in 2026.

If you operate in Jersey, the Data Protection (Jersey) Law 2018 imposes the same obligation under Articles 16 and 17: a DPIA before high-risk processing, and prior consultation with the Jersey Office of the Information Commissioner where residual risk stays high. Channel Islands firms serving EU clients frequently owe both regulators the same document.

And since 2 August 2026, the EU AI Act's obligations for high-risk AI systems apply. Article 26(9) explicitly requires deployers of high-risk AI to use the provider's technical documentation to carry out their GDPR DPIA. The two regimes now interlock: the AI Act tells you the system is high-risk, and Article 35 tells you what to do about it. For what AI-specific assessment actually involves, see AI and DPIAs: a new frontier.

Where DPIAs actually fail

Rarely in the drafting. The recurring failures are structural.

The assessment happens after implementation, when the budget is spent and the design is frozen, so no finding can change anything. Chelmer Valley again, and the Swedish school authority fined in 2019 for trialling facial recognition on students first and assessing later.

Or it is treated as a form to complete rather than a decision to make. A DPIA whose necessity section could not conceivably have concluded "do not proceed" is a compliance artefact in the worst sense.

Or it is never revisited. Article 35(11) requires review when the nature, scope, context, or purposes of processing change. The access-control system that quietly starts feeding attendance reports has changed purpose, and the two-year-old DPIA no longer covers it.

All three failures share a root cause: the DPIA lived in a document, disconnected from the processing it assessed. Nothing in a Word file on SharePoint notices that the processing changed.

That connection is the problem Clarium is built around. Because the DPIA draws its processing description from the same live register that powers your RoPA and data-flow maps, the discovery phase is an extract instead of an investigation, and a change to the underlying processing is visible against the assessment that relied on it. DPIA support is included on the Pro tier. See pricing.