Security & trust
You are handing us your workers' personal details and your clients' commercial information. Here is how it is kept, who can reach it, and — just as usefully — what we do not claim.
Security pages usually read like a certification list. We do not have certifications yet, so this one is the other thing: a plain account of how the product is actually built. We are pre-launch, which is the most useful security fact here — every control below went in before anyone's data was in it, rather than after an incident.
One region, and we can tell you which. The application runs on Fly in Sydney and the database sits in the same city on AWS ap-southeast-2 — the closest region to New Zealand that a managed Postgres exists in. Nothing is quietly replicated offshore; adding an overseas processor would be a decision with a paper trail, not a config change.
Every agency is a separate tenant, and there are two independent things keeping them apart — which is deliberate, because a single control is a single point of failure. Inside the application, every query is scoped to your organisation in code and behind a permission check. Underneath, row-level security is switched on across the database, so the data API a browser can reach refuses to answer for anyone else's rows even if the application were bypassed entirely.
Access follows the role, and the roles are yours to change. Thirty-three named permissions across twelve areas — candidates, pay and bill, compliance, settings and the rest — with fifteen roles seeded ready for a labour-hire desk. A consultant does not see payroll. A worker sees their own shifts, not your margins.
Sensitive actions are written to an append-only audit log, and each entry is hash-chained to the one before it within your tenant. The chaining is done by the database itself as the row is written, not by the application asking nicely, so changing what an old entry recorded breaks every hash after it. A scheduled job re-walks the chain nightly and shouts if it does not add up.
New Zealand privacy law says personal information should not be kept longer than it is needed, and employment and health-and-safety law says some of it must be kept for years. Those pull in opposite directions, so retention is a setting you control per tenant rather than a number we chose for you — and a legal hold beats it.
Workhr has an assistant that can read your data and take actions. Because that is a genuine risk surface, it ships with the switches on the outside: turn it off for the whole organisation, put it in read-only mode so it can answer but never change anything, or leave it on and choose action by action what it may do.
Most breaches are not clever. They are a leaked key, a stale dependency or a header nobody set. Those are checked mechanically, on every change, rather than being somebody's job to remember.
A security page that only lists strengths is not a security page. These are the things a careful buyer will ask about, and the true answer to each. We would rather you hear them here than find them in month three.
Sydney for the app and the database. No offshore replication.
Tenant scoping in the app, row-level security under it.
A hash-chained record of sensitive actions, verified nightly.
No certifications yet, and this page says so.
Send us your questionnaire, or book a walkthrough — we will answer with the same specificity as this page.