A plain-language data protection impact assessment for:
This tool is a screening template to support the creation of a context-specific data protection impact assessment. It does not constitute legal advice, and it supports, and does not replace, your organisation's data protection processes. While every care has been taken to reflect the statutory and regulatory framework current at the time of writing, guidance changes quickly and coverage cannot be guaranteed to be complete or current.
Responsibility for data protection compliance rests entirely with the adopting organisation: each assessment must be completed honestly, reviewed by your Data Protection Officer, and signed off before any tool is deployed, and where there is any doubt you should take your own professional or legal advice. The author accepts no liability for any loss or consequence arising from use of, or reliance on, this tool or any assessment produced with it. Use of this tool constitutes acceptance of these terms.
Who this is for. Anyone proposing a new AI or digital tool, or a new AI feature inside a tool you already use. You do not need to be a legal or technical expert; everything is explained in plain language as you go. Work through each section, and tap the i button on any section for what it is for and what a good answer looks like.
When you have finished, use Check readiness at the bottom to see whether the assessment is detailed enough to send to your Data Protection Officer (DPO), the person responsible for data protection across the organisation. This is a readiness check, not approval; only the DPO can sign off a completed assessment. (A DPIA simply means this assessment: a Data Protection Impact Assessment. The law requires one wherever a tool is likely to create a high risk to people, and completing it early, before decisions are made, is what the DfE guidance expects.)
Two housekeeping notes. Fields marked * are required before the readiness check will pass. And this template supports, it does not replace, your organisation’s data protection processes: it is not legal advice, and responsibility for compliance rests with your organisation (full disclaimer at the top of this tool).
Say what it does, who will use it, and the educational or operational purpose it serves. If it is an AI feature newly added to a product you already use, say so: a new AI feature is assessed like a new tool, not waved through because the product is familiar.
The DfE guidance says to involve your DPO at the very start and throughout, not at the end. Tick everyone consulted so far; if none yet, say who you will consult and when in the notes.
List each category (names, email, class, attendance and so on). The DfE guidance says to ask the supplier to justify why each category is necessary; collection must be limited to what the tool's educational purpose genuinely needs. If they cannot justify a category, that is a finding to record.
This question catches what the sign-up form does not. A tool that only collects a name and email can still end up processing sensitive information the moment someone types free text: a pupil writing about a medical appointment or a visit to a place of worship has just put health or religious data into the tool. Describe the input surfaces (free text, file upload, images, voice) and the rule you will apply to what goes into them.
Health, religion, ethnicity, and similar carry extra protection because misuse causes more harm. State the position and the safeguard, even if the answer is "none by design".
Normally the school or trust decides why and how the data is used (the "controller") and the supplier only handles it on your instructions (the "processor"). But the label in the contract does not settle it; what the supplier actually does settles it. If the supplier uses the data for its own purposes, such as product development, analytics or improving its AI, it is acting as a controller for that use, extra rules apply to it (including the Children's Code where pupils are involved), and you should ask why it needs to do this at all. The ICO's audits found this exact confusion to be the sector's most common failing.
The DfE guidance says to ask the supplier to walk you through what happens to the data at every stage: where it goes, who touches it, what happens to it at the end. If they cannot provide this, find out before procuring, not after. A supplier with nothing to show you is a finding in itself.
You should know who can access the data, not just the supplier you contract with. The ICO found around 30% of edtech providers had not handled sub-processor authorisation properly, and one case where a sub-processor's standard terms trained its AI model on children's data without the providers realising. Ask for the sub-processor list and how you will be told when it changes.
Mitigation prompt: data handled abroad is not a reason to reject a tool. Established suppliers normally cover this with an approved arrangement (you may see "UK Data Privacy Framework" or "International Data Transfer Agreement"). Note which one the supplier says applies.
These five are the clauses the DfE guidance says to check and challenge before signing, and the ones the ICO's audits most often found vague or missing. "Deletion and return" means the contract states that at the end, the data is deleted or returned at your choice; some contracts fail even that.
The law requires a valid reason (a "lawful basis") for using people's data. For most things a school does, that reason is that it is part of running the school and educating pupils ("public task"). Two boundaries to know. First, public task only stretches as far as your official functions: if a tool has extra features beyond that, such as features parents sign up to directly, public task will not cover them and the supplier may be the controller for that part. Second, do not confuse a tool's terms requiring parent or guardian agreement for young users with your lawful basis; that agreement is about the tool's terms of service, and your lawful basis is decided here, separately, and is rarely consent. If you do rely on consent for anything, there must be a real choice, a clear way to say no, and a way to withdraw it later. (Your DPO may also mention "recognised legitimate interests", a route added by the 2025 Act; that is for the DPO to weigh, not something this form decides.)
Mitigation prompt: ask whether you can configure the retention period yourself; the ICO asked providers to offer this. Cover both routine deletion during use and the exit position: when the contract ends or the supplier folds, how do you get the data back or confirm deletion?
Mitigation prompt: if a member of staff genuinely looks at what the tool suggests and is free to change it, rather than just accepting it, then it is really the staff member deciding, not the tool, and that is fine; the law calls this meaningful human involvement. Since February 2026 the law (Articles 22A to 22D of the UK GDPR) does permit some decisions with a significant effect on a person to be made entirely by a tool, but only with safeguards: the person must be told, must be able to make representations, get human intervention, and contest the outcome. If you answered "decides entirely on its own", describe those safeguards here and flag for DPO review; your Use of AI Policy may hold a stricter line and rule this out regardless.
Biometric identification and emotion inference are the highest-risk category in this form. If a tool does either, stop and involve the DPO before going further: biometric identification of anyone under 18 in a school requires written parental consent under the Protection of Freedoms Act 2012, with an alternative offered to anyone who refuses, and your Use of AI Policy may prohibit it outright.
Check the actual terms, not the marketing page, and check for sub-processors too: the ICO's audits found a sub-processor whose standard terms trained its AI model on children's data, with an opt-out the providers had not exercised because they did not know it existed. If the answer is yes for anything beyond delivering the service to you, the supplier is acting as a controller for that use, and for education tools the DfE product safety standards expect no use of personal data for model training without a confirmed lawful basis.
What people type into an AI tool, and what it produces, are organisational records: they can be requested under subject access requests and freedom of information, so you need to know where they live. In a Microsoft environment, Copilot interactions are searchable through Purview under the standard audit licence; in a Google environment, Gemini app conversations are searchable through Vault, though Gemini features embedded inside Gmail and Docs keep no record. For other tools, ask the supplier. "Nowhere" is an acceptable answer if true; "we do not know" is not.
Data protection by design means the tool arrives with only what you need switched on: non-core features off by default, optional data fields disabled, the strongest privacy settings applied from the start. The ICO found many products shipped as an all-or-nothing bundle; the DfE guidance says to review optional fields and disable what you do not need. Record what you switched off.
Where is it hosted, is single sign-on enforced, and is access limited to the right people? Single sign-on through your existing accounts is itself a strong security mitigation.
If the tool does not natively allow individual extraction or deletion, state the mitigation: a strict rule of anonymised input only, enterprise terms guaranteeing short automated retention, or supplier assistance committed in the contract. Remember the logs from section 9 count as this person's data too. If no mitigation is possible, flag explicitly for DPO review.
There are special rules for online tools that under-18s use (the Children's Code). The rules bind the companies that make the tools rather than schools directly, but looking after children's best interests is already your duty, and since the 2025 Act the law expressly requires services to take account of children's higher protection needs when designing their processing. Confirm three things: the strongest privacy settings are on from the start; it does not automatically sort or score pupils unless deliberately switched on; and it does not use design tricks ("nudges") that push children into sharing more or lowering their privacy. For generative tools, also consider under the Prevent duty whether the tool could generate or expose pupils to extremist or otherwise inappropriate ideological content, and note the safeguards: filtering, supervision, and reporting to the designated safeguarding lead.
The standards cover a product's stated purpose, educational use cases, filtering, monitoring and reporting, security, privacy and data protection, intellectual property, design and testing, governance, and safeguards for cognitive development, emotional and social development, mental health and manipulation. Ask the supplier which standards they meet and for their evidence; this check runs alongside the DPIA, not instead of it, and belongs to your tool approval process.
For each risk, think how likely it is and how much harm it could cause, then state the control that reduces it. For AI tools, the recurring risks are: staff or pupils entering personal or sensitive data, including through free text (section 4); inaccurate or invented output being relied on; data feeding the supplier's models (section 9); and weak access control; and, under the Prevent duty, a generative tool producing or surfacing extremist or otherwise inappropriate ideological content, sometimes from innocuous prompts. Each risk needs a matching mitigation, and any Prevent or safeguarding concern goes to your designated safeguarding lead.
Fairness means people are told how their data is used. If this tool introduces a new use of staff or pupil data, the relevant privacy notice is updated in plain language before go-live, and that includes AI sitting inside a teacher-facing tool that pupils never touch: if it processes their data, they and their parents are told. Treat an outstanding update as an action to close before the tool goes live.
A DPIA is a living record, not a one-off form. Tools change, and suppliers push new AI features into products you have already approved; a materially changed tool is reassessed, not assumed. Keep this assessment updated as and when the processing changes.
What the readiness check does, and does not do. It checks completeness and consistency: that every section is answered, in enough detail, and that answers agree with each other (a yes to overseas transfer needs a safeguard named, a pupil-facing tool needs the children's checks confirmed). It does not, and cannot, judge whether your answers are correct; that judgement belongs to your DPO. A green result means ready to submit, not approved.
Completed by the DPO after review; leave blank when submitting. Print or save to PDF for signature.