Security and data protection

Where the data is

Without an exam session

Documents, and the candidate details typed into them, are kept in the browser's own storage on that device and nowhere else. We cannot see them.

In an exam session

Each candidate's work is saved on their device first, then backed up to a database run by Supabase in Amazon Web Services' London region, in the UK. The browser talks to the database directly, over an encrypted connection. The database provider encrypts the data it stores.

Hosting

Cloudflare serves the app's files. It holds no candidate data.

Nothing from anywhere else

Apart from the database, the app loads nothing from any other address: no font services, no content networks, no analytics and no advertising trackers.

What is stored

For an exam session, only what the printed script's header and the running of the exam need:

• About each candidate: name and candidate number, the session, whether the spelling check is allowed, a scrambled form (hash) of their desk-slip PIN if the school uses slips, the anonymous identity of the device they are using, and when they started and finished. No date of birth, and nothing about why the candidate has access arrangements.
• The candidate's work: the newest version, and during the session a history in 30-second steps, so that staff can see the work as it stood at any moment if there is a dispute.
• The school and its staff: the school's name and centre number; each member of staff's email address, name if given, and role.
• The exam: its title, board, specification, component, date, time and room.
• The audit log (below).

No PDFs are stored: scripts are made on demand, in the member of staff's browser, from the backup.

Who can see what

Every table in the database has rules that decide, for each signed-in person, which rows they may read or change. A member of staff only ever reaches their own school's data, and within it their role decides:

Exams officers

Everything in their school.

Invigilators

Only today's sessions and any still open: they run them, and cannot see any other day's session or its scripts.

IT

The list of sessions with how many candidates each has. Never a candidate's name, work, device or PIN attempts.

Staff can read and change only the fields their screens use; a PIN's hash never leaves the server. A browser that has not signed in has no rights on any table. Candidates' devices never read tables at all: they call a small set of functions that each check which candidate the device is tied to.

Staff sign-in

• Staff sign in with a one-time link emailed to their address. Nobody can join a school uninvited, and only an exams officer can invite or remove staff.
• Exams officers must use two-factor sign-in, with a code from an authenticator app on their phone. The database gives an exams officer no rights until the code has been entered. Invigilators and IT staff may use it too.
• Setting up two-factor sign-in gives eight one-use recovery codes, for a lost phone. They are stored only in scrambled form, and repeated wrong codes stop further tries for a while.
• A sign-in left unused for a day is signed out.

Candidates and their devices

• Candidates have no personal logins or passwords. A candidate's device has an anonymous identity, which a member of staff ties to one candidate: by unlocking the pairing code shown on the device, or through the candidate's number and the PIN on their desk slip.
• One candidate per device and one device per candidate, enforced by the database. A backup from a device that no longer holds its candidate is refused. Moving a candidate to another device is a staff action.
• PINs are 6 random digits, shown to the exams officer once and stored only as hashes. Five wrong PINs in ten minutes lock the device for ten minutes; ten wrong for one candidate number, from any devices, lock that number for ten minutes. Every attempt is recorded.
• Closing a session ends every device's access to it.

How long work is kept

• Once a session is closed, its candidates' work and names are deleted automatically, overnight, when the school's retention period has passed: 180 days by default, and at least 180. The exams officer can choose a longer period, up to 730 days.
• The exams officer can keep one session's work longer, for example for an enquiry about results, or delete a closed session's work early. Every session shows the date its work will be deleted.
• When a session closes, the history kept during it is thinned to one version an hour.
• A session nobody closes is closed automatically seven days after its exam, so that the clock starts.
• The session's details and the audit log are kept.
• Deleted data remains in the database provider's own backups for up to 7 days more.
• Candidates' devices keep their own copy until staff clear them.

The audit log

The log records who did what and when: every device unlocked, released or finished; every PIN attempt, right or wrong, and a right PIN tried on a second device; PINs made and lockouts cleared; sessions opened and closed; staff joining; two-factor resets and recovery codes; retention changes; and work deleted. Exams officers can read it on screen and download it as a spreadsheet file, for example for a malpractice investigation.

Running the service

• The exam never depends on the server. Every save goes to the device first; the backup follows and is never waited for.
• Monitoring. An automatic check fetches the app and the server every 30 minutes and alerts us when something is down. There is no public status page yet.
• Changes to the database's structure are made only through versioned scripts kept with the code, and every change to the app is published only after its automated tests pass.
• Reviews. We reviewed the code, the database's rules and its settings on 10 October 2026, checking each rule as each role against the live database. An independent security review and Cyber Essentials certification are planned before the first paying school; neither has been done yet.

Documents for your school

In an exam session the school is the data controller and ExamDoc its processor. These are available to schools on request:

• the privacy notice for the service;
• a data-processing agreement, with the security measures and the companies we use (Supabase, Amazon Web Services and Cloudflare);
• a data protection impact assessment, to help with your own.

Ask us: [contact email to be added]

This website has its own, shorter privacy page.