Security
Last updated September 17, 2026
Written to be checked rather than believed. If your questionnaire asks something this page does not answer, send it and we will answer it in writing rather than pointing back here.
What we do not have
No SOC 2, no ISO 27001, and no third-party penetration test report. We are a small company and those are on a roadmap rather than on a shelf. We would rather you learn that here than three weeks into a review.
We also do not offer SAML single sign-on yet, and we cannot confine candidate data to a single jurisdiction today: it is processed in Canada, the United States and Germany.
Where candidate data lives
Interviews are conducted and scored on servers in Toronto. The database, the web application and the recording storage are in the United States. Candidate code executes in a sandbox in Germany, on a host reachable only from our own private network and never from the public internet.
Every third party that can touch any of it is named individually, with what each one receives.
Who can reach it
An employer sees only their own roles and their own candidates. That is enforced at every query, by re-deriving which company the caller belongs to from the database rather than trusting anything in the request.
Inside Larpy, access to production data is limited to the people who operate it, and every administrative view of a customer’s data writes an audit row. So does every override of a recommendation, every export of a cohort, and every read of the bias-audit figures.
Connection tokens for external tools are stored as hashes, shown once, scoped to read by default, and revocable immediately. A token can record a decision a person has made; it cannot make one.
Recordings
Held in private storage that is not publicly readable and reached only through links minted for one viewer that expire in minutes. They are deleted after 90 days by a nightly job; transcripts and evaluations after 12 months. Both are ceilings rather than minimums.
A deletion removes the file, not the pointer to it. If the file cannot be removed we report a failure rather than confirm a deletion that did not happen.
Candidate code
Runs in an isolated sandbox with no network access and a hard time limit, on a machine that holds nothing else. It is the same engine that scores the round, so what a candidate sees when they press Run is what the verdict is computed from.
What the model gets
The transcript, the role and its criteria, and on a coding screen the code. Not the recording. Candidate interviews are not used to train models, are not shared between customers, and are not read by us except to operate the service or when you ask us to look at something.
Demographic self-identification, where a candidate volunteers it for bias-audit purposes, is stored in a separate table that the interviewer and the scorer cannot reach, and is only ever reported as an aggregate with small categories suppressed.
When something goes wrong
We will tell you without undue delay after becoming aware of a breach affecting your candidates: what we know, what we are doing, and what we do not yet know. We will not wait for a complete picture before the first message.
Found something? security@getlarpy.com. We will not take legal action against anyone who reports a vulnerability in good faith, gives us reasonable time to fix it, and does not access or alter other people’s data while finding it.
Reliability
The interview engine runs on multiple machines so one failing host does not take live interviews with it. Verdicts are stored durably and recomputed automatically if scoring is interrupted. Health is monitored continuously and alerts reach a person.
An interview that cannot be scored is reported as unscored rather than given a number. A candidate is never rejected because our pipeline had a bad day.