Does your school need a DPIA for AI tools?

Almost certainly, if the tool will touch personal data about pupils or staff. The ICO's guidance on AI, now under review, says that "in the vast majority of cases, the use of AI will involve a type of processing likely to result in a high risk to individuals' rights and freedoms". That is the trigger for a data protection impact assessment (DPIA), done before the processing starts.12

The DPIA has a fearsome reputation it has not earned. Strip away the acronym and it is a written answer to one question, asked in seven parts: have we thought this through before switching it on?

Done before the decision, it is governance. Done the week after launch, it is paperwork with a date problem.

The legal test, in plain English #

Article 35 of the UK GDPR says that where processing, "in particular using new technologies", is likely to result in a high risk to people's rights and freedoms, the controller must assess it first. The ICO's list of processing that meets the test starts with innovative technology, "including AI", which needs a DPIA when combined with any other high-risk criterion from the European guidelines on DPIAs.3

Children supply that second criterion almost automatically. The ICO regards them as vulnerable because they "may be less able to understand how their data is being used, anticipate how this might affect them, and protect themselves against any unwanted consequences". So an AI tool plus pupils' data meets the test before anyone mentions SEND or a tool that scores and flags.4

Staff can count too, because of the power imbalance with their employer.

The exception is narrow. A staff tool with no personal data going into it, used for drafting a generic letter or planning a lesson on the water cycle, is unlikely to be high risk, and a DPIA is not usually needed.

Keep a short, dated screening note anyway: the tool, the use, why no personal data goes in, who decided, and what would change the answer. The ICO expects the reasons to be written down whenever a DPIA is judged unnecessary, and the note answers the question a year later, when nobody remembers the meeting.5

What this means for us

Stop debating whether an AI tool needs a DPIA. If it touches personal data about pupils or staff, assume it does, and put the effort into step two, where the real risks turn up. If it touches none, the screening note goes on file with the register entry, and the approval depends on it staying true.

Who holds the pen #

The DPIA belongs to the controller, which for most personal data, in the DfE's words, is "the school or the multi-academy trust". The ICO leaves each organisation to decide who carries out its DPIAs and who signs them off, and a trust using one tool the same way in every school can cover them all in one DPIA.6

The division that works is simple. Whoever proposes the tool drafts the DPIA, because they know what it is for. The DPO advises: the law requires that advice to be sought, and the ICO expects it recorded, with reasons if it is not followed.7

A named senior leader, or the headteacher, decides and signs. Governors and trustees, who hold accountability for data protection, get assurance.

One rule is worth writing into the policy: the DPO is not the decision-maker on their own advice. The law gives the DPO the job of advising on the DPIA and monitoring it, and their other duties must not create a conflict of interests. A DPO who drafts, advises and approves is marking their own homework.

Suppliers often say they have done a DPIA already. Ask for it and use it in step two: the DfE's product safety standards expect generative AI products to have one. It cannot replace the school's own, which covers these pupils, this purpose and this configuration.8

The ICO's audits of edtech providers, reported in June 2026, found that in many cases they "hadn't done a DPIA at all where one was required".9

The seven steps, and the AI question in each #

The ICO's guidance sets out seven steps. Answer each honestly rather than impressively; for an AI tool, each has one question that matters more than the rest.

1. Identify the need for a DPIA. What will the tool do, with whose data, and is there AI anywhere in it, including features added to tools the school already has?
2. Describe the processing. What goes in, where it is stored, who can see it, how long it is kept, what comes out, and whether any of it becomes training data. Every "don't know" becomes a written question to the supplier.
3. Consider consultation. Have the staff who will use it tried it with invented data, and is there a route for pupil and parent views where pupils are affected? If not, record why.
4. Assess necessity and proportionality. Could the same benefit come with less: no names, fewer pupils, shorter retention, or no tool at all? Record the lawful basis: for a state school, academy trust or college doing its core work, usually public task.
5. Identify and assess risks. Score each for likelihood and severity, and always check the AI list: training on school data, hallucinations acted on as fact, biased output, data leaving the UK, a disclosure in pupil work reaching the tool before the DSL, the tool changing after approval, and decisions with no person meaningfully involved.
6. Identify measures to mitigate the risks. For each risk: what will be done, by whom, and what risk remains. Settings and contract clauses count; a reassuring sales call does not.
7. Sign off and record outcomes. Who decided, on what DPO advice, with what residual risk; what goes on the register entry and in the privacy notice; and what will trigger a review.1011

That last risk has its own rules. Since 5 February 2026, new UK GDPR articles (22A to 22D) govern automated decision-making: significant decisions about a person taken with no meaningful human involvement. People must be told, be able to make representations, get human intervention and contest the outcome, and stricter limits apply to special category data.1213

A tool that sifts job applicants on its own is in that territory. The simplest control is a named person who reads the output, can overrule it, and makes the decision.

The question to ask, in writing

Is anything our staff or pupils put into your product, or anything it produces for us, used to train or improve your models or anyone else's, and which clause of our contract says so?

The DfE says suppliers must be able to explain whether data is used to train the model, so the answer goes into step two with the clause number beside it. "We take privacy very seriously" answers a different question, so ask again.14

One tool, all seven steps #

A composite example, typical rather than real. A head of English wants an AI tool that comments on Year 10 draft essays. Teachers upload the drafts; pupils never log in.

