Privacy & compliance

Privacy & data

Educator is built for UK schools. School students are minors, and their data is handled to a higher standard than in adult consumer products. This page explains exactly what we collect, how we use it, and the rights you and your students have.

Who we are, and which documents bind us

Educator is operated by Ben Willis, a sole trader based in England. For individual learners' accounts the data controller is Ben Willis. For school students the school is the data controller and Educator is the processor.

This page is guidance written for DPOs and school leaders. The documents that bind us are the privacy notice and the Data Processing Agreement. Where this page and either of those differ, the binding document takes precedence and we will correct this page. Our Data Protection Impact Assessment and Record of Processing Activities are available to school DPOs on request.

UK GDPR compliance

Educator operates under the UK General Data Protection Regulation (UK GDPR) and the Data Protection Act 2018. ICO registration is in progress and will be confirmed before the first paid subscription begins.

Educator acts as data controller for individual learners' accounts and as data processor for school students' personal data, where the school is the data controller.

A standing Data Processing Agreement (DPA) forms part of every school subscription. The DPA sets out the lawful basis for processing, the categories of personal data involved, the purposes for which we process it, and the school's rights as data controller. To request a copy for DPO review before your pilot, email support@educator-labs.com and we will send it within two working days.

For MATs and larger trusts: if you need a DPA that covers multiple schools under a single trust, contact us before signing up. We can issue a trust-level agreement that covers all schools in the MAT rather than requiring each school to sign separately.

Children under 13 - joining a school class: a pupil joins with a join code issued by their teacher, and that code - live, for a class that exists and has not been archived - is the evidence the school authorised them. The school is the data controller and provides the lawful basis for its pupils' educational use: normally Art. 6(1)(b) UK GDPR (performance of a contract) or, for a maintained school, Art. 6(1)(e) (public task). Educator acts as processor under the school's agreement. We do not rely on consent for school pupils and we collect no parental consent ourselves, so the sign-up is the same at any age. Parental communication on this route is the school's own arrangement under its policies. A teacher can also create pupils' accounts directly with Import students, in which case the pupil uses no code and goes through no sign-up at all (see Accounts created by the teacher below).

We are deliberate about what the join code does and does not prove. It is a shared secret, it is permanent for the lifetime of the class, and teachers often print it on a QR card, so it evidences that the school opened the class to its pupils rather than identifying any one pupil. The control that actually matters is roster control: the school decides who is in the class, sees every member on its own roster, and can remove a pupil's access by removing the class membership at any time.

If a parent objects: on the school route the school is the controller, so a parent should raise it with the school in the first instance. Short of erasure, the school can instruct us to remove the pupil from the class or to switch the account off, and we act on the school's instruction. If the school asks for the account to be deleted outright we do that too - see Data retention and deletion below for how erasure requests are handled and how quickly.

Children under 13 - signing up as an individual: with no school behind the account, nothing but a parent can supply a lawful basis. A learner who gives a date of birth under 13 can begin signing up, but the account stays locked until a parent or guardian confirms it by email. That consent is Art. 6(1)(a) UK GDPR read together with Art. 8, the provision that sets 13 as the age at which a child can consent to an information society service offered directly to them and requires parental authorisation below it. We email the parent a consent link. For up to seven days the child's account row - including the date of birth and the parent's email address - is held so the confirmation can be matched to it; that interim processing is what taking the step the child asked for requires, and it is how we meet the Art. 8 obligation itself. Practice is gated throughout. If no confirmation arrives inside the seven days the whole row is deleted automatically, and the parent's address is deleted with it. The consent email goes to the parent alone: no copy is sent to our own inbox, and the internal notice we get about the sign-up carries neither the parent's address nor the child's name.

Date of birth is self-declared, so it is an age check rather than verified proof of age - self-declaration sits at the lower-friction end of the age-assurance spectrum the Children's Code describes, which is proportionate for a service with no ads, no messaging between students, and no profile readable without signing in. Educator follows the ICO Age Appropriate Design Code (the Children's Code).

What data is collected

Data collected varies by account type. We apply data minimisation across all accounts: if we don't need a piece of data to run the service, we don't collect it.

