What is a DPIA?
Most assessments of a new system ask whether it will work. A DPIA asks a stranger and more useful question: whom could it hurt? A Data Protection Impact Assessment is GDPR’s mechanism for making an organisation think about harm to the people in the data before the processing exists, while the answer can still change the design. That timing is the whole point, and it is the first thing lost when the DPIA becomes a form to fill in.
When one is needed
The trigger is risk to people, not risk to the organisation. A DPIA is required where processing is likely to result in a high risk to the rights and freedoms of individuals, and the recognised signals are worth internalising because they describe much of what a modern people business builds: new or unfamiliar technology whose behaviour is not yet well understood, systematic monitoring of people at work or in public, large-scale processing of sensitive data, automated decisions with significant effects on individuals, matching datasets that were collected separately, and processing that touches people who are less able to push back, a description that often includes employees, given the power imbalance at work. Regulators publish authoritative lists of processing that always needs one, and this entry is orientation rather than legal advice. The practical habit is simpler than the criteria: ask the question at the start of every new data project, and let a short screening note record why the answer was no.
What a useful one contains, and what an artefact contains
The regulation sketches the contents: a description of the processing, an assessment of necessity and proportionality, the risks to individuals, and the measures that address them. A useful DPIA takes each seriously. The description is concrete enough that someone could object to it: what data, whose, flowing where, visible to whom. The necessity test has teeth, because it asks whether the purpose could be met with less, which is data minimisation applied before the fact. The risks are harms to named categories of people, not reputational risk to the company. And the measures change the design: narrower collection, shorter retention, aggregation, a human gate. The compliance artefact has the same headings and none of the force. It is written after procurement has signed, its risks are copied from the last one, its mitigations were already in the plan, and it ends in a drawer. A DPIA that cannot change anything is not an assessment of a decision. It is a record of one.
A pre-mortem for data risk
The best mental model for a DPIA already exists in decision science: the pre-mortem, in which a team assumes the plan has already failed and writes the story of why, because people generate far richer causes for a definite event than for a hypothetical one. A DPIA is the same move aimed at data harm. Assume it is eighteen months from now and this processing has genuinely hurt someone: a candidate, an agent, a client contact. What happened? The stories that come back are concrete in a way risk registers never are: the access that was wider than anyone remembered granting, the retention nobody set, the score that quietly became a decision, the export that left the tenant. Each story is a design change available today at the price of a paragraph.
One concrete example
Clearly illustrative, with no customer implied. A BPO plans analytics over agent activity data: schedules, handle times, quality scores. The artefact version arrives after the vendor is chosen, lists generic risks, and is filed. The pre-mortem version runs before the pilot. The team assumes an agent has been harmed and writes the stories: performance data fed into a dismissal with no human ever reviewing the underlying numbers; monitoring that crept from work time into breaks; individual scores visible to peers; data kept for years and surfacing in a reference. Each story becomes a change while change is cheap: aggregate views where the purpose allows them, explicit purpose limits in the vendor contract, short retention, a human review gate before any consequence reaches a person, and plain-language notice to the people being measured. The system that ships is narrower than the one first imagined, and the DPIA is the record of why, which is exactly what a regulator, a works council or a client audit will one day want to read.
The DPIA and decision intelligence
Strip the legal frame away and a DPIA is a decision artefact: evidence about a planned commitment, options for reducing its harm, a choice with an owner, and a duty to revisit when the facts change. That is the shape decision intelligence gives every consequential call, and the DPIA benefits from the same disciplines: assumptions carried with their quality on the evidence hierarchy, so a risk everyone merely stated looks different from one that was measured; the decision and its reasoning kept where the next person can find them; and the human gates the DPIA promises built as real human-in-the-loop controls rather than approval theatre. The wider obligations a DPIA sits among are covered in GDPR for BPOs.
Common questions
What is a DPIA?
A Data Protection Impact Assessment is a structured exercise, required by GDPR where processing is likely to pose a high risk to individuals, that describes a planned use of personal data, tests whether it is necessary and proportionate, identifies the risks to the people whose data is involved, and sets out the measures that will reduce them. Done well, it changes the design of the processing before it begins. Done badly, it documents a decision that was already made.
When is a DPIA needed?
Whenever processing is likely to result in a high risk to individuals, judged before it begins. The recognised signals include new or unfamiliar technology, systematic monitoring of people, large-scale processing of sensitive data, automated decisions with significant effects, matching or combining datasets, and processing that involves people less able to protect their own interests. Regulators publish authoritative lists of processing that always requires one; this answer is orientation, not legal advice.
What should a DPIA contain?
A plain description of the processing: what data, whose, where it flows, who sees it. An assessment of necessity and proportionality: whether the purpose could be achieved with less. The risks to the individuals concerned, named concretely rather than generically. The measures that reduce those risks, and the residual risk that remains. And a real decision with an owner: proceed, change the design, or consult the regulator. It should be revisited whenever the processing changes.
What is the difference between a useful DPIA and a compliance artefact?
Timing and consequence. A useful DPIA happens early enough to change the design, names specific harms to specific people, and leaves fingerprints: things the project did differently because of it. A compliance artefact is written after the decision has effectively been made, lists generic risks copied from a template, records mitigations that were already planned, and is filed where nobody will read it again. The document can look identical; the difference is whether anything was still changeable when it was written.