Ask.School is an AI-powered parent communication platform for UK schools that provides DPIA documentation and a data processing agreement as standard. Schools across the country are adopting AI tools at pace, from chatbots that answer parent queries to platforms that generate lesson plans or summarise pupil data. Each of these tools processes information in ways that traditional school software does not, and data protection law requires schools to assess the risks before deployment.

A Data Protection Impact Assessment — commonly known as a DPIA — is the formal mechanism for doing this. It is not optional. Under UK GDPR and the Data Protection Act 2018, schools must complete a DPIA before introducing any processing that is likely to result in a high risk to individuals. AI tools, by their nature, almost always meet that threshold.

Despite the legal requirement, many schools find the DPIA process unclear. The Information Commissioner’s Office (ICO) publishes guidance on DPIAs, but it is written for a general audience and does not address the specific risks that AI introduces. The DfE’s Data Protection Toolkit for Schools provides templates, but again, these were designed before generative AI became widespread in education.

Ask.School has put together a practical resource to bridge that gap. The sections below walk through the DPIA process step by step, explain the AI-specific risks that schools need to assess, and provide a worked example using a school AI chatbot scenario. Whether a school is deploying its first AI tool or reviewing an existing one, the framework below offers a practical approach to getting data protection right.

For the broader data protection picture, see the companion post on data protection and AI: what schools need to get right. For schools evaluating multiple AI vendors, the procurement checklist for school AI tools covers the due diligence questions that should be asked before any tool reaches the DPIA stage.

What is a Data Protection Impact Assessment?

A DPIA is a structured process for identifying and minimising the data protection risks of a project, system or technology. It is required by Article 35 of UK GDPR whenever processing is likely to result in a high risk to the rights and freedoms of individuals.

The ICO describes a DPIA as a way to “identify and minimise the data protection risks of a project”. It is not simply a form to fill in. A properly completed DPIA requires schools to think systematically about what personal data a tool will process, why that processing is necessary, what could go wrong, and what steps will be taken to reduce those risks.

A DPIA has several core components:

  • Description of the processing: What personal data is involved, where it comes from, who has access, and how long it is retained
  • Assessment of necessity: Why the processing is needed and whether there are less intrusive alternatives
  • Risk assessment: What risks the processing poses to individuals and how likely those risks are
  • Mitigation measures: What technical and organisational steps will be taken to reduce risks to an acceptable level
  • Consultation: Whether data subjects, the DPO, or the ICO need to be consulted

The output is a living document that should be reviewed and updated whenever the processing changes. For AI tools, this means a DPIA should be revisited whenever the vendor updates the model, changes data storage practices, or introduces new features.

When is a DPIA legally required for AI tools in schools?

The short answer is: almost always. The ICO’s screening checklist identifies several criteria that trigger a mandatory DPIA. AI tools in schools typically meet multiple criteria simultaneously.

The ICO’s triggering criteria

The ICO states that a DPIA is required when processing involves at least two of the following:

Criterion Typical AI Tool in School
Evaluation or scoring AI that assesses student work, behaviour or engagement
Automated decision-making with significant effects AI that triages parent queries or prioritises safeguarding alerts
Systematic monitoring Conversation logging, usage analytics, pattern detection
Sensitive data or data of a highly personal nature Safeguarding concerns, SEN information, medical data
Data processed on a large scale MAT-wide deployment, hundreds or thousands of users
Matching or combining datasets AI that draws on school MIS data, policy documents and public information
Data concerning vulnerable data subjects Children, parents in difficult circumstances
Innovative use or applying new technological or organisational solutions Generative AI is, by the ICO’s own definition, an innovative technology
Processing that prevents data subjects from exercising a right or using a service If a school only provides information via an AI chatbot

A school deploying an AI chatbot for parent communication, for example, is likely to meet the criteria for systematic monitoring (conversation logs), data concerning vulnerable data subjects (children’s information may be discussed), innovative technology (generative AI), and potentially large-scale processing (if deployed across a trust).

The DfE position

