Edvolve
Open navEdvolve Journal The ICO's Latest EdTech Audit
This article is intended for Headteachers · SBMs · DSLs · MAT leaders
Important questions schools should ask when evaluating what education technology to invest in.
In June 2026, the Information Commissioner's Office published the results of an audit into 28 EdTech providers used in UK schools. The findings weren't an isolated criticism of a few bad actors, the ICO found compliance gaps in contracts between suppliers and schools, privacy information that hadn't been kept current and incomplete mapping of where children's data actually goes once it enters a platform. The regulator is now in discussions regarding creating a dedicated EdTech code in response.
For school leaders, this isn't a story to read and move past, it’s a prompt to ask a question that's easy to defer in a busy term - do we actually know how the platforms our pupils and families use are handling their data?
This article isn't about any one provider, including us, it's about what to look for and what to ask when evaluating any EdTech platform your school relies on.
Why this matters more in 2026 than it did a few years ago
Two things have changed recently, together they raise the bar considerably.
The first is the Data (Use and Access) Act 2025 (DUAA), which updates UK GDPR and the Data Protection Act 2018. It introduces explicit "by design" expectations for online services likely to be accessed by children and it requires schools to have a formal, documented complaints-handling process in place, not an email address buried in a policy PDF, but a clear route, a named responsible person, defined response timescales and a system for logging outcomes.
The second is a shift in how procurement actually works. Buying a platform for a school used to be largely a features conversation and increasingly it isn't. Multi-academy trusts and school business managers are now expected to interrogate how a product handles data, not just that it complies with a standard on paper. Deals that would once have closed on a strong demo are now stalling at the documentation stage, not because the product lacks features, but because the supplier can't clearly evidence how data protection is built into the product itself.
Put simply, schools are now expected to ask harder questions and suppliers are expected to have harder answers ready.
What the ICO actually found
The specific gaps identified in the June 2026 audit are worth knowing, because they're a useful checklist for any platform your school is currently using or considering:
- Contracts that don't reflect reality. Some supplier contracts with schools didn't clearly establish who the data controller and processor were, or didn't include the specific clauses UK GDPR requires when a processor is handling data on a school's behalf;
- Privacy information that's gone stale. Privacy notices that hadn't been updated to reflect how the product actually works today, sometimes years after the notice was first written;
- Incomplete data mapping. Suppliers who couldn't fully account for where data flows once it enters their systems, including, in some cases, where it's shared with third parties for purposes like analytics or advertising;
- None of these are abstract, theoretical risks. They're the kind of gaps that turn into safeguarding concerns, parent complaints, or in the worst cases, the kind of incident that ends up reported to the ICO within the mandatory 72-hour window.
The questions every school should be asking
Whether you're reviewing your current platforms or evaluating a new one, these are the questions worth asking directly, and the answers should be clear and unqualified:
Who is the data controller, and who is the processor?
Your school is almost certainly the controller. The platform provider should be acting as a processor under a written contract that includes the specific clauses UK GDPR mandates, not a generic terms-of-service document.
What data is collected, and is all of it necessary?
Collecting more data than a feature genuinely requires is one of the most common issues procurement teams flag. If a platform is gathering information it doesn't need to deliver its core function, that's worth questioning regardless of how the feature is marketed.
Is any data used for advertising, profiling, or shared with third parties?
This should have a simple, direct answer. If the response involves qualifications, e.g. "only for service improvement," "only in aggregate," "only with trusted partners", it's worth pressing further on what those terms actually mean in practice.
Is there a Data Protection Impact Assessment (DPIA) for this product?
Where processing is likely to involve higher risk, and most platforms used directly by children fall into this category, a DPIA should already exist. It shouldn't need to be created in response to your question; it should be something the supplier can produce immediately because it reflects how the product genuinely operates.
Is messaging or stored communication encrypted, and who can access it?
For any platform involving staff-parent or staff-pupil communication, role-based access controls and encryption aren't optional extras. If a member of staff can access conversations they have no legitimate reason to see, that's a structural problem, not a setting that can be fixed later.
What happens to data when a pupil leaves or when the contract ends?
Retention and deletion policies are often the least visible part of a platform's data practices and one of the easiest things to overlook until a parent or a leaver specifically asks.
What "secure by design" should actually mean
The phrase "secure by design" gets used a lot in EdTech marketing, often as a sentence rather than a description of how a product is actually built. It's worth being sceptical of any provider who can't immediately explain, in plain terms, what that phrase means for their specific platform.
In practical terms, this should look like:
- Role-based access controls that are genuinely granular, not just "staff" and "everyone else," but access scoped to what each role actually needs to see;
- Encryption of stored and in-transit communications between staff, parents and pupils;
- A contractual and technical commitment that data is never used for advertising or sold to third parties - not as a policy statement, but as something built into how the platform is architected;
- Data mapping the provider can produce on request, not assemble after the fact;
- A privacy notice that's reviewed regularly enough to reflect what the product currently does, not what it did when it launched.
This is the standard we hold the Edvolve platform to and it's the standard we'd encourage every school to expect from any provider, including providers your school is already using today.
A practical starting point for this term
If your school hasn't reviewed its EdTech data practices recently, the summer is a sensible window to do it before new systems and staff arrive in September. A simple audit doesn't need to be complicated:
- List every platform pupils, parents or staff interact with that processes personal data;
- For each one, check whether the contract includes proper processor clauses and whether the privacy notice has been reviewed in the last twelve months;
- Ask each supplier the questions above, in writing, and keep the responses on file;
- Flag any gaps to your DPO or governing body before renewal dates arrive, not after.
None of this requires specialist legal knowledge, it requires treating data protection as a standing item, not a once-a-year compliance exercise.
The ICO's audit is a reminder that good intentions aren't the same as good practice. Schools are well within their rights, and increasingly expected, to ask suppliers to demonstrate, not just state, how children's data is protected. Any provider that can't answer those questions clearly is telling you something important, whether they mean to or not.
•••
•••••