Security
Where your candidates' data lives, and what guards it.
Last updated 13 September 2026.
The short version
- Data is stored in London, servers run in Amsterdam. Nothing leaves the United Kingdom or the European Union.
- The product has no third-party runtime code. Zero installed packages run on the server, which removes the most common way a service like this gets compromised.
- The browser is told it cannot use the camera, the microphone, or your location. Not a policy, a header the browser enforces.
- There is no SOC 2 report, no penetration test, and no bias audit. Details below, stated rather than glossed.
Where the data is
| Application | Railway, Amsterdam, Netherlands. Runs as a container built from a pinned image. |
|---|---|
| Database | Supabase, London, United Kingdom. PostgreSQL, encrypted at rest. |
| Backups | Managed by Supabase, in the same region. Not copied elsewhere. |
Nothing is stored in India, where the business is registered, and nothing is replicated to another region. If your review needs a one-line answer to "where does our candidate data live", it is the United Kingdom, on infrastructure operated from the Netherlands.
Two jurisdictions rather than one, and worth a sentence rather than a wave at "the EU". UK data protection law mirrors the GDPR and the United Kingdom holds an EU adequacy decision, so a transfer between the two needs no additional safeguards from you. Nothing crosses either border.
How it travels, and what the browser is told
Everything is over HTTPS. In production the service sends a strict transport header with a one-year lifetime covering subdomains, so a browser that has been here once refuses to try plain HTTP again.
The pages are served under a content security policy that allows scripts only from
this origin. Inline script is blocked, eval is blocked, and no content
delivery network is used, so there is no third-party script that could be swapped
underneath a candidate mid-assessment. The console cannot be framed by another site,
which is what makes a clickjacked destructive action impossible.
Three permissions are switched off at the browser level rather than merely unused:
| Camera | Denied by header. |
|---|---|
| Microphone | Denied by header. |
| Location | Denied by header. |
This matters more here than on an ordinary product. Assessment tools are the category where candidates reasonably expect to be watched, and the honest way to say we do not is to make it something the browser enforces rather than something we promise.
Supply chain
The server runs on the Node.js standard library and nothing else. There are no installed production dependencies at all, which is unusual enough to be worth stating plainly: the dependency list is empty, not short.
The reason to care is that most compromises of a service this size arrive through a package somebody else maintains, published under a maintainer's stolen credentials and installed automatically on the next deploy. That path does not exist here.
Two development-only tools are installed for testing and never ship in the running image. In the browser, the SQL and Python engines a candidate uses are WebAssembly builds served from this origin, pinned, and never fetched from a content delivery network.
Candidates run code, and that is contained
A candidate writes SQL and Python as part of the assessment. Both run inside the candidate's own browser, in a WebAssembly sandbox, in a worker thread. That code has no filesystem and no network. The only data it can reach is the copy of the practice warehouse already sent to that candidate.
Nothing a candidate writes is executed on our servers, and no candidate's code can reach another candidate's data, because it never leaves the tab it was typed in.
Who can reach production
One person, the founder. Access to Railway and Supabase is protected by multi-factor authentication.
A one-person business cannot offer separation of duties, and we will not claim it. What that means for you concretely is that there is no second person whose approval is required for a production change, and no second person to notice a mistaken one. The compensating controls are that the database is managed rather than self-hosted, every change ships from version control, and the whole test suite runs before a deploy.
Customer accounts are separated by workspace. Every query for candidate data is scoped to the workspace of the signed-in user, and there is no interface anywhere in the product that shows one customer another's candidates.
Credentials
Passwords are stored as scrypt hashes with the cost parameters recorded alongside each one, so the cost can be raised later without locking anybody out. The password itself is never stored and cannot be recovered from the hash, which is why a forgotten password is reset rather than looked up. Repeated failed sign-ins are throttled.
The session cookie is HTTP-only, same-site, marked secure in production, and expires on its own. It carries a random identifier and nothing else.
Durability, and recovering an interrupted sitting
Every decision a candidate makes is appended to a log as it happens rather than saved at the end. A run is rebuilt by replaying that log, so a restart, a deploy, or a lost connection in the middle of an assessment does not cost the candidate their work.
This was built for a constraint that no longer applies and kept because it is the right answer anyway. A candidate midway through a timed exercise is the worst possible moment to lose state.
Sub-processors
| Railway | Application hosting. Amsterdam. |
|---|---|
| Supabase | Database and backups. London. |
| Resend | Delivers the one-time code a candidate uses to prove their address, when they choose that over a provider sign-in. Receives an address and six digits. No other mail is sent by this product at all. |
| Anthropic | Optional. Receives one section of a report only when a user presses the summarise button, and only on accounts where it is configured. |
There are no others. No analytics provider, no error tracker, no advertising network, no customer messaging tool with access to candidate data. See the privacy policy for what each receives.
Results leaving for your own systems
If you configure a webhook, we post each finished result to a URL you control. Two things about that are worth a reviewer's attention.
Every delivery carries an x-trialday-signature header: an HMAC-SHA256 over
the timestamp and the exact body, using a secret only you and we hold. Verify it and
reject anything whose timestamp is stale. Without that check, anybody who learns your
endpoint can post a hiring verdict to it and your systems will record it.
We refuse to post to a URL that resolves into private or link-local address space, and we do not follow redirects. That is not about your endpoint — it stops somebody using the field to make our server fetch things inside our own network.
Deliveries and their failures are recorded and shown in your console, so an endpoint that has quietly stopped accepting them is visible to you rather than only to us.
Deletion
Deleting a result deletes the decision log behind it in the same operation. Everything a candidate did is in that log, so removing only the summary would leave the substance in place. Invitations can be revoked, and an unopened one expires on its own.
If there is an incident
Affected customers are told within seventy-two hours of us finding out, with a specific description of what happened, what data was involved, and what is being done. We would rather send an awkward accurate notice than a comfortable vague one.
What we do not have
Listed because you will find out, and finding out later is worse.
| SOC 2 | No report, and no audit under way. It is a five-figure exercise and this business is too young for it to be honest work rather than theatre. If your procurement requires one, we are not yet a fit and will say so on the call. |
|---|---|
| Penetration test | No third-party test has been performed. |
| Bias audit | None. Producing one requires candidate volume with demographic data that does not exist yet. Employers subject to New York City Local Law 144 or comparable rules should not use this product until it does. |
| Uptime commitment | No contractual guarantee. See Terms. |
| SAML single sign-on | Not built. Sign-in is by password, with Google and Microsoft available to candidates proving their identity. |
| Data residency options | One region only, the European Union. There is no United States or Asia-Pacific option. |
Two of these are deliberate rather than merely unfinished. A bias audit computed from a handful of candidates would be a number with no meaning attached to a serious legal claim. A SOC 2 report bought before there are controls worth auditing certifies the paperwork rather than the product.
Reporting a vulnerability
Write to [email protected] with enough detail to reproduce it. We will confirm receipt within two working days and tell you what we found.
Testing against your own account and your own candidates is welcome. Please do not test against another customer's data, run denial-of-service traffic, or use a real candidate's sitting as a test case. We will not pursue anybody who reports something in good faith within those limits.