The Department for Education’s guidance on generative AI in education reinforces this requirement. It states that schools should complete a DPIA before deploying any AI tool and should review it regularly. The Generative AI Product Safety Standards go further, requiring developers themselves to complete DPIAs during development and throughout the product lifecycle.

This means there are two DPIAs in play: the vendor’s DPIA, which covers how the product processes data at a technical level, and the school’s DPIA, which covers the school’s specific use case, data flows and context. Schools should ask vendors for a copy of their DPIA or a summary, and use it to inform their own assessment.

Where schools get this wrong

The most common mistake is treating a vendor’s DPIA as a substitute for the school’s own assessment. A vendor’s DPIA covers the product. The school’s DPIA must cover the school’s deployment — including the specific data that will flow through the system, who will have access, how staff will be trained, and what happens when things go wrong. These are context-specific questions that only the school can answer.

Another common mistake is completing a DPIA after deployment rather than before. UK GDPR is clear: the assessment must happen before the processing begins. A school that deploys an AI tool and then retrospectively completes a DPIA has not met the legal requirement, even if the DPIA itself is thorough.

What information should schools gather before starting a DPIA?

Before sitting down to complete the assessment, schools need to gather information from several sources. Attempting to write a DPIA without this preparation typically results in an incomplete document that needs to be revisited.

From the vendor

Schools should request the following from any AI vendor:

  1. Data processing agreement (DPA): A legally binding document under Article 28 of UK GDPR that sets out the vendor’s obligations as a data processor. This should specify what data is processed, the purpose of processing, data retention periods, security measures, sub-processor details, and data deletion procedures.

  2. Privacy notice or policy: The vendor’s public-facing explanation of how they handle data. Check that it is consistent with what the vendor has told the school directly.

  3. Vendor DPIA or DPIA summary: The vendor’s own assessment of the risks their product creates. Not all vendors will share the full document, but they should at minimum confirm that a DPIA exists and share key findings.

  4. Technical documentation: Where data is stored, whether it is encrypted in transit and at rest, what cloud infrastructure is used, and whether data is transferred internationally.

  5. Model training policy: A clear statement on whether conversation data, uploaded documents, or any other school data is used to train or fine-tune AI models. This is a critical question for schools — if the answer is yes or unclear, the risk profile changes significantly.

  6. Sub-processor list: A list of third-party services the vendor uses to deliver the product (e.g. cloud hosting, AI model providers, analytics services). Each sub-processor is a potential data protection risk.

  7. Security certifications: ISO 27001, Cyber Essentials Plus, or equivalent. These are not guarantees, but they demonstrate a baseline commitment to information security.

  8. Incident response procedures: How the vendor handles data breaches, including notification timescales and communication protocols.

From within the school

Schools also need to gather internal information:

  1. Data inventory: What personal data will flow through the AI tool? This includes data actively entered by users (queries, uploaded documents), data the tool accesses from other systems (MIS integration, school policies), and metadata generated by the tool (conversation logs, usage analytics).

  2. User groups: Who will interact with the tool? Staff, parents, students, governors? Each group has different data protection considerations.

  3. Access controls: Who within the school will have access to the tool’s admin panel, conversation logs, analytics, and configuration settings?

  4. Existing privacy notice: Does the school’s current privacy notice cover the processing that the AI tool will introduce? If not, it will need updating before deployment.

  5. Data protection policy: Does the school’s data protection policy address AI tools? Many policies written before 2024 will not.

  6. Staff training plan: How will staff be trained to use the tool in a data-protection-compliant way?

  7. Exit strategy: What happens to the data if the school stops using the tool? How will data be exported or deleted?

How should schools assess AI-specific risks?

Standard DPIA templates cover general data processing risks — unauthorised access, data loss, excessive data collection. AI tools introduce additional risks that most templates do not address. Schools completing a DPIA for an AI tool need to consider the following categories.

Hallucination and inaccuracy

Generative AI models can produce responses that sound authoritative but are factually incorrect. In a school context, this could mean a chatbot providing incorrect information about term dates, admissions policies, uniform requirements, or — more seriously — safeguarding procedures.

