A Data Protection Impact Assessment (DPIA) is a structured way to identify and reduce the privacy risks of a project before it goes live. It's the mechanism that turns "we should think about privacy" into a documented, defensible decision. Done well, it prevents expensive mistakes and produces exactly the evidence a regulator or customer will later ask for. Done as a box-tick, it's paperwork that protects no one.

When you need one

A DPIA is warranted whenever processing is likely to result in a high risk to individuals. In practice, that includes:

Large-scale processing of personal data, especially sensitive categories.
Systematic monitoring — tracking behaviour, location, or activity.
New technologies whose privacy impact isn't yet well understood, including AI systems that make or support decisions about people.
Automated decision-making that has a significant effect on individuals.
Combining or matching datasets in ways individuals wouldn't reasonably expect.

If a project touches more than one of these, treat a DPIA as required, not optional. When in doubt, a short screening assessment tells you whether a full DPIA is needed — and documents that you asked the question.

The steps

1. Describe the processing. What data, from whom, why, how it flows, how long you keep it, and who it's shared with. This is the factual base; the rest of the assessment depends on getting it accurate.

2. Assess necessity and proportionality. Do you actually need this data for the stated purpose, or is it convenient to collect? Is there a less intrusive way to achieve the same goal? A DPIA that never questions whether the processing should happen at all is missing its most valuable step.

3. Identify the risks to individuals. Think from the person's perspective, not the organisation's. What could go wrong for them — unwanted exposure, discrimination, loss of control, unexpected decisions? Rate each by likelihood and severity.

4. Identify measures to reduce the risks. For each material risk, decide what mitigates it — minimisation, encryption, access controls, retention limits, transparency, human review of automated decisions. Record which risks are reduced, which are accepted, and why.

5. Record the outcome and sign off. Document the residual risk and get a named owner to approve proceeding. If high risks remain that you can't mitigate, that's the signal to consult your regulator before going ahead.

The mistake that undoes the work

The most common DPIA failure isn't a bad assessment — it's a stale one. A DPIA describes a project at a moment in time. Projects change: scope expands, new data sources get added, a model gets repurposed. A DPIA completed at kickoff and never revisited describes a system that no longer exists, and offers no protection against the risks the current version introduced.

A DPIA should be a living record, revisited when the processing materially changes. Tie it to the thing it assesses so that when the project shifts, the assessment is flagged for review rather than silently going out of date.

The self-check

For your higher-risk processing, does a DPIA exist — and is it current?
Did it genuinely test necessity, or assume the processing was going ahead?
Are the risks framed from the individual's perspective?
Is each DPIA tied to its project so it gets revisited when scope changes?

Where CompliSense-AI fits

DPIAs decay because they live in documents disconnected from the systems they assess. CompliSense-AI keeps each assessment tied to the processing it covers, with an owner and a trigger to revisit it when the underlying system changes — so your DPIAs stay current and defensible instead of describing a project as it was a year ago.

See how your programme scores overall with the free readiness tool, and pair this with the DPDP readiness guide.