A firm is about to roll out a new tool that scans client matters and flags risks. Someone sensible asks whether it needs a privacy assessment. A partner says yes, do a quick privacy impact assessment, tick the box, move on. The project ships.
The problem is not that they did an assessment. It is that "a quick privacy impact assessment" may have been the wrong instrument entirely. If the processing crossed the threshold in Article 35 of the UK GDPR, the law did not ask for a light-touch review. It required a full Data Protection Impact Assessment, with defined content, a risk analysis, and in some cases a consultation with the ICO before the tool could go live.
So PIA or DPIA is not a question of what you call the document. It is a triage decision, and it is one firms get wrong in a specific, avoidable way: they choose the assessment by habit or gut, without ever applying the legal test that decides which one the law demands.
PIA and DPIA are not two flavours of the same thing
Clear up the terms first, because the loose usage is where the confusion starts.
A Privacy Impact Assessment, PIA, is the older idea. It comes from the ICO's pre-GDPR guidance, a general good-practice tool for thinking through the privacy implications of a project. It has no fixed statutory content. Plenty of firms still use "PIA" informally to mean any privacy review, however light.
A Data Protection Impact Assessment, DPIA, is the statutory successor, defined in Article 35 of the UK GDPR. It is not optional good practice. Where the trigger conditions are met, it is a legal requirement, with prescribed content: a systematic description of the processing, an assessment of necessity and proportionality, an assessment of the risks to individuals, and the measures you will take to address those risks.
So the honest framing is not "PIA versus DPIA" as two equal options. It is: a DPIA is mandatory in defined circumstances, and everything else is a matter of good practice you are free to shape. The triage question is really one question. Does this processing trigger a mandatory DPIA under Article 35? Everything follows from the answer.
The Article 35 test that decides it
A DPIA is required whenever processing is "likely to result in a high risk to the rights and freedoms of natural persons," and Article 35 singles out the use of new technologies as a common trigger. That is the general test. Article 35(3) then names three cases where a DPIA is always required:
- Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal or similarly significant effects for the individual.
- Large-scale processing of special category data under Article 9 (health, ethnicity, and the rest) or of personal data relating to criminal convictions and offences under Article 10.
- Systematic monitoring of a publicly accessible area on a large scale.
Beyond those, the ICO publishes its own list of processing operations that require a DPIA, drawing on the nine indicators of high-risk processing set out in European guidance. The working rule the ICO endorses is that where two or more of those indicators apply, you should treat the processing as high risk and do a DPIA. Innovative technology, large-scale processing, sensitive data, vulnerable data subjects, matching or combining datasets: hit two and you are in DPIA territory.
For a law firm, that threshold is easier to cross than it looks. A tool that profiles clients, an AI system that processes large volumes of matter data, anything touching health or criminal-offence data at scale: these are not edge cases. They are ordinary legal work, and several of them clear the Article 35 bar comfortably.
Where the triage goes wrong
Two failure modes, and they compound.
The first is assuming instead of applying. A firm decides a project is "probably low risk" without ever running it against the Article 35 criteria or the ICO's list. The conclusion might even be right, but it was reached by feel, and a feeling is not a screening. When the decision is later questioned, there is nothing to show that the test was applied at all.
The second is running the lighter instrument where the law required the heavier one. A firm does a brief privacy review, calls it a PIA, and treats the box as ticked, when the processing in fact triggered a mandatory DPIA. The assessment that happened is not the assessment the law asked for. The gap is not that no thought went in. It is that the specific, prescribed analysis Article 35 requires, including the formal risk assessment and the mitigation measures, was never done.
Field note: The tell I look for is not whether a firm has done DPIAs. It is whether it can show me the projects where it decided a DPIA was not needed, and why. A firm that can produce ten completed DPIAs but has no record of a single "we screened this and concluded no DPIA was required" is not triaging. It is only assessing the things it already assumed were risky, and missing the ones it assumed were not.
What happens if you get it wrong
Failing to carry out a DPIA where Article 35 required one is an infringement of the UK GDPR in its own right. It does not need a breach to sit behind it. The obligation is to do the assessment, and not doing it is the failure.
Infringements of the DPIA obligation fall under the standard maximum penalty in the UK GDPR: up to £8.7 million or 2% of total worldwide annual turnover, whichever is higher. That is the administrative ceiling, and even short of a fine, a regulator that finds you skipped a required DPIA has found a systemic governance weakness, not a one-off slip.
There is a second consequence that the missed triage hides. If a DPIA identifies a high risk that you cannot mitigate, Article 36 requires you to consult the ICO before you start the processing. That is a hard stop with a statutory pause built in. A firm that never did the DPIA never reaches this step, so it launches processing that should have been paused for prior consultation, and does not know it. The triage failure at the start quietly removes a safeguard at the end.
Triage as a recorded decision, not a reflex
The fix is not more assessments. It is making the triage itself a formal, logged step, so that every project produces a decision on the record rather than a reflex nobody wrote down.
When a new project or request comes in, the first move is a screening against the Article 35 criteria and the ICO's list, producing a documented conclusion: DPIA required, or not required, and the reasoning either way. Where a DPIA is required, the full assessment runs, and its output, including the risk analysis and mitigations, is drafted for the DPO to review and, if a residual high risk remains, to take to the ICO. Where it is not, the record of why still exists. The screening is the evidence, whichever way it points.
That is how the Privacy and Data Protection Agent handles it: the triage runs as a logged decision step, the DPIA is produced where Article 35 demands one, and everything is held as a draft for the DPO rather than actioned automatically. It is the same recorded-decision discipline the agent applies to the DSAR clock and to Article 28 processor reviews. And because a DPIA is one of the specific records the SRA and your COLP will expect to see for AI tools, the triage feeds directly into the wider governance picture we map in the COLP's AI governance checklist.
LegalAI Space builds AI agents for legal teams with a governance layer that makes every output verifiable, compliant, and audit-ready. Sign up for early access or book a pilot call with Founder Daman Kaur.
FAQ
What is the difference between a PIA and a DPIA? A PIA, or Privacy Impact Assessment, is the older, general good-practice term for reviewing a project's privacy implications, with no fixed statutory content. A DPIA, or Data Protection Impact Assessment, is the specific assessment defined in Article 35 of the UK GDPR, mandatory where processing is likely to result in a high risk, with prescribed content including a risk assessment and mitigation measures. In practice, a DPIA is the legally required instrument; "PIA" now usually describes anything lighter.
When is a DPIA legally required? Whenever processing is likely to result in a high risk to individuals, and always in the three cases in Article 35(3): large-scale automated evaluation or profiling with legal or similarly significant effects, large-scale processing of special category or criminal-offence data, and systematic monitoring of a public area on a large scale. The ICO also publishes a list of operations that require one, and treats processing that meets two or more high-risk indicators as needing a DPIA.
Is a PIA enough, or do we need a DPIA? If the processing crosses the Article 35 threshold, a general PIA is not enough. The law requires a DPIA with its prescribed content. A lighter privacy review does not discharge the obligation, however carefully it is written.
What happens if you don't do a DPIA when one is required? It is an infringement of the UK GDPR on its own, subject to the standard maximum penalty of up to £8.7 million or 2% of worldwide annual turnover, whichever is higher. It also means you may miss the Article 36 requirement to consult the ICO before starting processing that carries an unmitigated high risk.
Who decides whether a DPIA is needed? The controller decides, applying the Article 35 criteria and the ICO's list, and should record that decision. In a firm, the screening is typically owned by the DPO or the person responsible for the project, and the decision, either way, should be documented as evidence that the test was applied.
Do we need a DPIA for AI tools? Often yes. Article 35 flags new technologies as a common high-risk trigger, and AI tools that profile individuals, process large volumes of personal data, or handle sensitive data frequently meet two or more high-risk indicators. Each tool should be screened on its facts rather than assumed either way.
Sources
-
UK GDPR, Article 35. Requires a DPIA where processing is likely to result in a high risk to individuals, in particular using new technologies; Article 35(3) names three cases where a DPIA is always required; Article 35(4) requires the supervisory authority to publish a list of processing operations subject to the requirement; Article 35(7) sets out the mandatory content.
-
ICO, When do we need to do a DPIA? and Examples of processing likely to result in high risk. Sets out the ICO's list of high-risk operations and endorses treating processing that meets two or more high-risk indicators as requiring a DPIA. The term "privacy impact assessment" originates in the ICO's pre-GDPR PIA guidance.
-
UK GDPR, Article 36. Requires the controller to consult the ICO before processing where a DPIA indicates a high risk that the controller cannot mitigate.
-
UK GDPR, Article 83(4). Infringements of the DPIA obligations in Article 35 are subject to the standard maximum administrative penalty of up to £8.7 million or 2% of total worldwide annual turnover, whichever is higher.