The risk is not just that incorrect information is provided. It is that parents or staff may act on that information, believing it to be accurate because it came from an official school system. If a chatbot incorrectly states a safeguarding reporting procedure, the consequences could be significant.

Mitigations to document in the DPIA:

  • Whether the AI tool uses retrieval-augmented generation (RAG) to ground responses in school-approved content rather than generating answers from general training data
  • Whether the tool includes confidence indicators or disclaimers when responses are uncertain
  • How frequently the school’s knowledge base is reviewed and updated
  • Whether staff review a sample of chatbot responses on a regular basis
  • The process for correcting inaccurate responses when they are identified

Data leakage through prompts and responses

When users interact with an AI tool, they may inadvertently include personal data in their queries. A parent asking “my son James in Year 4 has been having problems with another child called…” has just provided names, year groups, and information about a potential safeguarding concern.

If the AI tool logs these conversations, transmits them to a cloud API, or uses them for model training, that personal data has been shared beyond the school’s intended purpose. Even if the vendor’s privacy policy says data is not used for training, the data may still be processed by third-party AI model providers.

Mitigations to document in the DPIA:

  • Whether the tool processes queries locally or sends them to an external API
  • Whether conversation data is logged and, if so, for how long
  • What happens to personal data inadvertently included in queries
  • Whether the tool has any data minimisation features (e.g. stripping identifying information before processing) — Ask.School’s personal data in documents guide explains how PII detection works in practice
  • Whether end users are warned not to include personal data in their queries

Model training on school data

This is one of the most significant risks for schools. Some AI tools use conversation data to improve their models — meaning that information shared with the tool could influence responses given to other users, potentially at other schools or organisations.

The Generative AI Product Safety Standards explicitly state that personal data must not be collected for commercial purposes such as model training without explicit consent. Schools should treat any use of school data for model training as a high-risk processing activity.

Mitigations to document in the DPIA:

  • A contractual prohibition on using school data for model training, included in the data processing agreement
  • Technical confirmation that the vendor’s API calls are made with training opt-out flags enabled
  • Regular review of the vendor’s terms of service for changes to training practices
  • A clear process for withdrawing consent and requesting data deletion if the vendor changes its training policy

Automated decision-making

If an AI tool makes decisions that affect individuals — such as triaging parent queries, prioritising safeguarding referrals, or categorising student behaviour — this constitutes automated decision-making under UK GDPR. Article 22 gives individuals the right not to be subject to decisions based solely on automated processing that produce legal or similarly significant effects.

In practice, most school AI tools involve a human in the loop. But schools need to document where the AI makes recommendations and where humans make final decisions. If the AI flags a safeguarding concern, is there always a human who reviews that flag before action is taken? If the AI categorises a parent query as low priority, is there a risk that urgent queries are missed?

Mitigations to document in the DPIA:

  • A clear description of where automated processing occurs and where human oversight is required
  • Staff training on reviewing and overriding AI recommendations
  • Escalation procedures for cases where the AI’s categorisation may be incorrect
  • Regular audits of automated decisions to check for bias or systematic errors

Bias and discrimination

AI models can reflect biases present in their training data. In a school context, this could manifest as the chatbot providing different quality responses to queries in different languages, misunderstanding cultural references, or consistently misinterpreting queries from users with certain communication styles.

For schools serving diverse communities, this is a real risk. A chatbot trained primarily on standard English text may struggle with queries that include code-switching, transliteration, or non-standard grammar.

Mitigations to document in the DPIA:

  • Whether the AI tool has been tested with diverse user groups
  • Whether the vendor provides information about the training data and any bias testing
  • How the school will monitor for differential performance across user groups
  • A process for reporting and addressing bias when it is identified

Third-party sub-processors

Most AI tools rely on a chain of sub-processors. A school AI chatbot might use OpenAI or Anthropic for the language model, AWS or Azure for hosting, a separate service for analytics, and another for logging. Each sub-processor is a potential point of data exposure.

Schools are responsible for ensuring that the entire processing chain is compliant, not just the primary vendor. A thorough DPIA should cover the entire chain, not just the primary vendor.

