Do you need a DPIA before rolling out Claude or Copilot? A UK screening test

Most UK organisations rolling out an AI assistant to staff will need a data protection impact assessment before they switch it on. Not all of them will, and the difference is worth establishing early rather than discovering during an incident. The screening test is set out in Article 35 of the UK GDPR and in the ICO's own published criteria, and it can be worked through in an afternoon.
The more useful question is what a DPIA has to contain to be worth anything. On that, there is an unusually good source: the ICO has published its own DPIA for Microsoft Copilot 365, including the review comments its data protection officer's team made on the first draft. The regulator's DPO told the regulator's own project team that the document was not good enough, and the reasons are precisely the ones a UK SME will fall into.
This guide is written for the person who has to produce or sign the assessment: a data protection lead, an operations director, or a managing partner in a firm without a full-time DPO.
When is a DPIA legally required?
Article 35(1) of the UK GDPR requires a DPIA where a type of processing, "in particular using new technologies", is likely to result in a high risk to the rights and freedoms of individuals. Article 35(3) then sets out three cases where one is always required: systematic and extensive automated evaluation of personal aspects, including profiling, on which decisions with legal or similarly significant effects are based; large-scale processing of special category or criminal offence data; and systematic monitoring of a publicly accessible area on a large scale.
Most staff AI-assistant rollouts do not land squarely in any of those three. That is why organisations sometimes conclude, too quickly, that no DPIA is needed.
The ICO adds its own list of ten types of processing under Article 35(4) that require a DPIA, and the first item is directly on point. It reads: "Innovative technology: processing involving the use of innovative technologies, or the novel application of existing technologies (including AI). A DPIA is required where this processing is combined with any of the criteria from the European guidelines."
The phrase to notice is "combined with". Innovative technology on its own is a criterion, not an automatic trigger. It becomes one when something else is present alongside it.
The screening test, in the form worth actually using
The ICO reproduces nine indicator criteria drawn from the European guidelines and states the working rule: "In most cases, a combination of two of these factors indicates the need for a DPIA. However, this is not a strict rule." The hedge is the ICO's own and should not be dropped: two factors is an indicator, not a threshold, and one factor with severe consequences can be enough.
Run your intended deployment against the criteria below. An AI assistant rollout starts with one already ticked.
| Criterion | Typical answer for a staff AI-assistant rollout |
|---|---|
| Innovative technology | Yes, always. This is the ICO's own example of the category. |
| Evaluation or scoring | Only if the assistant is used to assess people, for example screening CVs or drafting performance summaries. |
| Automated decision-making with legal or significant effect | Usually no, provided a human genuinely decides. See the Data (Use and Access) Act rules on meaningful human involvement. |
| Systematic monitoring | Sometimes. Usage analytics on individual staff can bring this into play. |
| Sensitive or highly personal data | Often yes in regulated sectors: client files, health data, legal matters. |
| Data processed on a large scale | Depends on the connector scope. An assistant with access to the whole document store is a different question from one that does not. |
| Matching or combining datasets | Often yes where the assistant reads across previously separate systems. |
| Data concerning vulnerable data subjects | More often than expected. See below. |
| Preventing individuals exercising a right or using a service | Usually no for an internal productivity tool. |
The vulnerable data subjects row is the one that catches organisations out. The ICO expressly names employees as a group who may count as vulnerable in this sense, because "a power imbalance means they cannot easily consent or object to the processing of their data by an employer". An internal staff rollout that processes employee data therefore has a realistic claim to two criteria before anyone has looked at client data: innovative technology, and vulnerable data subjects.
That does not settle it, and it is not meant to. It means the honest answer for most UK organisations is that a DPIA is likely to be required, and the sensible posture is to run the screening properly and record the outcome either way. The ICO's own template instructs staff that if they are unsure whether a DPIA is needed, they should use the screening assessment, and a documented negative screening is itself a useful artefact.
What the ICO's own DPIA shows about doing this badly
The ICO published its data protection impact assessment for Microsoft Copilot 365 under freedom of information reference IC-359252. It covers a pilot of around thirty users rather than a full rollout, with the ICO as controller and Microsoft as processor.
The document also contains the review recommendations made by the ICO's own DPO team on the first draft, and they are more instructive than the finished assessment. The first recommendation reads: "The DPIA is currently just a general DPIA about Microsoft CoPilot for 365 and you need to elaborate on your use cases and the ICO's purpose for using it." The third reads: "there is no real explanation of necessity."
Those two criticisms describe the standard failure mode almost exactly. An organisation downloads a template, describes the product rather than its own use of it, asserts that the tool is useful, and files it. What that produces is a document about Microsoft or Anthropic, not a document about your processing. It is the same trap as assuming a supplier can be GDPR compliant on your behalf, which we cover in our guide to whether Claude is GDPR compliant.
Two lessons follow. First, a DPIA is about your use cases, named specifically: which teams, which data, which tasks. "Staff productivity" is not a use case. Second, necessity has to be argued rather than assumed. Necessity means the outcome cannot reasonably be achieved another way that is less intrusive, and a DPIA that never engages with the alternatives has not made the argument.
What the Data (Use and Access) Act 2025 did, and did not, change
This is where competing guidance is least reliable, so it is worth being precise.
The Data (Use and Access) Act 2025 did not change when a DPIA is required. Article 35 and the screening architecture around it are untouched, and an assessment run against the criteria above is run against the same criteria it would have been run against in 2025.
What changed, from 5 February 2026, is the surrounding rules on automated decision-making, which affect what a DPIA has to document where an assistant informs decisions about people. The Act replaced Article 22 of the UK GDPR with a new framework that moves solely automated significant decisions from general prohibition to a permissive regime with mandatory safeguards. If your deployment touches decisions about individuals, the safeguards section of your DPIA has to reflect the current position rather than the pre-2026 one. Our briefing on what the Act changes for AI and automated decisions sets out the detail, including what meaningful human involvement now requires.
The short version: same trigger, different contents.
What a usable DPIA contains for an AI assistant rollout
Working from the ICO's structure and from what actually gets asked in practice, a defensible assessment covers:
- Named use cases, not the product. Which teams, which categories of data, which tasks, and which tasks are explicitly out of scope. This is the ICO DPO's first recommendation and the most common omission.
- A necessity and proportionality argument. Why this outcome cannot reasonably be achieved less intrusively, engaging with the alternatives rather than skipping them.
- The data flows as they actually are. Where data goes, who processes it, in which jurisdiction, and under what contractual terms. For Claude this includes retention and training positions by plan; for cloud routes it includes processing location, which our guide to Claude data residency for UK organisations covers.
- The connector and permission scope. An assistant that can read the whole document store presents a different risk from one scoped to a team folder, and the assessment should describe the scope you have actually configured.
- The human involvement position wherever output informs a decision about a person, written against the post-February 2026 rules.
- Retention, deletion and subject rights in practice. How a subject access request or erasure request is answered when the data sits in conversation history.
- The residual risk and who accepted it, named. An assessment with no residual risk recorded has usually not looked hard enough.
What not to do: do not run a tool-level DPIA and reuse it across every deployment, because the ICO's own DPO rejected exactly that; do not treat the supplier's documentation as your assessment; and do not leave it until after go-live, since a DPIA is intended to inform the decision rather than record it.
Where The AI Consultancy fits
Running the screening test, then producing an assessment that names real use cases and argues necessity properly, is normally the first piece of documented work in our AI readiness assessment, and for most UK SMEs it is a scoped exercise rather than a programme. Where the rollout is already under way, our Claude implementation engagements pick up the connector scoping and permission design the assessment depends on. Our UK AI compliance checklist covers the wider obligations this sits inside.
Verified on 31 July 2026 against the ICO's guidance on when a DPIA is required, the ICO's published DPIA for Microsoft Copilot 365 (FOI reference IC-359252), and the Data (Use and Access) Act 2025 as enacted. This article is general information, not legal advice. A DPIA is a legal document and sign-off rests with your own data protection officer or qualified adviser.
Frequently asked questions
- Do we legally need a DPIA before rolling out Claude or Copilot to staff?
- Probably, though it depends on your deployment. UK GDPR Article 35 requires a DPIA where processing is likely to result in a high risk to individuals, and the ICO names the novel application of AI as a criterion that requires a DPIA when combined with any of the European guidelines criteria. Because the ICO also recognises employees as potentially vulnerable data subjects, an internal rollout often meets two criteria before client data is considered. The ICO's working rule is that a combination of two factors usually indicates the need for a DPIA, while noting this is not a strict rule. Run the screening properly and record the outcome either way.
- Did the Data (Use and Access) Act 2025 change when a DPIA is required?
- No. The Act did not amend Article 35, so the screening criteria and the circumstances requiring a DPIA are unchanged. What changed, from 5 February 2026, is the framework around automated decision-making: the Act replaced Article 22 of the UK GDPR with a permissive regime plus mandatory safeguards. If your assistant informs decisions about individuals, the safeguards your DPIA documents must reflect the current rules rather than the pre-2026 position. Same trigger, different contents.
- Can we write one DPIA for the tool and reuse it across the business?
- That is the single most common failure, and the ICO's own data protection officer rejected it. Reviewing the ICO's draft DPIA for Microsoft Copilot 365, its DPO team recorded that 'The DPIA is currently just a general DPIA about Microsoft CoPilot for 365 and you need to elaborate on your use cases and the ICO's purpose for using it', and separately that 'there is no real explanation of necessity'. A DPIA has to describe your processing, naming teams, data categories and tasks, and has to argue why the outcome cannot reasonably be achieved in a less intrusive way.
- What does necessity mean in a DPIA, and why does it matter?
- Necessity means the processing is genuinely required to achieve your stated purpose and that the purpose cannot reasonably be achieved by a less intrusive route. It is not satisfied by asserting that the tool is useful or that competitors are adopting it. In practice this means engaging with the alternatives you considered and explaining why they were rejected. It matters because a DPIA without a necessity argument is one of the two defects the ICO's own reviewers flagged, and it is the part a regulator would test first.
- When should the DPIA be done, and who signs it off?
- Before the rollout, because a DPIA is intended to inform the decision rather than document one already taken. Completing it after go-live removes most of its value and is difficult to defend. Sign-off rests with your data protection officer where you have one, or with the senior person accountable for the processing where you do not. Where residual risk remains high after mitigation, the ICO must be consulted before proceeding.