How VESPA Academy meets current ICO and DfE expectations
The ICO published Edtech examined in June 2026, reporting on audits of 28 education technology providers. In July 2026 the DfE added a Procuring educational technology (EdTech) section to its Data protection in schools guidance, directing schools to take those findings into account.
Our platform, database and published policies were independently reviewed in August 2026 (internal forensic compliance audit). This page maps how we resolve each issue — the control or process — not only which document mentions it.
How to read this page. Each row states the mechanism first, then links to evidence. If a control is still being built, we say so under In development.
Against the ICO’s findings
| ICO finding across audited providers | How VESPA Academy resolves it |
|---|---|
| Around 70% were acting as controller for some children’s data without recognising it | How For school platform data we act as processor only: the school decides purpose and lawful basis; we process under the DPA. We act as controller only for our own commercial data (billing, enquiries, marketing). Student coaching records are not treated as 4Sight’s own dataset for product R&D. Evidence: Privacy Policy · DPA v2.0 |
| Around 70% could not show schools had authorised reuse of children’s data for product development, analytics or AI training | How Product improvement and AI training on children’s data are not instructed purposes. National benchmarking uses anonymous norms (no student or school identifiers) and is declared in DPA Schedule 1 as an instructed service feature. Optional AI is user-invoked API processing only (see AI row below). A completed DPA naming the school/trust is issued at trial start, estimate acceptance or payment, and is incorporated into our Terms. Evidence: DPA Schedule 1 · AI Usage Policy · Terms §9 |
| Data labelled “anonymised” was still identifiable; some retained indefinitely with reidentification keys | How National normative tables contain no student or school identifiers and cannot be joined back to individuals from those tables. School-level analytics stay identifiable only to that school and are visible only to its authorised users (row-level security). Evidence: Data flow summary (§5 Benchmarking) · DPA Schedule 1 |
| Sub-processor terms permitting retention of children’s data for AI training | How Our OpenAI organisation has API call logging, hosted tools and data sharing for model improvement disabled. Under OpenAI API business terms, customer data is not used to train models. Providers may retain API inputs briefly for abuse monitoring only — not for training. We do not train, fine-tune or host models ourselves. Evidence: AI Usage Policy · compliance pack OpenAI org controls (August 2026) |
| Around 70% had agreements lacking Article 28 detail | How DPA v2.0 addresses each Article 28(3) obligation, with a 30-day sub-processor notice period, a right to object, and a right to terminate affected services without penalty. The DPA is issued completed (school/trust named) and incorporated by reference — countersignature optional. Evidence: DPA v2.0 · SPL-2026.08 |
| Around 80% published privacy information too vague to explain what happens to children’s records | How We publish a plain-language Student Privacy Policy, a stage-by-stage Data Flow Summary, and a versioned sub-processor list with changelog — so a student, parent or DPO can see what moves where without reading the full DPA first. Evidence: linked documents above · policies index |
Against the DfE’s July 2026 procurement questions
| What the DfE tells schools to ask | How we meet it |
|---|---|
| Walk us through how personal data flows at every stage |
How
Account / roster → EU database (eu-north-1) → in-school questionnaire, coaching and reporting → optional AI prompt to OpenAI (US, SCCs; no training) when a user activates a feature → response may return to the EU store → erasure on controller instruction.
Evidence: /data-flow-summary.html
|
| Which sub-processors, where, and under what safeguards? | How Canonical public list with location and transfer basis per provider, versioned with changelog. Material changes notified with objection rights under the DPA. Evidence: SPL-2026.08 |
| Is data used to train AI models? How are outputs moderated? What controls do schools have? | How No training on school/student data by us or under OpenAI API terms (org toggles for model-improvement sharing are off). Portal AI runs only when a user deliberately activates a feature control (Generate, Send in chat, etc.) — there is no separate consent tick-box on every click; the button/send is the invocation, and nothing runs silently on student login. Outputs are advisory; staff coaching drafts are for human review. Schools can request that AI features be disabled for their establishment; some modules are also plan-gated. Evidence: AI Usage Policy (every portal AI feature listed with typical prompt fields) |
| Does this involve profiling pupils? | How VESPA scores and AI text are decision-support / coaching aids. Staff decide interventions. They are not solely automated decisions producing legal or similarly significant effects; consequential use requires human review (DPA clause 7 / Art. 22). Evidence: DPA clause 7 · AI Usage Policy |
| Will we need a DPIA, and will you help? | How Controllers remain responsible for deciding whether a DPIA is required. We provide a pre-populated supplier fact pack so you are not starting from a blank page. Evidence: DPIA support pack |
| How is data returned and deleted, in what timescale, with what confirmation? | How On controller instruction, personal data is removed from production systems (target within 30 days; currently via documented runbook). CSV export available to staff during the contract; full extract on request. Written confirmation of deletion provided on request (DPA clause 4.7). Routine leaver purge automation is in development (see below). Evidence: Data Retention Policy |
| What security assurance can you evidence? | How Cyber Essentials certified — IASME-CE-060416, valid 2 July 2026 to 2 July 2027, independently verifiable. Hosting/DB layers also carry SOC 2 Type II / ISO 27001 at the provider level (Supabase, Vercel). Evidence: Verify certificate · Information Security Policy |
AI invocation — plain English. Users do not tick “I agree” on every AI click. Each AI call is started by a clear UI action (for example generating a study plan or sending a UniGuide message). That action is what causes data to be sent to OpenAI for that request. There is no background AI processing of student records on login. School-wide disable of AI features is available on request (and some product modules are plan-gated). Full feature list and typical fields: AI Usage Policy.
UK GDPR obligations (summary)
| Obligation | How it is met |
|---|---|
| Art. 5(1)(a) transparency | Published policy set including a student-facing privacy notice |
| Art. 5(1)(c) minimisation | Demographic fields and email addresses are not sent to AI APIs for the features reviewed; each feature sends only the data that feature requires (first name may be used where personalisation needs it) |
| Art. 5(2) accountability | Independent review pack, versioned documents, policy archive |
| Art. 12–14 | Student Privacy Policy, for schools to share with students |
| Art. 22 | DPA clause 7 — decision-support only; human review for consequential use |
| Art. 28(2)–(3), (9) | DPA v2.0; general authorisation with 30-day notice and objection rights |
| Art. 32 | Encryption in transit and at rest, row-level security, MFA on administrative systems, SSO support, least-privilege access, audit logging, Cyber Essentials |
| Art. 33–34 | ICO notification within 72 hours where required; controller notified without undue delay |
| Art. 35 | DPIA support pack provided to schools |
| Chapter V transfers | Region stated per sub-processor, including Vercel serverless functions in the US (iad1), under SCCs and the UK IDTA. Primary application data stored in the EU (eu-north-1, Stockholm) |
| Children’s code | Applied where we act as controller |
In development
- Automated leaver erasure. Erasure requests are executed against a documented runbook. Automation of the routine leaver purge is in development.
- Reducing international transfers. EU-region inference options are available from our AI providers, and relocation of portal serverless functions to a UK region is under evaluation.
Contact
Data Protection Lead · admin@vespa.academy
Full policy set: vespa.academy/policies · Version archive: /policy-archive/
© 2026 VESPA Academy — 4Sight Education Ltd