Data Governance Atlas

Data protection impact assessments that are worth doing

For the controller / DPO

When a DPIA is genuinely required rather than merely prudent, how to scope one so it is useful, what makes a DPIA worthless, and who has to own the outcome.

NIST PF ID-PGV-P
ISO 27701 A.7.2.5
GDPR family Art 35Art 36

Required, or merely a good idea?

A DPIADPIAA structured risk assessment required before high-risk processing — new technologies, large-scale monitoring, sensitive data at scale. is a structured assessment of how a processing operation affects the rights of the people whose data is involved, and what you will do about the risks it surfaces. Most regimes make it mandatory for a defined band of high-risk processing and advisable for everything ambitious. Knowing which side of the line you are on matters, because a missed mandatory DPIA is itself an infringement, independent of whether anything goes wrong.

The mandatory triggers are broadly convergent. Under the GDPR (Article 35) a DPIA is required where processing is “likely to result in a high risk”, and in particular for: systematic and extensive automated evaluation or profilingProfilingUpdate: UK automated-decision rules moved from an Art 22 prohibition to a safeguards regime (Arts 22A-22D) in force 2026-02-05. with legal or similarly significant effects; large-scale processing of special category (sensitive) data; and large-scale systematic monitoring of a publicly accessible area. Supervisory authorities publish lists that add to this. As a rule of thumb, if two or more risk factors combine — new technology, sensitive data, vulnerable individuals, large scale, invisible processing — assume a DPIA is required and reason your way out only if you can.

Scope it around the processing, not the org chart

The most common scoping mistake is running a DPIA at the wrong altitude. A DPIA is about a specific processing operation or a set of closely similar ones — this new recruitment-screening tool, this CCTV deployment, this data-sharing arrangement. It is not a department-wide audit and not a one-off box-tick for “the CRM”. Define:

  • the processing, its purposes, and the data flows (who touches what, where it goes, who it is shared with);
  • necessity and proportionality — could you achieve the purpose with less data, or a less intrusive method?
  • the risks to individuals (not to the organisation) and their severity and likelihood;
  • the mitigations, and the residual risk after them.

Consult stakeholders whose view actually changes the answer — the DPO, security, the people who will operate the system, and, where appropriate, representatives of the affected individuals.

What makes a DPIA worthless

Three failure modes recur:

  1. It is written after the decision. A DPIA produced to justify a system already bought and built is theatre. Its entire value is that it can still change the design. Do it early enough to say “no” or “not like this”.
  2. It records risks but no owner or action. A risk with no mitigation, no owner and no deadline is a liability you have now documented against yourself.
  3. It measures risk to the business, not to people. Reputational and regulatory risk to the organisation is a by-product; the assessment is supposed to be about intrusion, discrimination, loss of control and harm to individuals. Get that backwards and you will mitigate the wrong things.

Prior consultation and the hard stop

If, after mitigation, the residual risk is still high, most regimes require you to consult the supervisory authority before starting (GDPR Article 36). That is a signal, not a formality: reaching that point usually means the design is wrong. Treat “we would have to consult the regulator” as a prompt to redesign.

Who signs it off

A DPIA is not the DPO’s document to approve — it is the DPO’s document to advise on. Accountability sits with the controllerControllerDecides why and how personal data is processed. Carries most of the duties — and the fines., which in practice means a senior decision-maker who can accept residual risk on the organisation’s behalf and authorise (or refuse) the processing. The DPO gives an opinion and monitors; someone with authority signs. If nobody senior is willing to put their name to the residual risk, that is your answer.

Keep it alive

Processing changes; so does risk. Re-run or revisit the DPIA when the purpose, scope, technology or data changes materially — and at a sensible cadence for long-running high-risk processing. A DPIA that describes a system as it was two redesigns ago is documentation of a system you no longer operate.

How this differs elsewhere

No departures recorded for this concept yet. That is not a finding. It means nobody has checked, not that the position is the same everywhere — see the coverage note on the governance index.

Sources

Last verified 26 July 2026