Legal
Security
How HireOS protects candidate data, written plainly enough to forward to a client who asks.
Last updated 29 July 2026
1.Tenant isolation
An agency is an organisation, and every job, candidate and screening belongs to exactly one. Isolation is enforced in the data-access layer: reads are scoped by organisation as part of the lookup, not checked afterwards, so a guessed identifier from another workspace resolves to nothing rather than to someone else's candidate.
2.Credentials and secrets
Passwords are hashed and never stored or logged in plain text. Service credentials are encrypted at rest with AES-256-GCM, so a tampered record fails to decrypt rather than yielding corrupted data. They are never returned to the browser or included in exports.
3.Candidate files
Original CVs are stored so recruiters can check the document rather than only the model's reading of it. They are served with private, no-store caching, and access is scoped to the owning workspace.
4.Access control
Workspaces have owner, admin and recruiter roles. Model settings, billing-relevant configuration, team management and the retention policy are restricted to owners and admins. The last owner of a workspace cannot be removed, so a workspace can never be orphaned.
5.Auditability
Deletions, data exports and retention purges are written to an append-only log that cannot be edited or removed from inside the product. Entries record who acted and what changed, and survive that person leaving the agency.
6.What we do not do
We do not train models on your data. We do not pool candidates between agencies. We do not send email to candidates on your behalf. We do not sell personal data.
7.Reporting a vulnerability
If you believe you have found a security issue, contact us before disclosing it publicly. We will acknowledge quickly and keep you updated while we fix it.
Something here you need changed before you can sign? Say so on the call — we would rather agree terms you are comfortable with.
Book a call