School students

Display name: The name shown to the student's teacher, on their trading card, and on the class and school leaderboards. It is formed from the first and last name given during sign-up, so for a school pupil it is their real name (see Real name below). There is no separate alias.
Email address: Used for account authentication via email and password, Google, or Microsoft sign-in. Never displayed to other students. Teachers can see the email addresses of students in their class in order to manage the roster. A pupil imported by their teacher without an email address has a placeholder address instead (see Accounts created by the teacher below).
Year group & class: The class a student joins via their class code, or is imported into by their teacher, determines their year group and subject. This is what links a student to their teacher's dashboard.
Date of birth: Collected at sign-up, as an age check, whenever a learner signs themselves up, whether they join a school class or study on their own. It is not collected for a pupil whose teacher creates the account with Import students, because that pupil never goes through sign-up. It is not displayed anywhere in the app, is never shown to other students, and is used for nothing beyond that age check, apart from one safeguard: a staff join request from an account that holds a date of birth is refused, so a pupil account can never be approved as a teacher. For a school pupil it does not trigger a parental-consent step, because the school provides the lawful basis for its own pupils (see Children under 13 above).
Subject progress: XP earned, current streak, streak freeze count, mastery level per card (Unseen → Seen → Familiar → Proficient → Mastered), and session history. This is the core data that makes spaced repetition work. Without it, the app cannot adapt card frequency to each student.
Real name: Required. Sign-up asks for a first name and a last name and both must be given to finish onboarding, because a teacher has to be able to recognise the pupils on their own roster. There is no alias option on the school route. What is true is that the name never leaves the school: school students do not appear on the global leaderboard or league standings under any name, and no school student's name is published on a page an unauthenticated visitor can reach. Teachers identify a specific student by that name or by their email address. For an imported pupil the name is the one the school supplied in its spreadsheet.
Accounts created by the teacher: Instead of sharing the class code, a teacher can create pupil accounts in bulk by uploading a spreadsheet to Import students on the class page. The school supplies each pupil's name and, optionally, an email address. Where no email is given, Educator generates a placeholder address on an unroutable domain (ending class.educator.local), which serves only as a sign-in name and cannot receive email. No date of birth is collected and no join code is involved: the account is created already attached to the class, and the pupil skips the sign-up questions. The teacher is shown a temporary password for each new pupil once, on a credentials sheet to download or print, and we keep no copy we can read back; resetting passwords from the class page works the same way. A pupil who signs in with Google or Microsoft is never given a password this way, and an import cannot attach an existing account unless it already belongs to a pupil at the same school.

Individual students

Username: The alias shown on the global leaderboard and league standings, never the real name. It is not asked for at sign-up: a placeholder is generated for the account, and the first visit to the leaderboard offers a one-time prompt to replace it with something the learner has chosen.
Name: Required. Sign-up asks an individual learner for a first and last name too, the same as a school pupil. It appears on their own profile and trading card; it is not what the global leaderboard or league standings publish.
Email address: Used for authentication and (if opted in) product update emails. Never sold or shared with third parties.
Date of birth: Collected during sign-up for age-gating purposes. Students under 13 are subject to additional protections under the ICO Children's Code. The date of birth is self-declared, is not displayed anywhere, and is used only for that age check and to stop a pupil account being approved as staff.
Subject progress: Same as school students: XP, streak, mastery per card, and session history. Drives the spaced repetition engine and the global leaderboard.
Billing information: Pro subscribers pay via Stripe. Educator never sees or stores card numbers. Billing data is held entirely by Stripe and governed by their PCI-DSS compliance. Educator stores only the Stripe customer ID and subscription status.

Optional parent email (individual learners only)

This applies to individual accounts only. An individual learner may add a parent or guardian's email address from their profile page; the field is not offered to school students, the action that saves it does nothing on a school account, and the weekly send only ever selects individual accounts. Educator never emails the parent of a school pupil. Parent contact for a school pupil is the school's own arrangement, not ours.

