DPIAs: When You Actually Need One

Most organisations either skip Data Protection Impact Assessments entirely, betting nobody will ask, or run one for every project regardless of actual risk, burning genuine assessment effort on low-stakes processing that never needed the scrutiny. Both mistakes come from the same root cause: not actually knowing the trigger, and defaulting to a guess instead.

I’ve written about GDPR as an architecture constraint generally. A DPIA is the specific procedural mechanism GDPR uses to force a genuine risk assessment before high-risk processing begins, and the trigger for needing one is more precise than most organisations’ internal guidance reflects.

The actual trigger, stated precisely

GDPR requires a DPIA where processing is “likely to result in a high risk to the rights and freedoms of natural persons” — a deliberately open standard, narrowed by specific criteria that supervisory authorities have elaborated consistently across guidance: systematic and extensive profiling with legal or similarly significant effects, large-scale processing of special category data, systematic monitoring of a publicly accessible area at scale, or processing that combines several risk factors simultaneously even where no single factor alone would clearly trigger the requirement.

The practical test that captures most of this cleanly: does the processing use new technology, involve profiling that produces legal or similarly significant effects, process special category data at meaningful scale, or systematically monitor people. Two or more of these factors present together is a strong signal a DPIA is required even if any single factor alone might be borderline.

Where organisations actually get this wrong

Assuming a DPIA is only for obviously sensitive sectors. A retail loyalty programme using purchase history to build detailed behavioural profiles for automated marketing decisions can trigger the requirement just as clearly as a healthcare system processing medical records — the trigger is about the nature and scale of the processing and its effect on individuals, not the sector’s superficial sensitivity.

Assuming AI deployment automatically requires one, or automatically doesn’t. An AI system making or materially influencing decisions about individuals — the AI Act’s own high-risk categories overlap significantly here — very often triggers the DPIA requirement through the profiling and automated-decision-effect criteria, but not every AI use case does; a narrow, low-stakes internal tool processing no personal data at meaningful scale may not trigger it at all, and treating every AI project identically wastes genuine assessment effort on ones that don’t need it.

Treating the DPIA as a one-time gate rather than a living document. A DPIA completed at a project’s launch and never revisited misses exactly the risk this piece is about — processing that expands, a new data source added, a new use case layered on afterward — each of which can shift the answer to whether high risk is actually present, requiring the assessment to be genuinely revisited, not assumed permanently settled by the original sign-off.

What a genuine DPIA actually requires, beyond the paperwork

A DPIA done properly is a genuine risk assessment, not a form completed to satisfy a compliance checklist — describing the processing, assessing necessity and proportionality, identifying risks to individuals specifically, and documenting the measures that mitigate those risks, with a genuine, considered answer rather than boilerplate language copied from a template. This connects directly to the evidence-generated-not-assembled discipline I’ve written about generally: a DPIA assembled hastily to satisfy an audit is a weaker document, and a weaker defence, than one that reflects genuine consideration done as the processing was actually designed.

Where the trigger question actually mattered

An insurance firm rolling out an AI-assisted underwriting tool initially assumed a DPIA wasn’t required, since the tool only “assisted” a human underwriter rather than deciding automatically. Closer analysis found the tool’s risk score carried enough practical weight in the underwriter’s actual decision-making — confirmed by interviewing underwriters about how they genuinely used it — that it met the profiling-with-significant-effects criterion regardless of the nominal human-in-the-loop framing. Running the DPIA the firm had initially thought unnecessary surfaced two genuine risk-mitigation gaps in the tool’s design, caught well before a regulator or a complainant might have found them instead.

Determining which current or planned processing activities genuinely trigger a DPIA requirement — and running a genuine assessment rather than a template exercise — is exactly the kind of compliance work a technology control assessment is built to support.

The cost of running an unnecessary DPIA is real but modest — some wasted assessment time. The cost of skipping a genuinely required one is considerably higher, discovered only when a regulator or a complaint forces the question retroactively.

For AI systems specifically, this triggers earlier than most teams expect — see data classification as a prerequisite for AI adoption.

A short, honest triage question at the start of every new processing activity — does this plausibly hit one of the trigger criteria — catches most of the genuine cases without turning every project into a full assessment.