Trust
Security
What is actually true about how this runs, including the parts that are not impressive.
How this site works today
Every line here describes the system currently serving this page.
- Static pages. The public site is pre-built HTML with no database and no login behind it, which removes most of the ways a marketing site gets breached.
- HTTPS everywhere. TLS at the Cloudflare edge and again to the origin, on a Let's Encrypt certificate. Plain HTTP is redirected.
- Origin in Germany (EU). A single server at Hetzner Online GmbH, with Cloudflare in front for DNS, caching and bot filtering.
- Signup addresses stay out of URLs and logs. The signup form posts in a request body, never a query string, and that endpoint has web-server logging switched off, so an address cannot end up in a plaintext access log or in a referrer header.
- The signup file lives outside the web root, readable only by the account that writes it, so it is not fetchable by anyone who guesses the filename.
- Rate limiting and a honeypot field on the signup endpoint, and a cross-origin check that rejects form posts from other sites.
- Standard web-server access logs record IP address, path and user agent for operational and abuse-handling purposes, and are rotated.
- Analytics. Google Analytics 4 on the public site, plus a first-party click counter that stores no personal data. Both are described on the cookies page.
How candidate data is handled
These are commitments about the product rather than an audit report, and they are written as commitments on purpose.
- Stored in the EU. Candidate answers, scores and reports sit on the same Germany (EU)infrastructure. They are not copied to a US region for convenience.
- Encrypted in transit between candidate, employer and server.
- Scoped access. An employer sees their own candidates and nobody else's. There is no cross-customer view and no shared pool of candidate data.
- Retention of 12 months by default, after which results are deleted. An employer can delete a candidate's data at any time, and a candidate can ask for deletion directly.
- No secondary use. Candidate data is not sold, not shared between employers, not used for advertising and not used to train AI models.
- Export on the way out. Reports as PDF and shortlists as CSV, so ending the relationship does not destroy the hiring record you may need to keep.
- Sub-processors are published and listed on the sub-processors page, with notice before a new one is added.
What we do not have
Stated so that nobody has to discover it in an evaluation:
- No SOC 2 Type I or Type II report.
- No ISO 27001 certification.
- No third-party penetration test report, and no bug bounty programme.
- No independent bias audit of the assessments. See the compliance page for what that means for New York City roles.
- No 24/7 staffed security operations centre. This is a small team, and an incident is handled by people, in working hours, as fast as they can.
If your procurement requires any of these, we are not the right supplier today. Say so at signup and we will tell you honestly whether that is likely to change on a timescale that helps you.
Reporting a vulnerability
Email [email protected] with steps to reproduce. You will get a reply from a person within three business days. Please do not test against real candidate data, do not run denial-of-service tests, and give us a reasonable window to fix an issue before publishing it. There is no bounty programme, so we cannot offer money, but we will credit you if you want the credit.
If something goes wrong
Customers affected by a breach of personal data are notified without undue delay, with what is known at the time rather than after everything is understood, and the notice is updated as the picture changes. The formal version of that commitment, including the timescales, is in the data processing agreement.