Mitigations to document in the DPIA:

  • A complete list of sub-processors and their data protection credentials
  • Confirmation that all sub-processors are bound by data processing agreements
  • Confirmation that data is not transferred to jurisdictions without UK adequacy decisions (or that appropriate safeguards are in place)
  • A process for the school to be notified when sub-processors change

How should the DPIA be structured?

There is no single mandated format for a DPIA. The ICO provides a template that covers the minimum requirements, and the DfE’s Data Protection Toolkit for Schools includes a school-specific version. Schools can adapt either template, but the DPIA must cover the following sections as a minimum.

Section 1: Description of the processing

This section should describe, in plain language:

  • The name and purpose of the AI tool
  • What personal data is processed (be specific — not just “pupil data” but “pupil names, year groups, and attendance data accessed via MIS integration”)
  • Where the data comes from (user input, school databases, public sources)
  • How the data flows through the system (from user query, to API, to response, to log)
  • Who has access to the data (vendor staff, school admins, safeguarding leads)
  • How long data is retained and how it is deleted
  • Whether data is transferred internationally

A data flow diagram is helpful here. Even a simple one that shows the path from user input through the AI system to storage and deletion makes the processing tangible and easier to assess.

Section 2: Lawful basis for processing

Schools must identify the lawful basis under UK GDPR Article 6 for each type of processing. The most common bases for school AI tools are:

Lawful Basis When It Applies
Public task (Article 6(1)(e)) Processing necessary for the school’s educational function. This is the most commonly used basis for school data processing.
Legitimate interests (Article 6(1)(f)) Processing that serves the school’s legitimate interests, provided those interests are not overridden by the individual’s rights. Note: this basis is not available to public authorities for processing carried out in the performance of their tasks — maintained schools should generally rely on public task.
Consent (Article 6(1)(a)) Where the school obtains explicit consent from parents or staff. Consent must be freely given, specific, informed and unambiguous. Schools should consider whether consent is truly “freely given” when a parent has no realistic alternative.
Legal obligation (Article 6(1)(c)) Where processing is required by law — for example, maintaining safeguarding records.

For special category data (including data about children, health information, or safeguarding concerns), schools also need to identify a condition under Article 9 of UK GDPR and Schedule 1 of the Data Protection Act 2018.

Important: The choice of lawful basis has practical consequences. If a school relies on consent, it must be prepared to stop processing if consent is withdrawn. If a school relies on public task, it must demonstrate that the AI tool is genuinely necessary for its educational function. Schools should discuss the appropriate basis with their DPO or data protection adviser.

Section 3: Necessity and proportionality

This section asks whether the processing is necessary and proportionate to the purpose. Schools should address:

  • Why is an AI tool needed? What problem does it solve that cannot be solved by non-AI means?
  • Could the purpose be achieved with less data? For example, could a chatbot function without logging conversations?
  • Is the processing proportionate to the benefit? A tool that processes large amounts of personal data to answer basic queries about school uniform may not be proportionate.
  • What alternatives were considered? Document any non-AI alternatives that were evaluated and why they were not suitable.

This is not a box-ticking exercise. Schools should be genuinely critical about whether the AI tool is the right solution. If a simpler, less data-intensive tool would achieve the same outcome, that may be the better option from a data protection perspective.

Section 4: Risk assessment

This is the core of the DPIA. For each risk identified, schools should document:

  1. The risk: A clear description of what could go wrong
  2. The likelihood: How probable is this risk? (Low / Medium / High)
  3. The severity: If this risk materialises, how serious is the impact? (Low / Medium / High)
  4. The overall risk level: Likelihood x Severity
  5. Mitigations: What measures are in place or planned to reduce the risk?
  6. Residual risk: After mitigations, what level of risk remains?

The risk assessment should cover both the general data protection risks (unauthorised access, data loss, excessive retention) and the AI-specific risks discussed earlier (hallucination, data leakage, model training, automated decision-making, bias, sub-processor chains).

Section 5: Mitigations and measures

