Security & Data Protection

The short version

ClassLens has no server database, no login, no accounts, and no third-party service that touches your data. Everything you enter — classes, pupils, seating plans, RAG ratings, scores — is written straight from your browser to a folder you choose on your own device. It is never transmitted to ClassLens or anyone else, at any point, not even briefly. There is nothing on our side to breach, and no account that could be compromised, because there is no account.

This page is written so your school’s IT team or Data Protection Officer can assess ClassLens before staff use it. It describes what is actually built. If you’re unsure whether it fits your school’s policies, check with your DPO before entering real pupil data. See also the Privacy Policy.

Is there a data processor relationship at all?

For pupil data, no. ClassLens never receives, stores, transmits, or has any technical means of accessing it — the app’s code runs entirely in the teacher’s browser and writes only to the folder they picked. There is no processing for a school to approve, and no sub-processor to review, for that data.

The relevant relationship, if any, is between the school and wherever the teacher’s folder actually lives. If it’s a plain local folder, there may be none. If it’s a folder synced to a service the school already has an agreement with (a school OneDrive or Google Drive), that existing agreement governs it — not a new one with ClassLens.

Data minimisation

Only a pupil’s first name and the first letter of their surname are ever stored — never a full surname, date of birth, photograph, or any SEN/medical category. This is enforced by the app in your browser before anything is written to your file, no matter what is typed or uploaded. The optional “Seating support” note is for practical arrangement details only (“front”, “extra time”) — typing a SEND label or a judgmental phrase into it is automatically stripped before saving.

Where the data lives, and retention

Wherever you point ClassLens — typically a folder in your school OneDrive. ClassLens only ever writes to that folder; it has no visibility into whatever the folder syncs to. The data is kept for exactly as long as you keep the file, and no longer. There is no separate copy anywhere to retain or forget to delete — retention is entirely in your hands, the same as a paper markbook. See the note on /help about clearing old classes at the end of a year (advice, not a requirement).

Hosting

The ClassLens application (HTML, JavaScript, CSS — no user data) is served as static files by Vercel. Vercel Inc. is US-incorporated; if your school has a policy about US-incorporated providers, note that this applies only to the delivery of the app’s code, which is the same for every visitor and contains nothing about anyone. No user data is hosted by Vercel or anyone else.

How the code is protected from tampering

ClassLens serves a strict Content-Security-Policy. On every page that loads your class data, the browser is instructed to allow no outbound network connections at all except back to ClassLens’s own domain, and to run only the app’s own scripts (no inline or injected code). In practical terms: even if a serious code-injection flaw were ever found, it would have no way to send your pupil data anywhere — there is no channel for it to leave the device. Every dependency that ships in the browser bundle is pinned to an exact version, so a compromised update cannot arrive silently. All traffic is HTTPS-only (HSTS), the app cannot be embedded in a frame, and camera/microphone/location and similar browser capabilities are denied.

Encryption at rest

ClassLens does not itself encrypt your data file. Its protection at rest comes from your device’s own disk encryption (BitLocker on a managed Windows device, FileVault on a Mac) and, if the folder syncs to OneDrive, that service’s encryption and account security including two-factor authentication. If your managed devices’ disk encryption is not confirmed enabled, that is the practical gap to close.

We considered adding a passphrase to encrypt the file within ClassLens and decided against it: “forget the passphrase” would mean permanent, unrecoverable data loss, and it would stop you (or your DPO) from being able to open the file and see exactly what is stored. Given disk + cloud encryption already cover the realistic threat, the transparency was judged more valuable.

Browser and device requirements

ClassLens relies on the File System Access API, currently supported only by Chrome, Edge and other Chromium browsers — not Safari, Firefox, or iOS/iPadOS. It detects this and shows a clear explanation rather than failing silently. On a school-managed device the feature can also be gated by IT policy (Group Policy / Intune) — worth confirming before a wider rollout. A written Security & Data Protection Briefing, naming the specific Chrome/Edge enterprise policies, is available for your IT team on request.

Shared classroom computers

On a computer several teachers use, ClassLens asks “who’s using ClassLens?” and remembers each teacher’s folder separately. This is not a login — it’s a convenience so the right folder opens. The real boundary is the browser’s own permission to that folder and the fact that each teacher’s folder is in their own OneDrive. For genuine separation on a shared machine, use separate browser profiles per teacher, or have each teacher sign OneDrive into their own account.

Backups

ClassLens keeps a small rolling set of timestamped snapshot copies in a backups subfolder next to your data file, to guard against an accidental overwrite. This is not a full backup service — if the device or folder is lost, the snapshots go with it. Keeping your folder somewhere with its own version history (a synced OneDrive folder) is the practical protection. ClassLens cannot back your data up on a server, because it never receives a copy.

If something goes wrong

There is no database to breach and no pupil data on any server, so most of a classic incident-response process does not apply — there is no ICO 72-hour notification pathway that runs through ClassLens’s systems, because ClassLens has no systems holding pupil data. A code bug that could mishandle data on your device is fixed and shipped through the full test/quality gate, and colleagues are told directly if a data-loss risk existed. A compromised dependency is bounded by the pinned lockfile and the no-outbound-connections policy above.

Reporting a vulnerability

If you believe you’ve found a security issue, contact the maintainer privately show address rather than opening a public issue. There is no bug-bounty programme — this is a small tool maintained by one person — but reports are taken seriously and acknowledged. /.well-known/security.txt points here.