Data protection and pupil privacy

Schools need clear information about how third-party education services process pupil data. This page brings together Monteeno’s school data-protection information and supporting documents.

Where we have got to

Monteeno is an early-stage product opening to its first schools. Some of the documentation a school needs for procurement is complete and some is not. This page marks each item either way rather than presenting an even picture.

We would rather lose an application than have a school build a DPIA on something we had not actually verified.

Data we process

Pupil accounts created by a school

The pupil’s name, as typed in by the school
A username generated from that name, which is what the pupil signs in with
A class or year-group label, if the school chooses to enter one
A password, stored only as a bcrypt hash and never in readable form
The learning record: lessons and modules completed, every quiz attempt with its score and result, game attempts, points and activity streaks
Sign-in records: active sessions and sign-in attempts

What we do not hold about pupils. No email address, date of birth, postal address, telephone number, photograph, free-text writing or payment detail. Pupils are never asked for any of these. Each pupil account carries an internal address on a reserved domain that cannot route anywhere, so a pupil cannot be emailed by Monteeno or by anyone else through Monteeno.

School staff accounts

Name, work email address, role at the school, and a hashed password

School application data

School name, contact name and role, work email address, approximate pupil numbers, year groups of interest, and anything written in the optional message box
The page the application came from and any campaign parameters in the link, so we know which outreach worked

Website visitors

A first-party record of a small set of named events, such as an application being started. It stores the event name, the page path and a random identifier that lives in the browser tab and is discarded when the tab closes.
There is no third-party analytics service, no advertising pixel and no cross-site tracking on the parts of the site pupils use.

Why it is processed

To create and authenticate pupil and staff accounts
To deliver lessons and record which parts a pupil has completed
To mark quizzes, apply the pass mark and issue certificates
To show teachers the progress of pupils at their own school
To answer a school’s application and provide support
To understand, in aggregate, which parts of the programme schools actually use

School and Monteeno roles

For pupil accounts a school creates, the school is the controller and Monteeno is the processor. The school decides which pupils are added and for what educational purpose; Monteeno processes that data only to deliver the service on the school’s instructions. This is the standard arrangement for a school using a third-party learning platform.

Monteeno is a separate controller for its own business records: applications to the Founding Schools Programme, the contact details of school staff, correspondence, and parent customers who buy Monteeno directly. That processing is described in the Privacy Policy.

These roles are set out formally in our data processing agreement, which is written against Article 28 UK GDPR. If your school would rather we signed its own DPA, send it over.

Where data is stored

Pupil data is held in the United Kingdom. Every account and learning record sits in Amazon Web Services’ eu-west-2 region in London. We moved the database there from the United States on 24 September 2026 and verified the new location directly against the running database.

For completeness about how we got here: until that date the database ran in AWS us-east-1 in Northern Virginia, and an earlier version of this website had wrongly said data was stored in the UK. We corrected that publicly rather than quietly, and then moved the data so the claim is true.

Not every provider we use is in the UK, and we are not going to imply otherwise. The platform our application runs on is a United States company, and the regions used by our email, payment and video providers are still not confirmed in writing. Those are listed individually in the table below, marked either way. A school assessing us should read that table rather than rely on the sentence above.

For context on what is actually at stake: a Monteeno pupil record is a name, a class label and a set of quiz scores. We hold no pupil email address, date of birth, postal address, telephone number, photograph or written work.

Retention and deletion

A job runs every night and deletes records once they pass the periods below. These are the same periods set out in clause 8 of the data processing agreement, and they are enforced in code rather than being a statement of intent.

Record	Deleted after
Pupil accounts and their full learning record	12 months after the school’s licence ends. A school that renews keeps its pupils; the clock only starts once there is no current licence.
Sign-in attempt records	90 days
Expired sign-in sessions	30 days past expiry
Website event records	400 days. These are not linked to any account.
Competition entries	6 months after the competition closes, unless the parent separately consented to our emails. Not part of the school service.

Alongside that schedule:

A teacher can remove a pupil from the roster at any time, which withdraws their access

We will delete a pupil’s account and learning record on request from the school, and confirm when it is done

We will delete a school’s entire data set on request if it stops using Monteeno

Deletion requests go to hello@monteeno.com.

Security

Measures that are in place today:

Passwords stored as bcrypt hashes, never in readable form

Sessions held in a signed, HttpOnly, Secure, SameSite=Strict cookie, so the token cannot be read by page scripts

HTTPS enforced across the site, with HTTP Strict Transport Security for one year including subdomains

A Content Security Policy and MIME-type sniffing protection on every response

Encrypted connections between the application and the database

Every school endpoint checks the caller’s role and scopes results to their own school, so one school’s staff cannot see or change another school’s pupils

Pupils hold no email address, which removes the usual email-based account takeover and password-reset attack routes entirely

Resetting a pupil’s password ends all of that pupil’s active sessions

Things we do not have, stated plainly:

Cyber Essentials certification

ISO 27001 certification

An independent penetration test

Multi-factor authentication for staff accounts

We do not display compliance badges, because we do not hold the certifications they would represent.

Subprocessors

The third parties that process data on Monteeno’s behalf. Locations marked “not yet confirmed” are ones we have not verified in writing with the provider, and we are not going to state them until we have.

Provider	What it does	Location
Neon	The application database: all account and learning records	AWS eu-west-2 (London, United Kingdom). Moved from us-east-1 on 24 September 2026 and verified against the running database. No pupil record leaves the UK at this layer
Amazon Web Services	Underlying infrastructure for the database, and content delivery	London (eu-west-2) for the database itself. AWS is a United States company and its content delivery runs through global edge locations, so it remains covered by the UK Extension to the EU-US Data Privacy Framework: Amazon Web Services, Inc. is a covered entity of the Amazon.com, Inc. certification, confirmed Active on the DPF register
Floot	The platform the application runs on, including sign-in infrastructure and file storage	United States company. Region not confirmed, and no transfer mechanism is stated in its published terms. We have asked for both in writingNot yet confirmed
Resend	Email to staff and parents. No email is ever sent to a pupil	United States company. Sending region not yet confirmed in writingNot yet confirmed
Stripe	Payment processing for parent purchases only. Not used for schools, and no pupil data is involved	Not yet confirmed in writingNot yet confirmed
Bunny.net	Video delivery for lesson videos. Receives the viewer's IP address in order to deliver the video	Not yet confirmed in writingNot yet confirmed
Google Fonts	Serves the typefaces the site is set in. A pupil's browser requests the font files directly, so Google receives the IP address and browser details of anyone loading a page. No account or learning data is sent, and no cookie is set by the request	Google LLC, United States. Google LLC is certified under the UK Extension to the EU-US Data Privacy Framework

Documents

Privacy Policy — published
School Licence Terms — published
Subprocessor list — the table above
Security summary — the section above
School Data Processing Agreement — published. Happy to sign your school’s own DPA instead if that is simpler.
Transfer Risk Assessment — completed, available to your data protection officer on request. It is not published because it contains our frank internal analysis of the risk, which is more use to a DPO than to a search engine.
Retention schedule — the table above, matching clause 8 of the DPA and enforced nightly in code.
Deletion requests and data-protection questions: hello@monteeno.com

Questions before you apply?

Data-protection questions go straight to the founder. Ask before applying if it would help — we would rather answer them up front than halfway through a rollout.

Apply for a free school licence