For each risk, document specific, actionable mitigations. Vague statements like “appropriate security measures will be in place” are not sufficient. Each mitigation should be:

  • Specific: What exactly will be done?
  • Assigned: Who is responsible for implementing and maintaining the mitigation?
  • Timebound: When will the mitigation be in place?
  • Verifiable: How will the school confirm the mitigation is working?

Section 6: Sign-off and review

The DPIA should be signed off by:

  • The headteacher or a senior leader with authority to approve the processing
  • The DPO or data protection lead
  • The IT lead or whoever is responsible for implementing the tool

The sign-off should include a commitment to review the DPIA at defined intervals — at minimum annually, and whenever the processing changes.

What does a completed DPIA look like in practice?

The following worked example shows how a school might complete a DPIA for deploying an AI chatbot to answer parent queries. This is illustrative — every school’s DPIA will differ based on the specific tool, data flows and context.

Worked example: AI chatbot for parent communication

Tool: An AI-powered chatbot embedded on the school website, designed to answer parent queries about school policies, term dates, admissions, uniform and other frequently asked questions.

How it works: Parents type a question into the chatbot widget. The chatbot searches the school’s uploaded knowledge base (policy documents, FAQs, newsletters) and generates a response based on that content. Conversations are logged for quality assurance and safeguarding monitoring.

Description of processing

Element Detail
Data subjects Parents, carers and prospective parents who use the chatbot
Personal data processed Conversation text (which may include names, contact details or other personal data entered by the user); IP addresses; device identifiers; timestamps
Special category data Potentially — if a parent mentions a child’s medical condition, SEN status, or safeguarding concern in a query
Data source User input via the chatbot interface
Knowledge base data School policies, term dates, admissions information, uniform guidance, newsletter content — uploaded by school staff
Data storage Cloud-hosted in the UK on ISO 27001-certified infrastructure
Data retention Conversations retained for 12 months, then automatically deleted
International transfers None — data processed and stored in the UK
AI model provider Vendor uses a third-party large language model via API; queries are sent to the model provider’s UK-based endpoint
Model training Conversation data is not used for model training; contractually prohibited in the DPA

Data flow diagram (text representation)

Parent types query → School website chatbot widget
    → Vendor's server (UK)
        → Query matched against school knowledge base
        → If needed, query sent to LLM API (UK endpoint) with knowledge base context
        → Response generated and returned to parent
    → Conversation logged in vendor's database (UK)
    → School admin can view conversation logs via dashboard
    → Logs auto-deleted after 12 months

Lawful basis

Processing Activity Lawful Basis Justification
Responding to parent queries Public task (Article 6(1)(e)) Providing information to parents is part of the school’s educational function
Conversation logging Legitimate interests (Article 6(1)(f)) Quality assurance and safeguarding monitoring. Balanced against data minimisation — logs are retained for 12 months only.
Analytics (aggregated, non-personal) Legitimate interests (Article 6(1)(f)) Understanding query patterns to improve the school’s information provision

If special category data is inadvertently included in conversations (e.g. health information), the condition under Article 9 is substantial public interest (Schedule 1, Part 2, paragraph 18 of the DPA 2018 — safeguarding of children and individuals at risk).

Necessity and proportionality assessment

Question Assessment
Why is this tool needed? The school office receives approximately 200 phone calls per week, many of which are about routine information available on the website. An AI chatbot can answer these queries instantly, freeing staff time for complex cases.
Could less data be processed? The chatbot does not require parents to create accounts or provide personal data. However, parents may include personal data in their queries. A disclaimer will remind users not to include sensitive personal information.
Were alternatives considered? A static FAQ page was considered but does not address the volume or variety of queries. A human-staffed live chat was considered but is not feasible within the school’s budget.
Is the processing proportionate? Yes. The data processed is limited to voluntary user input. The benefit — reduced admin burden and faster parent responses — is proportionate to the minimal personal data involved.

Risk assessment

