Security
What we do today, and what we don't yet.
Interview recordings are among the most sensitive things a company holds about a person. This page describes the system as it is currently built, including the parts that are not finished.
Last reviewed July 2026
01
Tenant isolation
This is the control we would point at first. Every tenant’s data is separated by PostgreSQL row-level security, and the application connects as a role that cannot bypass it. Isolation is enforced by the database, not by application code remembering to add a filter.
The practical consequence: a bug in our application logic cannot leak one customer’s candidates to another, because those rows are not visible to the connection at all. Cross-tenant reads return not-found rather than data.
02
Encryption
Traffic between candidates, customers and the application is served over HTTPS. Data at rest — the database, uploaded résumés, recordings and generated reports — is encrypted by the managed storage underneath.
One exception worth naming: the sandbox that executes candidate code runs on a dedicated host reached over a secret-gated network path rather than TLS. It handles submitted code and test output, not identity or account data. Moving it behind TLS is on the list.
03
Where your data is held
In a single region: Singapore (ap-southeast-1), on AWS and Supabase. Model inference for résumé parsing and interview scoring runs on Amazon Bedrock.
We do not currently offer a choice of region. If EU or US residency is a requirement for you, tell us before you buy rather than after — today the honest answer is that we cannot meet it.
04
Model use
We do not train models on candidate data. Inference runs on Amazon Bedrock, which does not use content submitted to it to train the underlying models.
Scores are reproducible in the sense that matters for review: each one is stored with the evidence and the rubric that produced it, so a decision can be reconstructed — and challenged — later.
05
Authentication and access
Roles are enforced server-side per endpoint, not only in the interface. External interviewers and client users can reach only the screens their role entitles them to.
Access tokens are short-lived and refresh tokens are long-lived, so deactivating a user takes effect on their next refresh — an already-issued access token stays valid until it expires. If you need someone locked out immediately, tell us and we will terminate the session.
Application secrets are held in AWS Secrets Manager rather than in configuration or source control.
06
Retention and deletion
We delete candidate data — recordings, transcripts, code submissions and scores — on request from you or from the candidate, and confirm in writing when it is done.
Automated retention schedules are not built yet. Deletion today is a request we action, not a policy the system enforces on a timer. If you need enforced retention windows, ask and we will tell you where that sits.
07
Subprocessors
We use AWS for hosting, storage, document extraction and model inference; Supabase for the database; Cloudflare for this site and for live interview rooms; and an email delivery provider for invitations. The current list, with what each one processes, is available on request and in the DPA.
08
Certification status
We are not SOC 2 certified, and no audit is currently under way. We would rather say that than display a badge for a report that does not exist. If certification is a procurement requirement for you today, we are not yet the right vendor.
We will complete a security questionnaire properly, and where the answer is “not yet” it will say so.
09
Reporting a vulnerability
Email security@recruit360.co. We acknowledge within one business day and will tell you what we intend to do and roughly when.
We will not pursue legal action against good-faith research that avoids privacy violations, service degradation and data destruction. There is no paid bounty, and we will say so rather than string you along.