Security and where your data is kept

Most people who use Police Law Prep work for a police force, so the list of accounts is sensitive on its own. This page says what is held, where each kind of data sits, who can reach it and how it is protected, so that you can judge it for yourself. The privacy notice covers purposes, lawful bases, retention periods and your rights.

What the service holds about you

For an account, the service holds your email address, the way you sign in, a purchase reference, your study progress, and the optional answers described in the privacy notice. You can use any email address, including a personal one, and if you sign in with Apple you can choose Hide My Email.

It never holds your card details, because Stripe or Apple take payment on their own pages. It never holds your password in a readable form, because Supabase stores a one-way hash and the server never sees the password itself. Our own tables hold no IP addresses or browser strings. Supabase's session table in the same database does (each session's IP address and browser, until sign-out or 30 days unused), so those are also inside the weekly encrypted backups.

Where each kind of data is stored

Nothing is sold, rented or shared with any company for its own marketing, and the privacy notice lists the transfer safeguards for each provider outside the UK.

Who can reach it

One person runs Police Law Prep, and that person is the only one with administrative access to the database, the hosting account and the mailbox. There are no staff and no contractors with access to user data.

Your browser never talks to the database directly. Every table refuses direct access (row-level security is on with no policies), and the app's pages read and write through the server. The database credentials exist only on the server and in the owner's own administration tools, never in the browser. Each request to the server checks who you are and then checks a live access record (the database for accounts, the code registry for access codes) before it returns anything, so ending someone's access takes effect at once rather than when a token expires.

The code is kept on GitHub, and the GitHub account that controls it uses two-factor sign-in, including hardware security keys. Production secrets are not in the code repository. The backup server accepts SSH connections only over a private network with a key, and its public SSH port is closed.

How it is protected in transit and in the browser

• Every page and API call uses HTTPS, and the site tells browsers to use HTTPS only, for two years at a time (HSTS).
• Every page is sent with a Content Security Policy that limits where scripts can load from and where the page can connect, a header that stops any other site framing it, and a policy that turns off camera, microphone and location access.
• The sign-in library is served from the site itself at a checked, pinned version rather than from a third-party content network.
• Forms accept requests only from the site's own origin. Access-code sign-in is limited to 20 attempts per IP address in ten minutes, and the contact form is limited by one-way hashes of the IP address and email address that live only in the server's memory for ten minutes.
• Account sessions are short-lived signed tokens, and the server treats a token as identity only and asks the database about access on every request. The older access-code route sets a one-year cookie holding a one-way hash of the code, and the server checks it against the code registry on every request.
• Passwords must be at least 8 characters, and you can use Google or Apple sign-in instead of a password.

Sign-in records and logs

The "security records" line in the privacy notice refers to two providers' logs, not to a table of our own:

• Vercel, the host, keeps request logs (time, path, IP address and browser) for one day on our plan.
• Supabase, the sign-in provider, keeps each session's IP address and browser in its session table until you sign out, or until a daily job removes a session that has not been used for 30 days, which also means a device unused for 30 days signs in again. It records each sign-in event (time, IP address and browser) in its own log store, kept for one hour on our plan. The database copy of those audit records is switched off.

The server's own log lines are fixed messages and status codes. They do not contain email addresses, IP addresses or request bodies.

Backups

Every Sunday the database, the study-progress files and the access-code records are bundled and encrypted with a public key (age), then copied to the rented server in Nuremberg and to the director's encrypted laptop. The newest eight weekly bundles are kept, so a backup lives for about eight weeks, and a restore drill on the first of each month checks that a bundle can still be decrypted and restored. Backups are used only to recover from a loss and to test that recovery.

Keeping data to a minimum

• The onboarding question about your police force area has "Other" and "Prefer not to say" as complete answers. Since 26 October 2026 the answer is added to a per-area count at the moment you answer and is not stored against your account, so the database holds no record of which force any account belongs to. Answers given before that date were converted to counts and removed from the account rows when the change went live, and the weekly backups taken before it still hold the old per-account answers until they rotate out, within about eight weeks.
• Onboarding and research answers are never sent to analytics, Google, Stripe or Resend, and never go into sign-in tokens or study files.
• Page-view and funnel counts are cookieless and aggregated, and nothing in them identifies you.
• Study progress and answers end when your access ends, on the schedule in the privacy notice.
• You can delete your account from inside the app. Deletion completes within seven days and removes the account from the account systems. The privacy notice lists the records that must stay for a time (for example accounting records), and the weekly backups rotate the rest out within about eight weeks.

Breaches and how to report a problem

A Large Company Ltd is registered with the ICO as a data controller (registration ZC232130). If a breach affected your data, you would hear from us by email, and the ICO would be told within 72 hours where the law requires it.

To report a vulnerability or a security concern, email alexander@alargecompany.com. A real person reads it and replies. If you prefer to send details encrypted, say so in a first email and we will arrange it.

No independent penetration test has been carried out yet. The checks above are the product's own automated tests and the providers' own certifications: Supabase and Vercel hold SOC 2 Type 2 reports, and Stripe is a PCI DSS Level 1 service provider.

Date and review

This page is updated with every change to how data is stored or protected. It was last updated on 26 October 2026, alongside the privacy notice of the same date.