Adding an address triggers a double opt-in: we email that address once to ask it to confirm, and no weekly update is sent until it does. After confirming, the parent receives a weekly email, sent via our email provider Resend, disclosing the child's first name and, for the past seven days, the number of practice sessions, the number of cards practised, the number of cards mastered, and the current streak. It also reports non-use: in a week with no sessions the email says so and suggests a nudge. The tone is supportive rather than comparative - it never ranks the child against anyone - but a parent should expect it to report a quiet week as well as a busy one. The parent email is never displayed publicly, never shared, and can be removed by the learner at any time, which stops the emails. Because this is a third party's personal data collected by the learner's own action, we hold it on the learner's instruction and delete it on their instruction.

Teachers

Name & email: Used for authentication, school account association, and service communication (e.g. the weekly digest email sent on Sunday evenings summarising class progress).
School & role: The school the teacher is associated with and their role (Teacher or Head of Department). Determines which classes, students, and analytics views are accessible.
Class structure: The classes a teacher has created, including class name, subject, exam board, and tier settings. This is configuration data rather than personal data, but it is associated with the teacher account.

All account types

Push notifications (optional): Stored only if a user turns practice reminders on from their profile page. We keep the push endpoint URL issued by their browser, the two subscription keys that go with it (p256dh and auth), and the device user agent string. No message content is stored. The record is deleted when the user turns reminders off, when the browser reports the subscription as expired, and when the account is deleted.
Technical & server logs: Standard request logs generated by our hosting provider, Vercel: IP address, request URL, timestamp, user agent, and the account ID where the user is signed in. Used only to keep the service secure and to debug problems, never for profiling or location inference. Retained for 30 days, which is Vercel's default, then deleted.

Cookies and analytics

Educator sets no advertising cookies and allows no third-party trackers. Three things are worth recording for a DPO review.

Attribution cookie: When a visitor first arrives from a link carrying a marketing tag, such as a utm_source or a referral parameter, we set one first-party cookie (edu_src) for up to 90 days. It records only which channel sent them, as an anonymous label such as “newsletter” or a referring site. It holds no name, email, or other identifier, is never shared, and is never used for advertising.
Usage analytics: We use Vercel Web Analytics and Speed Insights to count page views and measure performance. Both are cookieless: nothing is stored on the visitor's device, visits are aggregated and anonymised, and there is no cross-site tracking.
Session cookies: Signing in requires a session cookie, which our authentication provider Clerk sets and manages. It is strictly necessary to keep a user signed in, and is not used for analytics or advertising.

What we do not collect

This is equally important. Educator does not:

Use third-party advertising pixels or tracking scripts. There are no Meta, Google Ads, TikTok, or other ad-network tags on Educator. No student behaviour is fed into any advertising audience or lookalike model.
Build behavioural profiles for ad targeting. Practice data (which cards a student answered, how quickly, and with what accuracy) is used only to drive the spaced repetition engine. It is not sold, licensed, or used to infer student characteristics for commercial purposes.
Sell or share data with third parties. The sub-processors that host and run the app (Neon, Vercel, Clerk, Stripe, Resend, Sentry) are listed in the DPA and are used only to operate the service. No data is passed to publishers, data brokers, or research organisations without explicit written consent from the school. An email you choose to send us at support@educator-labs.com is handled in our support mailbox, not in the app.
Track location. No GPS, IP-to-location inference for profiling, or any other location signal is stored or used. Session data captures only answers to cards, not where those answers were given.
Use social media login data beyond authentication. Students and teachers may sign in with Google or Microsoft. From that account we receive the email address, display name, and profile picture, and we use them only to create and identify the Educator account. No other profile data is requested.

Student name privacy

School students are minors covered by a school DPA. Their names are used inside their own school - by their teachers, on the class board, on the school-wide board, and on their profile card, which only signed-in members of the same school (and Educator administrators) can open - because that is how a teacher recognises their own pupils. No school student's name is published on a public-facing surface, and none appears on the global leaderboard or league standings under any name.

