Security at Hexense HR

Last updated: 12 August 2026

Hexense HR holds employment records — salaries, addresses, sick leave, performance reviews, signed contracts. This page describes how that data is protected, in enough detail to answer a security review without a call. Where a control is missing or weaker than we would like, it says so.

Questions this page does not answer: security@hexense-hr.com. To report a vulnerability, see our vulnerability disclosure policy.

1. Where your data lives

All customer data is stored and processed in the European Union.

• Database and file storage — Supabase, hosted on AWS eu-west-1 (Ireland).
• Application compute — Vercel, pinned to Dublin (dub1) so it is co-located with the database rather than reaching across regions.
• Off-site backups — Cloudflare R2, EU jurisdiction.

Every vendor with access to customer data is named, with its location and the data it sees, on our subprocessors page. We list a subprocessor before it processes anything, not after.

2. Tenant isolation

Each customer organization is a separate tenant. Isolation is enforced in the database, not only in application code, because application code is where isolation bugs live.

• Every table carrying customer data has an owning organization, and PostgreSQL Row-Level Security is enabled and forced on all 93 tables in the application schema. Forced means the table owner cannot bypass the policies either.
• Write policies carry an explicit check, so a row cannot be inserted or updated into another organization — a read-only policy would leave that half open.
• Foreign keys are composite on the organization column, so a record cannot reference a parent belonging to a different tenant.
• The application layer re-asserts the same boundary on every request, and the browser never holds a privileged key: it uses the public anonymous key and is governed by the policies above.
• A 9,767-line isolation test suite impersonates users from different organizations and asserts each cannot read or write the other’s rows. It runs in continuous integration on every change, against a database migrated from scratch, and a new tenant table cannot ship without appearing in it.

3. Encryption

• In transit — TLS on every connection, with HTTP Strict Transport Security set to two years, including subdomains, and submitted for preloading.
• At rest — database and file storage are encrypted by the platform (AWS-managed keys via Supabase).
• Credentials we hold on your behalf — calendar and Slack access tokens are encrypted at rest under our own key, above the platform’s encryption. API tokens issued to AI agents are stored only as SHA-256 hashes, so a database disclosure does not yield a usable token.
• Uploaded files (contracts, receipts, CVs) are served through short-lived signed URLs, never public links.

4. Access control

• Roles — employee, manager, or administrator, per organization. A user in more than one organization holds a separate role in each.
• Two-factor authentication is available to every user on every plan (authenticator app, with single-use recovery codes stored hashed). Administrators can require it for their whole organization.
• Single sign-on (SAML) is available on Enterprise, including restricting an email domain to SSO so a password cannot be used to bypass your identity provider. Automated user provisioning (SCIM) is built but not yet verified end to end, so we do not offer it as a working feature.
• Step-up verification — sensitive actions (changing a member’s role, offboarding, billing, changing a password, disabling two-factor) require a second factor verified within the last ten minutes, not merely at sign-in.
• Session management — every user can see their own active sessions (device, IP, last activity) and revoke any of them, singly or all at once. A revoked session loses access when its current sign-in token expires — within the hour, not instantly, and we say so in the product too.
• Access review — administrators have a built-in review of who holds elevated roles, when each role was granted and when it was last used, and can record a dated, audited attestation that the list was reviewed.

Our own access to your data

Our support staff can reach tenant data for support and platform administration. That access is deliberately held to a higher bar than a customer administrator’s:

• An enrolled second factor is required to open the staff console at all — it is not optional for us.
• Suspending an organization, exporting its data, changing its plan, or deleting it each require a second factor verified in the last ten minutes.
• Deletion additionally requires typing the organization’s identifier and is impossible until the account has been suspended for at least 30 days.
• Staff actions against your organization are written to your audit log, where your administrators can see them. An export of your data appears there as an event.

5. Audit logging

Security-relevant events — sign-in changes, role grants and revocations, approvals, exports, administrative changes — are recorded to a per-tenant audit log that your administrators can read. The log is append-only at the database level: updates are rejected at any age, so a timestamp cannot be altered after the fact. Entries are retained for 12 months by default — each organization can shorten this (never past 12 months, the maximum we retain), enforced by a scheduled sweep rather than by intention.

6. Backup and recovery

The database is backed up daily by Supabase. File storage is archived daily to Cloudflare R2 in the EU, separately and deliberately — managed database backups do not include stored files, and without the second archive a restore would return records pointing at documents that no longer exist. All six storage buckets are covered, and a test fails our build if a new bucket is added to the product without being added to the archive.

Backups are tested, not assumed. On 1 August 2026 we restored a production backup into a scratch project and required four things of it: that its migration history matched production, that a real user could sign in and load the application, that the full isolation suite still passed against the restored copy — proving the tenant boundary survived the restore and not merely the rows — and that no stored file references were left dangling. All four passed.

Recovery objectives, stated plainly

We would rather you had these figures than a better-sounding pair we cannot stand behind. Both are being worked on: point-in-time recovery would reduce the recovery point from a day to minutes, and the next drill will be timed.

7. Incidents and breach notification

Our Data Processing Agreement commits us to notifying you without undue delay, and within 72 hours of becoming aware of a personal data breach affecting your data. Reports from security researchers are acknowledged within five business days and assessed within ten, under our disclosure policy.

Application errors are captured in a monitoring service with personal data stripped before transmission, and availability is externally monitored.

8. How we build

• Every change is reviewed before it reaches production and must pass continuous integration: type checking, linting, the full test suite with enforced coverage floors, the tenant isolation suite against a from-scratch migration, and a check that no server-only module can be imported into browser code.
• Database migrations live in the repository and are reviewed like code. They are applied to a staging database before production, so a migration that cannot apply cleanly costs a throwaway environment rather than customer data.
• Dependencies are pinned by lockfile, installed frozen in CI, and monitored for advisories with automated update pull requests. New dependencies require explicit approval.
• Secrets are never committed and never reach the browser; that boundary is enforced by a lint rule and, as a hard backstop, by the production build failing.

9. What we do not have

Stated because you would find out anyway, and because a page that lists only strengths is not useful to you.

• No third-party penetration test. No external party has tested this product. If you need one before signing, tell us — it affects our scheduling.
• No security certification. We are not ISO 27001 certified and hold no SOC 2 report. We operate an information security management system built to ISO 27001:2022 and have completed an internal gap assessment against all 93 Annex A controls, but an internal assessment is not an audit and we will not present it as one.
• Point-in-time recovery is not purchased, which is why the recovery point above is up to 24 hours rather than minutes.
• Hexense HR is a very small company. That is a genuine continuity risk and we would rather name it than let you discover it. It is also why the controls above are mechanical wherever possible: enforced by the database, the build, or the test suite, so they do not depend on someone remembering.

10. Your rights and your data

The data subject rights the GDPR grants are served from inside the product, not by emailing us:

• Access and portability — any employee can export their own complete record as a machine-readable JSON bundle, and an administrator can produce the same bundle for a member handling a subject access request. Reports, payroll runs, timesheets, and the audit log export as CSV.
• Erasure — an administrator can erase an offboarded member. Identifying personal data is scrubbed in place, including stored documents and receipts, while the employment record the employer must keep and the append-only audit trail survive. This step is irreversible and available only after offboarding, so it cannot be used as a shortcut around it.

What we collect, why, and for how long is in our Privacy Policy; the terms under which we process it for you are in the Data Processing Agreement.

If your organization closes its account, data is retained for a 30-day grace period and then deleted.