Step one takes a minute: essays are pupils' personal data (their names, their words and, now and then, a disclosure), so a DPIA is needed. Step two turns up three unknowns (where the servers are, how long essays are kept, whether they train the model), and each goes to the supplier in writing.

Step two also finds a name at the top of every essay, which prompts the best question of all: could uploads use candidate numbers instead?

At step three, two teachers try the tool on invented essays and find its tone harsh for lower-attaining pupils, which becomes a settings change. At step four, the basis is public task, and the tool needs the text but not the names, chosen drafts rather than the whole cohort, and 30 days' storage rather than forever.

At step five, the standout risk is a safeguarding disclosure inside an essay: unlikely, but severe. At step six, teachers read every draft before upload, so a disclosure goes to the DSL first and never reaches the tool. Add teacher review of every comment before a pupil sees it, contract clauses on training, location and deletion, and a register entry limiting use to Year 10 English.

At step seven, the DPO's advice is written in, the deputy headteacher who owns the AI policy signs, and the residual risk is recorded as low. The review triggers are a model or terms change, an incident, or any request to widen the use.

When the answer is no, and keeping it alive #

A DPIA that stops a tool has worked. Most refusals are really "not like this": narrow the use, change the settings, or choose a tool with better terms.

If a high risk remains after every reasonable measure, the law's answer is prior consultation. Article 36 requires the controller to consult the ICO before the processing starts, and it cannot go ahead until then; the ICO says it will reply within eight weeks of receiving the DPIA, or up to 14 in complex cases. (From 30 September 2026 the regulator is the Information Commission, which is still known as the ICO.)151617

For a school, needing the regulator's view first is usually the sign to choose a different tool.

A DPIA describes the tool as assessed, and AI tools do not stay as assessed. The ICO calls a DPIA a "living" process, and the DfE's procurement guidance, added in July 2026, says to keep it updated "as and when changes to the processing occur". The same audits found cases of providers switching new features on by default, and of AI functionality introduced without adequate safeguards.18

So the review triggers matter more than the annual date: a model or feature change, new terms, an incident or complaint, and any use beyond the one assessed. The register entry and the DPIA should point at each other.

A situation #

An AI assistant appears overnight inside the platform every member of staff already uses. Nobody bought anything, but the processing has changed, so it is treated as a new tool. Whoever administers the platform checks the settings that day and, where they allow it, turns the feature off for pupil accounts until it is assessed. The DPO screens it within the week: what data the assistant can reach, whether the existing agreement covers it, and whether prompts are used for training. If it touches personal data it gets a DPIA like any other tool, the register gains a row, and the screening note goes on file with its date, because someone always asks later when the school knew.

Five asks, one owner each #

1. The headteacher, or the senior leader the AI policy names, signs every AI DPIA as the decision-maker, and nothing that touches personal data goes live before that signature.
2. The DPO gives written advice on every DPIA, and it stays in the document, with the reasons recorded wherever it is not followed.
3. Whoever proposes a tool drafts its DPIA, starting with step two, and sends every open question to the supplier in writing.
4. Whoever keeps the Approved Tools Register links each row to its DPIA or screening note, and puts the review triggers in the diary.
5. Governors and trustees ask each term which AI tools were assessed, which were refused, and which are due for review.

What changed in this guide #

[launch date]: First published, written against UK GDPR Articles 22A to 22D, 35 and 36, the ICO's guidance on DPIAs and on AI, and the DfE's Data protection in schools, as in force on 28 September 2026.

Sources #

1. UK GDPR, Article 35: Data protection impact assessment, legislation.gov.uk, revised text as in force on 28 September 2026
2. UK GDPR, Article 36: Prior consultation, legislation.gov.uk, revised text
3. UK GDPR, Articles 22A to 22D: automated decision-making, inserted by the Data (Use and Access) Act 2025, section 80, in force 5 February 2026
4. UK GDPR, Article 38: Position of the data protection officer, legislation.gov.uk, revised text
5. UK GDPR, Article 39: Tasks of the data protection officer, legislation.gov.uk, revised text
6. The Data (Use and Access) Act 2025 (Commencement No. 6 and Transitional and Saving Provisions) Regulations 2026, SI 2026/82, made 29 January 2026
7. What is a DPIA?, ICO, DPIA guidance, under review following the Data (Use and Access) Act
8. When do we need to do a DPIA?, ICO, DPIA guidance, under review following the Data (Use and Access) Act
9. Examples of processing 'likely to result in high risk', ICO, DPIA guidance, under review following the Data (Use and Access) Act
10. How do we do a DPIA?, ICO, DPIA guidance, under review following the Data (Use and Access) Act
11. Do we need to consult the ICO?, ICO, DPIA guidance, under review following the Data (Use and Access) Act
12. Guidance on AI and data protection: What are the accountability and governance implications of AI?, ICO, updated 15 March 2023, under review following the Data (Use and Access) Act
13. Public task, ICO, lawful basis guidance, updated 28 August 2026
14. Edtech examined, ICO, 24 June 2026
15. ICO governance changes confirmed for 30 September 2026, ICO, 15 September 2026, updated 17 September 2026
16. Data protection in schools: Responsibilities, DfE, guidance last updated 9 July 2026
17. Data protection in schools: Generative artificial intelligence (AI) and data protection in schools, DfE, section updated 23 March 2026
18. Data protection in schools: Procuring educational technology (EdTech), DfE, section added 9 July 2026
19. Generative AI: product safety standards, DfE, updated 19 January 2026

Sources opened on 28 September 2026.