Data protection
Data Protection Impact Assessment
Written for a school's Data Protection Officer, DSL or governors who need to see the risks we have identified and what we do about them. It sits alongside our privacy policy, GDPR page and security page.
1. Why we did this
Online Ready is used by children, and a school is the controller of that data. Even where a DPIA is not strictly required, we think a service for children should be able to show its working. This document covers the student course, the teacher and trust dashboards, and the ordering process.
2. What the service does
A school orders seats. Each class gets a class code. Students use the code to join, choose a display name and a 4-digit PIN, and complete seven short modules with quizzes. On passing a module they earn a certificate. Teachers see progress on a dashboard. Multi-academy trusts can see and allocate seats across their schools. Students can write short reflections in some activities.
Roles. The school is the controller for student data and we are the processor. For order and invoicing details (teacher name, email, finance contact), we are the controller.
3. What data we process
| Data | Whose | Why | How long |
|---|---|---|---|
| Display name, class code | Student | To show progress to the teacher and name the certificate | Deleted 1 September each year |
| PIN (stored only as a one-way hash) | Student | So a student can return to their own progress | Deleted 1 September each year |
| Modules completed, quiz scores and attempts | Student | Progress, passing, certificate | Deleted 1 September each year |
| Written reflections (encrypted in the student's browser with a key derived from their PIN) | Student | Learning activity; teacher can see them only where the student's device has shared them | Deleted 1 September each year |
| Certificate ID, month issued, school name (no student name) | Student (not identifiable) | So a certificate can be verified as genuine | Kept |
| Teacher name, email, school, finance contact, PO number | Staff | Set up access, invoice, support | Paid orders archived for accounting; unpaid kept until paid or cancelled |
| Safeguarding team name, room and optional photo | Staff (DSL) | Shown to students so they know who to talk to | While the licence exists |
| Technical logs (IP address, request times) | Anyone | Security, rate limiting, fault-finding | Short-lived, held by our hosting providers |
What we do not collect from students: email address, date of birth, home address, photo, location, device identifiers for tracking, or any advertising data. There is no public sign-up, no analytics cookie, and no profiling.
Special category data. We do not ask for any. A student could choose to write something sensitive in a reflection, which is why reflections are encrypted so that we cannot read them, and why the course tells students to talk to a trusted adult rather than write about serious concerns.
4. Necessity and proportionality
Lawful basis: the school's public task or legitimate interest in educating and safeguarding pupils (Keeping children safe in education expects schools to teach online safety). For our own order data, performance of a contract. We collect the minimum needed: a student needs a name for the certificate and a PIN to resume. Every student record is deleted automatically on 1 September, whether or not the school has paid again. Students and parents can ask their school, or us, to access or delete a record at any time.
5. Risks and what we do about them
| Risk | Likelihood / severity | What we do | Left over |
|---|---|---|---|
| One school seeing another school's data | Low / High | Row-level security on every table; the browser holds only a public key; reads and writes go through server-side functions scoped to the school's class code or dashboard token | Low |
| Someone guessing a student's PIN to read their progress or reflections | Medium / Medium | PIN stored as a hash; attempts are limited and the account locks after repeated failures; reflections are encrypted with a key derived from the PIN, so a database leak alone does not expose them | Low |
| A student faking a certificate | Medium / Low | Quiz answers are held on the server and marked there; certificates are only issued by the server; certificate IDs can be checked on our verification page | Low |
| Student writes something sensitive in a reflection | Medium / Medium | Reflections encrypted; course prompts students to speak to a trusted adult; the safeguarding team is shown inside the course | Medium. The school's safeguarding procedures remain the safety net |
| Data kept longer than needed | Low / Medium | Automated deletion every 1 September (a scheduled job, not a manual task) | Low |
| Data leaving the UK | Medium / Low | Database and storage are in the UK (AWS London). Our functions are set to run in London. Our hosting and email providers are US companies and rely on UK-approved transfer safeguards (see section 6) | Low |
| A teacher losing access or a student being locked out | Medium / Low | Teacher dashboard link can be re-sent by email; teachers can reset a student's PIN without ever seeing it, and the student keeps their progress | Low |
| Public access to safeguarding team photos | Low / Low | Photos are optional, staff-chosen, and only a name and room are required. The storage area for these photos is currently publicly readable if the exact file address is known. We plan to switch to time-limited links | Low-medium until fixed |
| A processor suffering a breach | Low / High | Data minimisation limits what could be exposed (no email, address or date of birth for any student); processors are named below; we will tell the school without undue delay and help it assess whether the ICO must be told within 72 hours | Low |
| Our own mistakes or one-person dependency | Medium / Medium | Honest limitation: this is a small operation. Backups are held by Supabase; changes are logged; annual review of this document | Medium |
6. Who else processes data (sub-processors) and their agreements
| Provider | What for | Where | Data processing agreement |
|---|---|---|---|
| Supabase | Database, file storage | UK (AWS London, eu-west-2) | Supabase DPA |
| Vercel | Website and server functions | Functions run in London (lhr1); content delivered from a global network; US company | Vercel DPA |
| Resend | Emails (login details, dashboard links, invoices) | US company | Resend DPA |
| Monzo | Receiving bank transfers; we read payment references only, never card details | UK | Bank terms; we hold no student data in it |
For US providers we rely on the UK Extension to the EU-US Data Privacy Framework where the provider is certified, or the standard contractual clauses and UK addendum in their agreements. We have not yet had these agreements reviewed by a solicitor. We will tell schools before adding or replacing a sub-processor.
7. Children's code
Students can only join through a class code a school has issued, and we process their data only to deliver the course on the school's instruction, so the ICO's Children's code does not formally apply to us. We follow its spirit anyway: minimum data, no profiling, no nudging, no advertising, and plain language for the age group.
8. Outcome
We assess the overall residual risk to students as low, because the data is minimal, short-lived and partly encrypted, and a school controls who joins. The two items we are working to improve are the public photo storage and independent legal and security review. We do not believe the processing needs prior consultation with the ICO.
9. Actions we have committed to
- Move safeguarding team photos to time-limited links.
- Complete our ICO registration and have these documents reviewed by a solicitor.
- Commission an independent security test and accessibility audit.
- Review this DPIA every year, and whenever we change what data is collected or who processes it.
Questions
Email us if your DPO needs more detail, a signed processing agreement for your school, or a copy of this document for your records.