# Risk Likelihood Severity Overall Mitigations Residual Risk
1 Hallucination: Chatbot provides incorrect information about school policies Medium Medium Medium RAG architecture ensures responses are grounded in school-uploaded content; regular knowledge base reviews; disclaimer that parents should verify critical information with the school office Low
2 Data leakage via queries: Parents include personal data in queries that is then processed by the LLM provider Medium Medium Medium Disclaimer on chatbot interface; vendor’s API does not retain query data beyond the API call; contractual prohibition on data use for training; queries sent to UK-based endpoint only Low
3 Model training on school data: Vendor or sub-processor uses conversation data to train AI models Low High Medium Contractual prohibition in DPA; vendor’s API configured with training opt-out; annual vendor audit of training practices Low
4 Unauthorised access to conversation logs: Conversation data accessed by unauthorised individuals Low High Medium Role-based access controls; multi-factor authentication for admin access; encryption at rest and in transit; access limited to designated school staff Low
5 Safeguarding disclosure in chatbot: Parent discloses a safeguarding concern via the chatbot Medium High High Chatbot configured to detect safeguarding language and direct users to contact the school’s DSL directly; conversation logs reviewed by safeguarding team; staff training on monitoring chatbot interactions Medium
6 Bias in responses: Chatbot provides lower quality responses to certain user groups Low Medium Low Knowledge base content reviewed for inclusivity; vendor provides bias testing documentation; school monitors response quality across user groups Low
7 Sub-processor data breach: A breach at the cloud hosting provider or LLM provider exposes school data Low High Medium Sub-processors hold ISO 27001 and Cyber Essentials Plus; vendor’s DPA includes breach notification within 72 hours; school’s incident response plan covers third-party breaches Low
8 Excessive data retention: Conversation data retained longer than necessary Low Medium Low Automated deletion after 12 months; annual review of retention period; data subject access request process documented Low

Sign-off

Role Name Date Signature
Headteacher [Name] [Date]  
DPO / Data Protection Lead [Name] [Date]  
IT Lead [Name] [Date]  

Review date: [Date + 12 months, or earlier if the processing changes]

Schools evaluating AI chatbot vendors can use the procurement checklist for school AI tools alongside this DPIA process to ensure comprehensive due diligence. Ask.School provides schools with a completed DPIA and data processing agreement, reducing the documentation burden. Learn more at ask.school.

What role does the DPO play in the DPIA process?

Under UK GDPR, schools must consult their Data Protection Officer (DPO) when carrying out a DPIA. In maintained schools, this is often an external DPO provided by the local authority. In academies and MATs, the DPO may be an in-house appointment or an external consultant.

The DPO’s role in the DPIA process includes:

  • Advising on whether a DPIA is required: The DPO should confirm that the processing meets the ICO’s criteria and that a DPIA is necessary.
  • Reviewing the methodology: The DPO should check that the DPIA covers all required elements and that the risk assessment is thorough.
  • Challenging assumptions: The DPO should act as an independent voice, questioning whether mitigations are sufficient and whether residual risks are acceptable.
  • Providing regulatory guidance: The DPO should advise on lawful basis, international transfers, and data subject rights.
  • Monitoring compliance: After the DPIA is completed, the DPO should ensure that mitigations are implemented and that the DPIA is reviewed on schedule.

Schools should involve the DPO from the beginning of the process, not ask them to rubber-stamp a completed document. The ICO has been clear that the DPO’s involvement must be meaningful, not nominal.

What if the school does not have a DPO?

All public authorities, including maintained schools and academies, are required to appoint a DPO under Article 37 of UK GDPR. If a school does not currently have a DPO, this needs to be addressed as a matter of priority — not just for the DPIA, but for all data protection obligations.

Local authorities typically provide DPO services to maintained schools. Academy trusts may appoint a trust-wide DPO or use an external service. The ICO’s guidance on DPOs sets out the requirements.

What happens if the DPIA identifies high residual risk?

If, after applying all reasonable mitigations, the DPIA still identifies a high residual risk to individuals, the school has two options:

  1. Do not proceed with the processing. If the risks cannot be mitigated to an acceptable level, the tool should not be deployed. This is a legitimate and responsible outcome of a DPIA.

  2. Consult the ICO under Article 36 of UK GDPR. This is known as “prior consultation” and requires the school to submit the DPIA to the ICO before the processing begins. The ICO will review the assessment and may provide advice, impose conditions, or prohibit the processing.