Class leaderboard: Visible only to students in the same class and to the class teacher. It shows the student's name as the school knows it, alongside their XP and streak. No email address and no other identifying data appears on it.
School leaderboard: Visible only to authenticated members of the same school (teachers and students in any class at the school). The same rule applies: the student's name as the school knows it, plus XP and streak, with no email address or other identifying data. School students do not appear on the global leaderboard under any name.
Live session board: During a teacher-hosted live session the teacher's screen shows a real-time ranked board of students by display name. This is teacher-controlled, classroom-contextualised, and the only place in Educator where ranked competitive signals are intentional.
Individual accounts: Individual learners (not school students) appear on the global leaderboard and league standings under a username, never under their real name. Sign-up does ask an individual for a first and last name, and that is what their own profile and trading card show them - but it is not what those boards publish. The username itself is not asked for at sign-up either: a placeholder is generated with the account, and the first visit to the leaderboard offers a one-time prompt to swap it for a chosen one. Every individual account is given one at sign-up, so the board always has an alias to show rather than relying on the learner to have set one.

Why this matters: school DPAs typically prohibit processing children's personal data for purposes beyond the contracted service. Keeping student names off public leaderboards is not just good practice. It is necessary for schools to remain compliant with their own data protection obligations.

ICO Age Appropriate Design Code (Children's Code)

Educator is designed to be aligned with the UK ICO's Age Appropriate Design Code, which applies to online services likely to be accessed by children. The Code's fifteen standards are reflected throughout the product:

Data minimisation. We collect only what is functionally necessary. There is no “nice to have” data collection. Every field in the schema has a specific purpose tied to the spaced repetition engine, authentication, or teacher management.
No nudge techniques. Educator does not use FOMO countdown timers, streak-loss pressure messages (“you're about to lose your streak!”), or competitive rankings pushed to students outside the classroom. Gamification celebrates forward progress only: rank up banners, not “you were overtaken” alerts.
No location tracking. Educator does not collect GPS data or derive location from IP addresses for any profiling purpose.
Privacy by default. New student accounts are private by default. Leaderboard visibility is limited to the authenticated school context. Students do not opt out of public exposure. They never have public exposure in the first place.
Age-appropriate content. All card content is curriculum-aligned, written by the Educator team, and quality-checked against our card-quality rules. There is no user-generated content, no messaging between students, and no social graph.
Parental controls. Date of birth is collected at sign-up as an age check, and drives the parental-consent requirement on the individual route. For school pupils, the school controls who has access - an account is created only with a working class join code or by the teacher's own roster import, and the school can remove access via class membership. A pupil's data is managed under the school's DPA and schools can request deletion at any time.

Note for DPOs: we hold our own Data Protection Impact Assessment and are happy to share it, alongside our Record of Processing Activities, and to complete your school's supplier questionnaire. Contact support@educator-labs.com and we will respond within five working days.

Data retention and deletion

Educator maintains clear, published retention periods for all account types.

Active school subscriptions: Student and teacher data is retained for the duration of the school's pilot or subscription. On expiry or termination the licence locks immediately: students lose access, while teachers keep read-only access so the school can retrieve anything it needs. Personal data is then deleted in full within 60 days of that expiry, and we contact the school before we carry the deletion out. Sixty days is the outer limit, not a waiting period: a school that wants its data removed sooner only has to ask, and bulk deletion requests are actioned as below. This matches the retention term in the Data Processing Agreement, which is the binding commitment.
Pilot accounts: The four-week free pilot gives full access with no card required. If a school does not convert to a paid subscription after the pilot ends, the account is frozen immediately (student access off, teacher access read-only) and the data is permanently deleted within 60 days. The school is emailed when the pilot ends, and again before the deletion is carried out, so it has the chance to export anything it wants to keep.
Individual accounts: Individual accounts are not deleted automatically for inactivity. Your data is kept for as long as your account exists, and you can delete your account at any time from your profile settings page.
Data export: All users (school students, individual students, and teachers) can download their account data as a JSON file from their profile page at any time. The file includes account details, every session, and every card review. Note: school students can download their data but cannot self-delete. Account deletion for school students is the school's responsibility under the DPA (see Account deletion below).
Account deletion: Individual accounts and teacher/HoD accounts can self-delete from the profile page. School student accounts are covered by the school's DPA. Deletion is the school's responsibility. A school student who wants their account deleted should ask their teacher; the school can contact support@educator-labs.com to action it.
Bulk school deletion: Schools can request bulk deletion of a cohort's data, for example when a year group leaves the school. Contact support@educator-labs.com with the class or cohort to be deleted. Deletion is carried out within five working days and confirmed by email.

Right to erasure (Article 17): any student, parent, or school acting on a student's behalf can submit a right to erasure request. We will action it within 5 working days, and in every case inside the statutory 30 days, and confirm deletion in writing. To submit a request, email support@educator-labs.com with the subject line “Data erasure request”.

Security

Educator uses infrastructure designed for security by default, with no self-hosted servers for any part of the data path.

Database: All personal and session data is stored in Neon Postgres on AWS us-east-1 (Virginia, USA). Data is encrypted at rest and in transit. Neon is SOC 2 Type II certified. Cross-border transfers to the USA are covered under the UK International Data Transfer Agreement (UK IDTA).
Hosting & edge: The application is served via Vercel (UK edge, US fallback). All traffic is encrypted with TLS 1.2 or higher. Vercel holds ISO 27001 certification and is SOC 2 Type II compliant.
Authentication: Authentication is handled by Clerk, which manages session tokens and the OAuth flows. Sign-in is by Google, Microsoft, or email and password. Clerk also sends the authentication emails (password resets, account notices) directly from its own infrastructure under its SOC 2 Type II certification. Educator never stores passwords. Clerk is GDPR-aligned.
Payments: Payments are processed entirely by Stripe, a PCI-DSS Level 1 certified payment processor. Educator never sees card numbers, CVCs, or full bank details. We store only the Stripe customer ID and subscription status required to manage access.
Error tracking: Application errors are captured by Sentry for debugging. Sentry is configured not to send default personal data (sendDefaultPii: false), and a beforeSend hook removes the email address, IP address, cookies, and Authorization and Cookie headers from every error report before it leaves our servers. Where a signed-in user is attached to a report, only their pseudonymous account ID remains.
Email: Transactional emails (weekly teacher digest, account notifications) are sent via Resend from the educator-labs.com domain with full DKIM and DMARC authentication. We do not send marketing email to students. When an account is created we also send ourselves a short internal notice so we know it exists. That notice carries no personal data: no name, no email address, no class name. It says only what kind of account was created, the subject, a count for a class import, and a link into our admin area. The emails users receive (welcome, “you've joined”, parental consent) go to the user alone, with no copy to us.

Sub-processor list: the list of sub-processors that host and run the app (Neon, Vercel, Clerk, Stripe, Resend, Sentry) along with their processing purposes, data locations, and certifications is available on request. Emails you send to our support address are handled in our support mailbox rather than in the app. To obtain the list, contact support@educator-labs.com.

Contact and data requests

For all data-related queries (whether from a school, a student, a parent, or a Data Protection Officer) contact us at:

Email: support@educator-labs.com

We aim to respond to all data requests within 72 hours on school days, and within the statutory 30-day window for Subject Access Requests (SARs) and erasure requests regardless of when they arrive.

Data Processing Agreement: Request a copy of the DPA before starting a pilot. Include your school name and your DPO's email address and we will send the document for review within two working days.
Subject Access Request (SAR): Students and parents have the right to a copy of all personal data we hold. We will provide a complete data export within 30 days. Schools submitting on behalf of a student should include the student's display name and the email address used to register.
Erasure requests: Request deletion of a specific student account, a cohort, or an entire school's data. Actioned within 5 working days, matching the commitment in our Data Processing Agreement, and in every case inside the statutory 30 days. Deletion is confirmed by email.
Safeguarding concerns: If you have a safeguarding concern related to Educator (for example, you believe a student's account has been accessed by an unauthorised third party) email support@educator-labs.com immediately with the subject line “Safeguarding”. We will respond within four hours on school days and escalate internally to our designated safeguarding lead.
ICO complaints: If you are not satisfied with our response to a data request, you have the right to complain directly to the ICO at ico.org.uk/make-a-complaint. We would always prefer to resolve a concern directly first. Please give us the chance to do so.

School setup & permissions: roles, class creation, live sessions, homework, and school licensing
Onboarding: step-by-step setup for teachers, school students, and individual learners