Security & Privacy Statement

Traffic to Kestrion is encrypted in transit with TLS. There is no unencrypted fallback path in the application, and HTTP Strict Transport Security is set for two years including subdomains.

Message bodies are encrypted at rest with AES-256-GCM. Uploaded documents — resumes and supporting files — are stored in a private bucket that is never publicly addressable; they are reached only through short-lived signed links generated on the server for a person who is already authorized to see them.

Passwords are never handled by our application code. They are hashed and stored by our authentication provider, and we have no mechanism to read them.

Authorization is enforced in the database itself through row-level security, not only in the interface. Every table carries policies that scope each query to the signed-in account and its role, so a request made directly against our data API is held to the same rules as one made through the app.

• Ownership comes from the session. Records are matched to the authenticated account on the server; an identifier supplied by the browser is never trusted to decide what you can see.
• Roles are enforced twice. Candidates, recruiters and administrators are separated both by route guards and, independently, by database policy.
• Two-factor authentication is available on every account using standard time-based one-time codes, and we recommend enabling it.
• Sensitive changes require your password again. Changing your email, changing your password, disabling two-factor authentication and deleting your account all re-check your credentials at the moment of the action, rather than relying on an open session.
• You can see and end your sessions. Settings lists the devices signed in to your account, with a control that signs out every other device immediately.
• Single sign-on via SAML is available for organizations that require it.

A Kestrion profile is searchable because the person it belongs to chose to be discoverable. Discoverability is a setting, it is yours, and turning it off removes you from recruiter search.

For what we collect, how long we keep it and how to request its deletion, see the Privacy Policy and Data Retention Policy.

Recruiting organizations are verified before they can search. Where a credential can be confirmed with the body that issued it, we confirm it there rather than accepting what was typed — and we distinguish that from a weaker document review rather than calling both “verified”.

A recruiter’s first message in a new conversation is screened for the patterns that characterize recruitment fraud — requests for payment, pressure to move off-platform, urgency language from an unverified sender. Messages that fail screening are held for human review and do not reach the candidate. Accounts can be warned, suspended or banned, and each of those decisions is recorded.

Administrative actions — account status changes, verification decisions, moderation outcomes — are written to an audit log recording who acted, on what, and when. Audit records are retained for one year and then deleted automatically.

Denied access attempts are logged separately, capturing the account, the resource and a reason code — never the contents of a message. Those records are retained for ninety days.

Accepted offers are kept as a durable record: the signature, a verification hash and the device details captured at the moment of acceptance, held independently of anything that changes afterward.

• A content security policy restricted to our own origin and our named service providers, plus the standard protections against framing, content-type sniffing and referrer leakage.
• Cross-site request forgery defended in two independent layers, verified against a running instance rather than assumed.
• Rate limiting on sign-up, sign-in, two-factor verification, password reset and account re-authentication, enforced in shared storage so it holds across every server instance.
• Automated checks on every change: type checking, linting, unit tests, an access-control regression suite covering attempts to reach another account’s records, and an accessibility scan.

If you’ve found a security vulnerability, please report it to security@kestrion.co rather than disclosing it publicly. We investigate all reports and will follow up directly. We ask for reasonable time to remediate before public disclosure, and we will not pursue action against researchers who report in good faith and avoid accessing other people’s data.

Kestrion is not SOC 2 attested and not ISO 27001 certified. We have not engaged an auditor, and we would rather state that plainly than display a badge we have not earned. We maintain practices consistent with GDPR and CCPA requirements, and this page will be updated as any formal assessment begins and progresses.

The controls described above are in place today and we are glad to walk an enterprise security team through them in detail. If you need documentation for a vendor review, write to security@kestrion.co.