A DPIA sounds like paperwork until the moment you actually need one, and by then it is usually too late to do it properly. If you are building anything that scores, profiles, or makes decisions about people using their data, and increasingly that describes most AI projects, a Data Protection Impact Assessment is the checkpoint that decides whether you launch on schedule or spend the next few months explaining yourself to the ICO.
We work with organisations moving AI from pilot to production, and the DPIA is usually where a project first collides with reality. Engineering wants to ship. Legal wants evidence that privacy was considered properly, not retrofitted after a data protection officer asked awkward questions in a meeting three weeks before launch. Getting this right early costs a few days of proper work. Getting it wrong costs a stalled launch, or a regulatory enquiry that drags on for the best part of a year.
This guide covers what a DPIA actually is, when UK GDPR requires one, what has to be in the document, how to run the process without it turning into theatre, and what changes when the thing you are assessing is an AI model rather than a standard database.
What a DPIA actually is
A Data Protection Impact Assessment is a formal document you write before you start processing personal data in a way that carries real risk to the people behind that data. It is not a form you fill in after the system is already live, to justify a decision that has already been made. It is meant to happen while the project is still changeable, so that if the assessment turns up a genuine problem, you can still fix the design rather than the aftermath.
The document traces how data enters your system, who touches it, where it sits, what could go wrong, and what you are doing to stop that. Done properly, it forces three things to happen. You have to identify the actual risks that your specific processing creates, not generic privacy worries copied out of a template. You have to write down the measures you are putting in place to bring those risks down to something acceptable. And you end up with a paper trail that shows, if a regulator or a worried customer ever asks, that you thought about this before you started rather than after something went wrong.
What it is not
A DPIA does not replace proper security controls, and it is not the same as a general privacy policy sitting on your website. It does not substitute for a legitimate interest assessment either, though the two often overlap and reference each other. It is also not a one-off exercise you clear once and file away. Projects change shape. A model gets retrained on a new dataset, a feature pulls in a data source nobody flagged, a vendor changes how they process something on your behalf. Each of those shifts the risk picture, and the DPIA needs to move with it.
The failure mode we see most often is a DPIA written to justify a decision the team had already made. Someone builds the feature first, then works backwards to produce a document that makes the choice look considered. That is not compliance. It will not hold up if anyone actually reads it closely, and regulators do read closely.
When UK GDPR actually requires one
Article 35 of UK GDPR sets the bar at processing "likely to result in a high risk to the rights and freedoms of natural persons." That phrase is doing a lot of work, and it is deliberately not a fixed checklist. You have to assess your own processing against it rather than waiting to be told.
Three scenarios put you over that bar almost automatically:
- Systematic and extensive profiling that has legal or similarly serious effects on someone. Credit scoring and insurance underwriting are the standard examples, where an automated process makes or heavily informs a decision about a person.
- Large-scale processing of special category data or criminal conviction data: health records, biometric identifiers, genetic information, anything the law treats as needing extra protection, processed at real volume rather than as an edge case.
- Systematic monitoring of public spaces on a large scale, such as CCTV networks that track people across multiple locations rather than a single camera watching a single door.
The ICO also keeps its own list of processing types that always trigger a DPIA regardless of scale, including biometric matching, genetic data used for health purposes, and automated decision-making that seriously affects people. Here is the part teams miss most often: the ICO's list is not exhaustive, and your obligation does not disappear just because your project is not named on it. If the processing meets the high-risk threshold in substance, you need a DPIA whether or not it appears on anyone's official list.
In practice, several factors tend to stack up. Processing that touches vulnerable people, children, patients, anyone in a position of financial dependency, processing that combines multiple risk factors, and processing built on genuinely new technology all push a project over the line faster than any single factor on its own. If your AI system profiles behaviour to make a consequential decision, works with health data at any real scale, or tracks people systematically across services, start the DPIA before anyone touches production code.
What actually has to go in the document
UK GDPR Article 35 sets minimum content requirements, and following them properly matters even though nobody hands you a template that guarantees compliance on its own. A DPIA assembled from generic boilerplate reads as generic boilerplate, and that is the first thing an auditor or a regulator notices.
The description of processing
Start with a plain account of what you are actually doing: the purposes behind the processing, the categories of personal data involved, and who the data belongs to. Trace the flow properly, from the point data enters your system through every hop it takes in storage and processing, to the point it gets deleted. Name the actual technologies and infrastructure. Not "our cloud platform" but the specific services, the specific vendors, the specific retention periods you have set.
Necessity and proportionality
This is the section people skip or fake, and it is the one that matters most. Explain why the processing is genuinely needed to achieve what you are trying to achieve, and whether a less intrusive approach could get you there instead. If the honest answer is "we could do this with less data but chose not to because it was easier," write that down. A DPIA that only ever concludes the processing was necessary, every single time, is not doing its job.
Risk identification and the measures that follow
List the specific risks to people's rights and freedoms that your processing creates: discrimination, financial loss, reputational damage, loss of confidentiality, whatever applies to your case specifically. Rate each one on likelihood and severity, not a gut feeling scribbled in five minutes. Then set out the technical and organisational measures you are putting in place against each risk individually. Encryption, pseudonymisation, access controls, staff training, regular audits, all fine, but list them against the risk they actually address rather than as a general list of things your security team does anyway regardless of this project.
What happens if you skip one
The ICO has the power to fine, and skipping a DPIA where one was legally required is one of the more straightforward things to prove after the fact. There is no ambiguity about whether the paperwork exists. Either the document has a date before the processing started, or it does not.
The direct fines are one part of it. Under UK GDPR the ICO can issue penalties of up to £17.5 million or 4% of global annual turnover, whichever is higher, for the most serious infringements, and a missing or defective DPIA on genuinely high-risk processing sits in that category. In practice most enforcement starts smaller: an information notice, a formal warning, a requirement to pause processing until the assessment is done properly. That last one is the version that actually hurts a live AI product, because "stop processing" for a model already in production can mean pulling a feature customers rely on, with very little notice.
The quieter cost shows up before any regulator gets involved. A DPIA gap tends to surface during procurement, when a prospective enterprise customer's security team asks for evidence of your privacy assessment and you do not have one to send them. Or during due diligence on a funding round or an acquisition, when the absence of a DPIA on a data-heavy product reads as a governance gap to whoever is doing the reviewing. We have seen deals slow down over exactly this, not because the underlying processing was reckless, but because nobody could produce the document proving it had been thought through properly.
Running the assessment, step by step
Screen and scope
Before you write anything, work out whether you need a DPIA at all. Run your planned processing against the ICO's screening questions: new technology, special category data, automated decisions, systematic monitoring. If the answer comes back yes, define the scope properly before you start drafting anything: what data, from where, retained for how long, accessible to whom. Map the data flow end to end, naming every system, every third party, every point where data changes hands.
Assess and challenge
Justify the processing against its purpose, and actually challenge the assumption rather than rubber-stamping it. Could you achieve the same outcome with a smaller dataset, a shorter retention period, or a less invasive method? Write down the answer either way, including when the honest answer is no. Then identify concrete risks specific to what you are actually building, not a generic list of privacy concerns lifted from somewhere else. Rate each by likelihood and severity before you decide what mitigates it.
Document and keep it live
Record every decision, every risk, every mitigation, with dates and named contributors. If you consulted a DPO or a supervisory authority, note when and what came out of it. Then, and this is the step almost everyone drops, revisit the document when the project changes. A DPIA written for version one of a model and never touched again is a DPIA that stopped being true the day the training data changed.
DPIAs for AI and RAG systems
Traditional DPIAs were written for systems where you could trace a straight line from input to output. AI does not always give you that line. A model trained on millions of examples can produce a decision that even its own engineers cannot fully explain, and that changes what a privacy assessment needs to cover for anyone running an AI implementation at any real scale.
Automated decision-making
Document how the model actually reaches a decision, and whether the person affected by it can understand or challenge the outcome. That means tracing the training data itself: where it came from, whether it carries bias that could produce a discriminatory result, and how you would even know if it did. Any system that predicts behaviour, assesses creditworthiness, or determines someone's eligibility for a service sits in high-risk territory by default and needs an assessment before it goes live, not after a complaint arrives.
You also need to cover the training process itself. Does the model use personal data during training? What stops it from memorising individual records and exposing them later through inference? This is a real risk, not a theoretical one. Models can leak training data back out through the right adversarial prompt, and "we did not intend that" is not a defence a regulator finds persuasive. Worth checking too whether the model can infer special category data by proxy. Strip out the obvious identifiers and a model can still reconstruct health status, ethnicity, or sexuality from patterns in features that look entirely innocent on their own.
RAG systems and internal knowledge platforms
Retrieval-augmented generation brings its own version of the problem. These systems combine a language model with an organisation's own data, often documents, tickets, or records that were never built with an AI retrieval layer in mind. The assessment has to cover what the system can retrieve, what it can surface in a generated answer, and who is allowed to ask it questions in the first place.
An internal chatbot that can quietly assemble someone's full HR history from three unrelated documents is a privacy incident waiting to happen, and it will not look like one until it does.
Think about combinations too. A RAG system can surface an inference that was never explicit in any single document it drew from, just by putting two ordinary facts next to each other. That is a kind of risk a traditional keyword search never created, and it deserves its own line in the assessment rather than being waved through under "standard access controls apply."
Where DPIAs go wrong in practice
We see the same handful of mistakes on repeat. The DPIA gets written by one person in isolation, usually someone in legal or compliance, without input from the engineers who actually know how the system moves data. It reads well and misses the one integration that creates the actual risk.
Teams also treat the DPIA as a gate to get through rather than a document worth reusing. Once it is signed off, it goes in a folder and nobody opens it again until an audit forces the issue eighteen months later, by which point the system has changed enough that half the document is no longer accurate.
And plenty of DPIAs read like they were assembled from a template with the nouns swapped out. Generic risk lists, generic mitigations, nothing specific to the actual data flow in front of you. That is the version that falls apart under scrutiny, because a regulator asking one follow-up question usually finds the gap immediately. This is why the process matters more than the document. A DPIA is a record of thinking that happened, and if the thinking did not happen, no amount of careful drafting fixes that afterwards.
Getting your DPIA foundation right
A DPIA works best when it sits on top of a data estate you actually understand: who owns what, where personal data lives, how it moves between systems. Without that picture, the assessment becomes guesswork dressed up as a formal document, and guesswork does not hold up when someone checks it. That is also, incidentally, a legal obligation you cannot skip just because it is inconvenient to map.
This is where the compliance work and the data architecture work meet. We help organisations map their data governance before they build the AI system that needs a DPIA, so the assessment describes something real rather than something aspirational. It is a lot easier to write an honest necessity and proportionality section when you already know exactly what data your pipeline touches and why it is there.
If you are about to launch an AI project and have not yet worked out whether it needs a DPIA, start there before you start building. Our AI readiness checklist is a reasonable place to check your own footing, and if you would rather talk it through with someone directly, get in touch and we will give you a straight answer on what your project actually needs.