Pupil data is not used to train general-purpose AI models. The school or trust remains the controller and retains ownership, with full export available at any time including at termination, at no cost.
Who is responsible for what
- The school or trust is the controller. It determines what pupil data is collected and why. That responsibility does not move to a software supplier.
- Edves is a processor, acting on documented instructions under a data processing agreement.
- Obligations to pupils and families — privacy notices, lawful basis, subject access, rectification, erasure where applicable — remain the school’s.
A supplier saying “we’re GDPR compliant so you’re covered” has either misunderstood the allocation or is hoping you have. The correct answer to “are you compliant?” is “here is our DPA, here are our sub-processors, here is our security documentation, and here is what we will sign.”
Special category and sensitive data
Schools hold considerably more sensitive data than most organisations of their size: health and medical information, SEND records, safeguarding concerns, free school meal eligibility, ethnicity, religion, looked-after status, and details about family circumstances.
Much of this is special category data under UK GDPR, requiring an Article 9 condition in addition to a lawful basis. In practice this means access control matters more in a school than almost anywhere.
How Edves handles pupil data
- Role-scoped access down to field level. A subject teacher sees their own classes. A SENCO sees SEND detail. Safeguarding records sit behind separate permissions and are not visible in general pupil views. Access follows role, not seniority.
- Audit logging on every access. User, time, record. This is what converts an access policy into something enforceable, and it is the control school systems most often lack.
- Configurable retention set to the school’s own retention schedule, not a supplier default.
- Data minimisation — the school decides what is collected; unused fields are not forced on it.
- Subject access support — a pupil’s record can be extracted for an SAR without a manual trawl across systems.
- Parent access through the app, which handles a proportion of routine access requests before they become formal.
DPIAs
Introducing a new system that processes children’s data at scale, particularly with any automated processing, normally requires a Data Protection Impact Assessment. Edves provides the documentation a DPIA needs — processing purposes, data categories, retention, security measures, sub-processors, transfer arrangements and automated processing description — rather than leaving a DPO to reverse-engineer it from a website.
The DPIA remains the school’s document and the school’s decision. A supplier that offers to write your DPIA for you has misunderstood whose assessment it is.
AI and pupil data
Stated plainly, because this is where schools should press hardest:
- Pupil data is not used to train general-purpose AI models.
- Pupil data is not sold and not used for advertising or commercial profiling.
- Data used to personalise teaching stays within the school’s tenant.
- Sub-processors are disclosed, with processing locations identified.
- Automated processing that produces indicators surfaces its inputs, so a human can see why a pupil was flagged and disagree.
- These terms are contractual and provided during procurement, not marketing claims.
See DfE generative AI standards for the product-level assessment.
The bigger practical risk
In most schools the realistic data protection failure is not the procured system. It is:
- Pupil data pasted into a consumer AI tool with no DPA behind it.
- Mark books and SEND lists on personal laptops that leave with staff.
- A WhatsApp group containing pupil information with former staff still in it.
- Trip lists and medical information emailed to personal addresses.
- Access rights that were never revoked when someone changed role or left.
A single system with proper access control and leaver processes helps with all of these. But the sanctioned alternative has to arrive with the policy, or the underlying pressure simply routes around it.
Data ownership and exit
| Question | Position |
|---|---|
| Who owns the data? | The school or trust, stated in contract |
| Can we export everything? | Yes, including full history, in a usable format, at any time |
| What does export cost? | Nothing, including at termination |
| What happens at termination? | Export delivered, then deletion on the school’s instruction and schedule |
| Is data ever withheld to force renewal? | No |
That last row deserves attention during procurement. It is the only leverage a school retains after signature.
Questions for any supplier
- Are you controller or processor here? If they say controller, stop.
- Can we see your DPA and your sub-processor list before we commit?
- Where is our data hosted and processed?
- Who at your company can access our pupil data, under what circumstances, and is it logged?
- What is your breach notification commitment to us, in hours?
- Show me the contract clause on AI model training.
- What does full export cost at termination, and in what format?
Data protection law and regulator guidance continue to develop. Confirm current obligations with the ICO or your own data protection officer; this page describes Edves’s posture and is not legal advice.