In practice, prior consultation with the ICO is rare. Most high-risk situations can be resolved by selecting a different vendor with stronger data protection practices, reducing the scope of the processing, or implementing additional technical safeguards. If a school finds itself needing to consult the ICO about an AI tool, it is worth considering whether that tool is the right choice.

How does the DPIA fit with KCSIE and the AI Product Safety Standards?

The DPIA does not exist in isolation. It is one element of a broader compliance framework that includes Keeping Children Safe in Education (KCSIE), the Generative AI Product Safety Standards, and the school’s own safeguarding and acceptable use policies.

KCSIE

Part 2 of KCSIE 2025 requires schools to have “appropriate filtering and monitoring” for any technology used in the school. This applies to AI tools. The DPIA should cross-reference KCSIE requirements and document how the AI tool’s filtering and monitoring capabilities meet the standard.

For a full analysis of KCSIE requirements for AI tools, see the guide on how schools can meet KCSIE requirements when using AI tools.

AI Product Safety Standards

The government’s Generative AI Product Safety Standards require developers to carry out DPIAs and maintain them throughout the product lifecycle. Schools should ask vendors to demonstrate compliance with these standards and use the vendor’s DPIA to inform their own assessment.

The standards also require that personal data is not used for model training without explicit consent, that privacy notices are provided in age-appropriate formats, and that robust activity logging is maintained. Each of these requirements should be reflected in the school’s DPIA.

Bringing it together

Framework What It Requires DPIA Connection
UK GDPR / DPA 2018 DPIA for high-risk processing; lawful basis; data minimisation; security measures The DPIA itself
KCSIE 2025 Appropriate filtering and monitoring; risk assessment for technology DPIA should document how the AI tool meets filtering and monitoring requirements
AI Product Safety Standards Vendor DPIA; no model training on personal data; transparency; activity logging School DPIA should reference vendor’s compliance and add school-specific context
DfE AI Guidance Schools should complete DPIAs for AI tools; review regularly Supports the requirement and provides additional context
ICO Guidance When DPIAs are required; how to conduct them; when to consult the ICO Provides the methodology and legal framework

What should schools watch out for when completing a DPIA for AI tools?

Drawing on the ICO’s published enforcement actions and guidance, there are several areas where extra care makes a significant difference.

Treating the DPIA as a one-off exercise

A DPIA is a living document. It should be reviewed whenever the processing changes — for example, when the vendor updates their AI model, introduces new features, changes sub-processors, or modifies their data retention practices. Schools should set a review date (at minimum annually) and assign responsibility for monitoring changes.

Ensuring the right people are involved

A DPIA completed by the IT department alone will miss safeguarding considerations. One completed by the safeguarding lead alone will miss technical risks. The DPIA should involve input from IT, safeguarding, senior leadership, and the DPO. For AI tools used by parents, it may also be appropriate to consult parent representatives.

Being too vague about data flows

“Data is processed securely in the cloud” is not a sufficient description of processing. The DPIA should specify exactly what data enters the system, how it moves through the system, where it is stored, who can access it, and when it is deleted. For AI tools, this means tracing the path of a user’s query from input to response to storage.

Ignoring the sub-processor chain

Many DPIAs assess the primary vendor but ignore the sub-processors that handle the actual data processing. If a school’s AI chatbot vendor uses OpenAI’s API, the school’s DPIA must consider OpenAI’s data practices, not just the vendor’s.

Not updating the privacy notice

If a school introduces an AI tool that processes personal data in a way not covered by the existing privacy notice, the notice must be updated before the tool is deployed. This is a legal requirement under Articles 13 and 14 of UK GDPR. Schools should check their privacy notice against the DPIA to confirm coverage.

