Privacy policy
Last updated:
Shuttle Learning Privacy Policy
1. Plain summary
This policy explains how Shuttle Learning Limited handles personal information across our marketing website (shuttlelearning.com) and our new educational web app for learning OCR GCSE Computer Science (J277) in Python. We are a UK company and you can reach us any time at support@shuttlelearning.com. In short: we collect as little as we can, we never sell your data, and where your school sets up your account we act on the school's instructions.
Plain English summary: This page tells you what we collect, why, and what your rights are.
2. Who we are and how to contact us
Shuttle Learning Limited, 167-169 Great Portland Street, London, England, W1W 5PF. Email: support@shuttlelearning.com.
We are not legally required to appoint a Data Protection Officer (DPO) under UK GDPR Article 37 (mandatory only for public authorities, large-scale regular and systematic monitoring, or large-scale processing of special category data). Our internal data protection contact for any privacy question is support@shuttlelearning.com.
Plain English summary: We are a London-based company; email us with any privacy question.
3. What this policy covers
The marketing website at shuttlelearning.com (built on Framer). The canonical URL for this policy is https://www.shuttlelearning.com/legal-pages/privacy-policy.
The educational web app, served at our learn subdomain.
Plain English summary: This covers both our website and our learning app.
4. Our role: controller or processor
Whether we are the "controller" (we decide why and how data is used) or a "processor" (we act on someone else's instructions) depends on how you use our services. We follow the same model used by other UK edtech providers. Educake, for example, states that for students it is "a 'data processor' on behalf of the School... This means that the School is the 'data controller' and we only process students' personal data in accordance with the School's instructions." Seneca similarly states that "in most cases, Seneca acts as a data processor... The school will be the data controller."
Marketing website visitors, contact form, mailing list: Shuttle Learning is the controller.
Educational app users who sign in with a school Microsoft account: the school is the controller and Shuttle Learning is the processor under an Article 28 Data Processing Agreement. We only process student and teacher data on the school's documented instructions. Sign-in is restricted to school domains we have approved via our domain allowlist.
Plain English summary: On the app your school is in charge of your data and we act for them; on the website we are in charge.
5. What we collect, why, and our lawful basis
Note on lawful basis: where the school is controller for app data, the school sets the lawful basis (typically public task or legitimate interests for core teaching and assessment) and we process on its behalf. The bases below are indicative.
Category | Purpose | Lawful basis (Art 6) | Retention |
|---|---|---|---|
Marketing-site browsing telemetry (pages viewed, device/browser, approximate country) | Run and improve the website; measure traffic | Consent (analytics cookies) | Limited period set in Analytics |
Contact form data (name, email, message) | Respond to enquiries | Legitimate interests / steps before a contract | Up to 12 months after last contact |
Mailing list (email, preferences) | Send updates you asked for | Consent | Until you unsubscribe |
App account (Firebase Auth UID, school Microsoft email, display name, provider microsoft.com, student/teacher role claim) | Create and run your account; tell students from teachers | School determines (typically public task or legitimate interests); contract | While active, plus 6-month grace |
Class memberships (classId, teacherId, student UIDs, rotatable join codes) | Group students with their teacher | School determines (typically public task) | While active, plus 6-month grace |
Attempts (UID, classId, lessonId, questionId, submitted source code or MCQ answer letters, AI score and feedback, timestamps, attempt number) | Mark work and show progress | School determines (typically public task) | 12 months after end of relevant school year unless the school instructs otherwise |
Lesson summaries (AI "what went well / even better if" plus MCQ score) | Give feedback to student and teacher | School determines (typically public task) | 12 months after end of relevant school year unless the school instructs otherwise |
Operational telemetry (rate-limit counters on users/{uid}.rateLimit.*) | Prevent abuse and keep the service stable | Legitimate interests | Rolling, short |
Cookies / local storage (Firebase Auth token cached in IndexedDB; one localStorage key shuttle.activeClassId) | Keep you signed in and remember your active class | Strictly necessary (essential) | Session / until cleared |
Server logs (Cloud Function logs: UID, lessonId, questionId; raw submitted code and email address are redacted) | Diagnose faults | Legitimate interests | 30 days |
We do not collect home address, phone number, payment details, biometrics, or location beyond approximate country.
Plain English summary: We collect your school email, your code and answers, and your scores, and we keep them only as long as needed.
6. Children's data and the ICO Children's Code
Our app users are aged 14 to 16, so they are children in data protection law. The ICO's Children's Code (the Age Appropriate Design Code) contains 15 standards for online services likely to be accessed by children. The ICO's "Introduction to the Children's code" confirms the code "does not apply to schools and educational and training institutions processing the information of people under the age of 18 for the purposes of education", but that "the Children's code may apply to providers of edtech used in schools." We therefore aim to meet its standards.
In practice that means: high-privacy settings by default; age-appropriate, plain language (Standard 4, transparency); the best interests of the child as a primary consideration (Standard 1); a Data Protection Impact Assessment (Standard 2); data minimisation; no profiling for marketing; no behavioural advertising; no nudge techniques designed to weaken privacy; and no geolocation beyond approximate country. We do not use children's data for our own commercial purposes such as product development or research, which is the line the ICO draws for when an edtech provider becomes a controller in scope of the code.
(Note: the Gemini API Additional Terms confirm that "for the European Economic Area, Switzerland, and the United Kingdom, you may only make API clients available to users using Paid Services", which is the basis on which we operate.)
Plain English summary: Because our users are under 18, we apply extra protections and never advertise to you or profile you for marketing.
7. AI-marked submissions (Gemini)
When you submit code or answers for marking, the submission is sent to a Google Cloud Function hosted in Belgium (europe-west1), which calls Google's Gemini API (model gemini-2.5-flash-lite, described by Google as "our most cost-efficient multimodal model, offering the fastest performance for high-frequency, lightweight tasks") on the paid tier to produce a score and feedback. The result is written to our database (Cloud Firestore).
What is sent: your submitted source code or MCQ answer text, plus the lesson and question identifiers needed to mark it.
What is not sent: your name and email are not part of the marking prompt; your Python runs in your own browser via Skulpt and is not sent anywhere just to run.
Training: the Gemini API Additional Terms of Service state: "When you use Paid Services, including, for example, the paid quota of the Gemini API, Google doesn't use your prompts (including associated system instructions, cached content, and files such as images, videos, or documents) or responses to improve our products, and will process your prompts and responses in accordance with the Data Processing Addendum for Products Where Google is a Data Processor."
Retention / ZDR: by default Google's "Abuse monitoring" documentation states Google "retains the following data for fifty-five (55) days for the purposes of detecting and preventing violations of the Prohibited Use Policy", namely prompts, contextual information and output. Google's Zero Data Retention (ZDR) documentation states that "when your request for ZDR for a particular project is approved, all user content (prompts and responses) and identifiable metadata (such as IP addresses and Google Account IDs) are cleared prior to logging. The resulting record is marked as sanitized and contains zero identifiable user data." ZDR on the Gemini Developer API is not on by default and must be requested and approved per project. Where available we use ZDR to further restrict logging, and we keep this position up to date as Google's terms evolve.
Human oversight: Gemini's score is validated server-side and, where a teacher reviews work, the teacher's judgement takes precedence.
Plain English summary: Your code goes to Google's Gemini AI to be marked, Google does not train on it, and a teacher can always override the AI.
8. Automated decision-making (Article 22)
Article 22 of the UK GDPR gives extra protection where a decision is made solely by automated means and has a legal or similarly significant effect. (Note: the Data (Use and Access) Act 2025 reshaped this area into Articles 22A to 22D from 5 February 2026, and the ICO's guidance is being updated.) We treat Gemini grading as decision support, not solely automated decision-making: scores feed back into learning and a teacher has oversight and can override them. We do not use it to make significant decisions about a student with no meaningful human involvement. Because our users are children, the ICO is clear that even a small decision may be significant, so we apply this cautiously, keep an audit trail, and keep it under review.
Plain English summary: The AI helps mark your work but does not make final decisions about you on its own.
9. Cookies, analytics and local storage
Marketing website: uses a cookie banner (allow/deny); Google Analytics (with IP anonymisation) runs only if you accept; Google reCAPTCHA protects the contact form.
Educational app: uses only essential storage: a Firebase Auth token cached in IndexedDB to keep you signed in, and a single localStorage key (shuttle.activeClassId). The app does not use Google Analytics, advertising or tracking.
Plain English summary: The website uses analytics if you agree; the app uses only what is needed to sign you in.
10. Sub-processors
Name | What they do | Where they process | Transfer mechanism |
|---|---|---|---|
Google (Firebase Authentication) | Sign-in and account identifiers | EU/global | Google Cloud Data Processing Addendum incorporating SCCs and the UK Addendum |
Google (Cloud Firestore, eur3) | Stores app data | Belgium and Netherlands (eur3 read-write; witness in Finland) | As above |
Google (Cloud Functions, europe-west1) | Runs the marking function | Belgium | As above |
Google (Firebase Hosting) | Serves the app | Global edge | As above |
Google (Firebase App Check / reCAPTCHA v3) | Anti-abuse attestation | Global | As above |
Google (Gemini API, paid tier) | AI marking | Routing may transit outside the UK/EU, including the US | As above |
Google (Cloud Logging / Cloud Monitoring) | Diagnostics | EU/global | As above |
Framer B.V. | Marketing site hosting only | EU | Standard contractual protections |
The educational app does not use Google Analytics, Meta pixels, advertising SDKs, third-party CRMs, payment processors, or any analytics provider.
Plain English summary: Google runs the app's infrastructure and AI marking; Framer only hosts our marketing site.
11. International transfers
We aim to keep app data in the EU: Firestore is pinned to the eur3 multi-region (read-write replicas in Belgium and Netherlands, witness in Finland) and Cloud Functions to europe-west1 (Belgium). Region pinning guarantees where data is stored at rest, but it does not guarantee that every Gemini API call is processed only in the UK or EU: Google's own documentation notes that standard and global endpoints "don't guarantee data residency or in-region ML processing", so a call may transit other countries including the US. Where personal data leaves the UK we rely on Google's Cloud Data Processing Addendum, which incorporates Standard Contractual Clauses together with the UK Addendum (or, alternatively, the standalone UK International Data Transfer Agreement (IDTA)) as the ICO-approved transfer mechanism, supported by a transfer risk assessment.
Plain English summary: We keep data in Europe where we can and use approved legal safeguards when data leaves the UK.
12. How long we keep information
Category | Retention |
|---|---|
Contact enquiries | Up to 12 months after last contact |
Mailing list | Until you unsubscribe |
App attempts and lesson summaries | 12 months after end of relevant school year unless the school instructs otherwise |
App account and class membership | While active, plus 6-month grace |
Backups | Documented short window |
Server logs | 30 days |
Analytics | Limited period set in Analytics |
Plain English summary: We keep things only as long as we need them, then delete or anonymise.
13. Keeping information safe
We use Firebase App Check (reCAPTCHA v3 attestation); Firestore Security Rules that deny client writes to the attempts and grading collections (all writes are server-side via the Admin SDK); encryption in transit and at rest; our GEMINI_API_KEY held in Google Secret Manager and never shipped in the client bundle; multi-factor authentication on admin accounts; per-user rate limits (30 submissions per minute, 200 per day); and regular review. This aligns with the NCSC Cloud Security Principles and the Cyber Essentials baseline, which KCSIE 2025 and the DfE Generative AI product safety expectations encourage schools to check when buying AI-powered tools.
Plain English summary: We use strong, industry-standard security and least-privilege access.
14. Your rights
You have rights to access (Art 15), correct (Art 16), erase (Art 17), restrict (Art 18), data portability (Art 20), object (Art 21), and rights regarding solely automated decisions (Art 22). To exercise them email support@shuttlelearning.com. We respond within one month, extendable by up to two further months for complex or numerous requests under Article 12, and we may pause the clock if we reasonably need information to verify your identity or locate your record. Where your school is the controller, please send requests to your school first; we will cooperate and act on the school's instructions.
Plain English summary: You can see, fix, or delete your data; ask your school first where they run your account.
15. Data breach response
We keep a breach log, investigate promptly, and contain incidents. Where we act as processor, we notify the school (the controller) without undue delay so it can meet its 72-hour deadline to the ICO. Where we are controller, we notify the ICO without undue delay and, where feasible, within 72 hours where the breach is likely to risk people's rights and freedoms, and we tell affected individuals without undue delay where the risk is high.
Plain English summary: If something goes wrong we act fast and tell the school or the regulator as required.
16. Complaints and the ICO
You can complain to us first at support@shuttlelearning.com. You also have the right to complain to the Information Commissioner's Office at ico.org.uk.
Plain English summary: If you are unhappy, contact us, and you can also go to the ICO.
17. Changes to this policy
We version this policy and date each update. Where schools are controllers we notify them of material changes.
Plain English summary: We will tell you and your school when we change this page.
18. Effective date and last updated
Effective date: 23 June 2026
19. Related documents
Data Processing Agreement (DPA) for schools: published at https://www.shuttlelearning.com/legal-pages/dpa-for-schools and accepted via the onboarding click-through when a school first signs up.
Privacy summary for students (plain English): published alongside this policy.