Security & Data Protection

Candidate data stays on-device by default

New schools use on-device candidate data automatically. Candidates, access arrangements, assignments, results, and related people data stay in the browser on the school’s own computers. This does not make the whole product local-only: saved displays, rooms, layouts, cycles, sessions, scheduled exams, member accounts, and school settings still sync securely so authorised colleagues can work together. Our database is built to refuse candidate-linked data from on-device schools, and we test that refusal automatically.

Schools that need candidate-linked data available across devices can contact us about hosted candidate data. We enable that only after an informed conversation about what will be hosted, the safeguards, and the school’s responsibilities; it is not a self-service setting.

Both options are fully supported. Apart from where student records are stored, the guarantees are the same: the same multi-factor requirement, the same database-enforced separation between schools, and the same Data Processing Agreement. Hosted candidate data is a considered choice for schools that need those records across several staff or devices, not a weaker one.

With on-device candidate data, your school is responsible for the devices holding that data. Use the built-in backup and export tools regularly: if someone clears a device’s browser storage, the data stored on that device is gone for good.

Where and how data is stored

• Application data is hosted in the European Union and encrypted both in transit (TLS, the same technology behind the padlock icon in your browser) and at rest (encrypted while stored on disk).

• Payments are handled by Paddle, our payment provider and merchant of record; your card details never touch our systems.

• We keep the list of companies involved in running the service deliberately short; see the Sub-processors page.

Access control

• Every school’s data is kept completely separate by rules built into the database itself, not just checks in our application code. Even a mistake in our app could not show one school another school’s data: the database blocks it directly, and we test this automatically.

• Access to candidate personal data always requires multi-factor authentication (a password plus a one-time code from an authenticator app): a password alone is never enough, even for administrators.

• What each person can do inside a school workspace is checked by our servers, not just shown or hidden on screen. Even if someone found a way around the interface, the server still blocks anything they are not allowed to do.

• Teacher requests need no teacher accounts. Each school shares a high-entropy request link whose secret is kept in the link fragment and stored by us only as a one-way hash. The public form exposes class labels and scheduling slots only—never students, enrolments, workload results, or traffic lights—and every submission must pass Cloudflare Turnstile.

Application and platform security

• The application is protected by browser-level defences (a strict Content Security Policy plus hardened security headers such as HSTS, frame denial, and referrer policy) that block common web attacks, such as malicious scripts being injected into the page.

• No advertising, no third-party analytics, and no marketing trackers anywhere in the product.

• We do not record or replay how you use the site, and we do not send error details to third parties: if something goes wrong, the details stay in your own browser.

• Every database change is reviewed by another person and tracked in version control before it goes live, and is checked by an automated test suite covering both who should and should not get access, including wrong-school users, people who have not completed multi-factor authentication, and deactivated accounts.

• Server passwords, API keys, and verification secrets are kept in managed server-side secret stores, never inside the application that runs in your browser.

Special category data

Access arrangement data (extra time, rest breaks, and similar) can reveal disability or health information. We treat it with the same strict separation and multi-factor requirements as all candidate data, collect only what is needed to run the school’s examinations, and never use it for any purpose other than the school’s instructions.

Availability and resilience

• The application keeps working offline: displays keep running through short network interruptions during an exam.

• Hosted candidate data benefits from our platform’s automated backups; on-device candidate data has built-in export and backup tooling instead.

• We schedule maintenance away from common examination periods where practicable.

Deletion and data rights

Schools can export their data at any time and staff can exercise data rights from the in-app Account → Data rights page. When a subscription ends, remaining school data is deleted within 30 days as set out in section 9 of the Data Processing Agreement.

Reporting a vulnerability

If you believe you have found a security issue in ExamDisplay, please email contact@lompla.com with the details. We will acknowledge your report promptly, keep you informed, and will not take action against good-faith research conducted without accessing other schools’ data or disrupting the service.

Questions

Data protection officers and IT leads are welcome to send us security questionnaires or request our DPA countersigned: contact contact@lompla.com. See also our Privacy Policy, DPA, and Sub-processors list.