Schools sometimes default to consent as the lawful basis for AI tools because it feels like the safest option. However, consent in a school context is complicated. Can a parent truly give “freely given” consent when the school has adopted a tool that affects how information is communicated? In many cases, public task or legitimate interests is a more appropriate basis, and schools should consider this carefully with their DPO.

What should schools include in their records of processing activities?

Under Article 30 of UK GDPR, schools must maintain a Record of Processing Activities (ROPA). When a new AI tool is deployed, the ROPA should be updated to include:

  • The name and purpose of the AI tool
  • The categories of personal data processed
  • The categories of data subjects
  • The recipients of the data (including sub-processors)
  • International transfers (if any)
  • Retention periods
  • A description of the technical and organisational security measures

The ROPA entry should be consistent with the DPIA. If the DPIA says conversations are retained for 12 months, the ROPA should say the same. Inconsistencies between the DPIA, ROPA, and privacy notice are a common finding in ICO audits.

A practical DPIA checklist for schools deploying AI tools

Schools can use this checklist to ensure their DPIA is comprehensive. It is designed to be printed or added to the school’s data protection files.

Before starting the DPIA

  • Confirmed that a DPIA is required (checked against ICO screening criteria)
  • Identified the DPO and scheduled their involvement
  • Assembled the DPIA team (IT, safeguarding, senior leadership, DPO)
  • Requested all vendor documentation (DPA, privacy policy, DPIA summary, technical docs, sub-processor list, security certifications)

Completing the DPIA

  • Described the processing in detail, including data flows
  • Identified all categories of personal data and data subjects
  • Identified the lawful basis for each type of processing
  • Assessed necessity and proportionality
  • Completed the risk assessment, including AI-specific risks:
    • Hallucination and inaccuracy
    • Data leakage through prompts and responses
    • Model training on school data
    • Automated decision-making
    • Bias and discrimination
    • Sub-processor chain risks
  • Documented specific, assigned, timebound mitigations for each risk
  • Assessed residual risk after mitigations
  • Determined whether prior consultation with the ICO is needed

After completing the DPIA

  • DPIA signed off by headteacher, DPO, and IT lead
  • Privacy notice updated to cover new processing
  • ROPA updated to include the AI tool
  • Staff training completed before deployment
  • Review date set (at minimum 12 months, or earlier if processing changes)
  • Vendor’s terms of service and data practices added to monitoring schedule
  • Exit strategy documented (data export and deletion procedures)

How should MATs approach DPIAs for trust-wide AI deployments?

Multi-Academy Trusts deploying AI tools across multiple schools face additional complexity. A single DPIA may cover the trust-wide deployment if the processing is consistent across schools, but it must account for differences in context — for example, a primary school and a secondary school in the same trust may have different risk profiles for the same tool.

Trust-level considerations

  • Data controller: The trust is typically the data controller for AI tools deployed centrally. Individual schools within the trust may be joint controllers if they have autonomy over how the tool is configured or used.
  • Consistency: If the tool is configured identically across all schools, a single DPIA with school-specific addenda may be sufficient. If each school has different configurations, separate DPIAs may be needed.
  • DPO coordination: The trust DPO should coordinate the DPIA process, but individual schools’ safeguarding leads and IT staff should contribute to the risk assessment.
  • Procurement: Trusts have an opportunity to negotiate stronger data protection terms with vendors due to the scale of deployment. The data processing agreement should cover all schools in the trust.

Practical steps for MATs

  1. Complete one core DPIA covering the tool, vendor, and data flows
  2. Add school-specific addenda covering local configurations, access controls, and risk factors
  3. Ensure the trust-wide privacy notice covers the processing, or confirm that each school’s individual notice has been updated
  4. Provide standardised training materials for staff across the trust, with flexibility for local context
  5. Assign a trust-level lead responsible for monitoring the vendor and reviewing the DPIA on schedule

Where can schools find further guidance?

The following resources provide additional guidance on DPIAs and data protection for AI tools in schools:

Schools that want a practical overview of data protection obligations before starting the DPIA process can refer to the guide on data protection and AI: what schools need to get right.

Ask.School provides DPIA documentation and a data processing agreement. Learn more at ask.school.