How we meet UK GDPR, principle by principle.

Last updated October 2026

Our role: processor for student data, controller for our own records

For student data (name, PIN hash, quiz results, reflections), your school is the data controller — you decide to use the course and enrol your students, under your own safeguarding and education functions. We act as a data processor, handling that data only on your instruction, under the terms you agree to when you order seats. We don't use student data for our own purposes.

For order and invoicing data (teacher name, email, finance contact, PO number), we act as the controller — we collect this ourselves, directly from you, to set up and invoice the service you've asked for.

The Children's code (Age Appropriate Design Code)

The ICO's Children's code applies to online services "likely to be accessed by children" on a direct-to-consumer basis, or to an edtech provider that processes children's data beyond a school's instructions (for example, for its own marketing, research, or product development). Online Ready doesn't meet either test: students can only join through a class code a school has deliberately issued (there's no public sign-up), and we only ever process student data to deliver the course and issue a certificate, on the school's instruction. On the ICO's own published test for edtech providers, the code's 15 standards don't formally apply to us — but we've built the product to follow the spirit of them anyway (data minimisation by default, no profiling, no nudging a child to share more than needed, clear language written for the age group using it).

The seven principles

1. Lawfulness, fairness and transparency

Your school's own legitimate interest or public task in educating and safeguarding pupils is the lawful basis for processing student data — we act under that as your processor. For our own order/invoicing data, our lawful basis is performing the contract you've asked us to perform. Nothing is processed in a way a student, parent, or teacher wouldn't reasonably expect from an online safety course — this page, the privacy policy, and the security page are how we stay transparent about exactly what happens.

2. Purpose limitation

Student data is used only to run the course, mark quizzes, and issue a certificate. It is never reused for marketing, advertising, profiling, or sold on. Order/invoicing data is used only to set up access and send the invoice — not for marketing without separate consent.

3. Data minimisation

A student only ever provides a display name and a 4-digit PIN they choose themselves — no email address, date of birth, or home address is collected from students at any point. The PIN itself is never stored (see "integrity and confidentiality" below). Written reflection answers are only collected where a module's activity specifically calls for one, and students aren't required to write more than the activity asks.

4. Accuracy

Students type their own name, so accuracy there sits with them (as it would on paper). Teachers can see every result on their dashboard and flag anything that looks wrong to us directly. Safeguarding-team details (DSL name, room) are editable by the school at any time from their own dashboard, so they're never stuck out of date.

5. Storage limitation

Every student record — name, progress, quiz scores, encrypted reflections, and certificate — is automatically and unconditionally deleted every year, on 1 September, for every school, paid or free. Nothing personal about a student is kept beyond one academic year by default. See the retention table below for exactly what happens to each type of data.

6. Integrity and confidentiality (security)

Covered in full on our security page, in short: the database is hosted in the UK (AWS London region, via Supabase); written reflections are encrypted in the student's own browser with a key derived from their PIN before anything is sent anywhere, so nobody — including us — can read one without that student's PIN; PINs themselves are never stored, only a one-way hash; and database access is restricted with row-level security plus server-side functions scoped by school, so one school can never see another's data. We never handle card or bank details — schools pay by invoice/bank transfer.

7. Accountability

This page, the privacy policy, and the security page are our public record of what we do and why. There's a single named contact for any data protection query (below). We're a small, early-stage operation — we're honest that our Data Protection Impact Assessment is published (as a draft pending legal review), but we haven't yet finished our ICO registration, and we're not going to claim otherwise. This page will be updated the moment that is done.

Data retention schedule

This runs as an automated job every 1 September — it isn't a manual "when we remember to" process.

Who else processes data on our behalf (sub-processors)

Where a provider is based outside the UK, we rely on their published standard contractual clauses or equivalent safeguards for the transfer. The agreements are public: Supabase, Vercel and Resend. We haven't yet had them formally reviewed by a solicitor — that's part of the "pending legal review" note at the top of this page.

Your rights, and how to use them

If you're a school, you're the controller for your students' data — contact us at email us to access, correct, export, or delete any student's data, and we'll action it directly. If you're a student, parent, or carer, the quickest route is your school's Data Protection Lead, since they hold the relevant consent and context — but you're welcome to contact us directly too, and we'll loop your school in. If you're a teacher or finance contact whose own details we hold for an order, contact us directly for access, correction, or deletion.

Questions

Email us for anything on this page. We'll also take complaints seriously and try to resolve them directly — though you always have the right to raise a concern with the Information Commissioner's Office (ICO) as the UK's data protection regulator.