This page describes controls that are actually in place today. We update it as the product evolves — no vapourware.
Every table that stores agency data has Postgres row-level security switched on. Policies scope reads and writes to the caller's agency membership, so one agency cannot see or modify another agency's workers, shifts, credentials, timesheets, invoices or audit records.
All traffic to StaffReady is served over TLS. Application data and uploaded documents are encrypted at rest by our managed Postgres and object storage providers.
Credential documents (AHPRA certificates, police checks, working-with-children checks, NDIS clearances) are stored in a private bucket. Files are namespaced by agency and worker, and access is gated by the same row-level security rules that protect the database.
Creating a worker, verifying a credential, broadcasting a shift, approving a timesheet, generating an invoice, sending it, marking it paid — each writes an append-only entry to the audit log. Entries record who acted, the agency, the entity, the time, and the values that changed. Facility approvals are done from an emailed link rather than an account, so those entries carry the approver's email address and a hash of their IP instead of a user id. The database grants agencies read and insert on the log and nothing else: there is no screen, API or support tool that edits or deletes an entry. You can filter and export the whole trail as CSV from the Compliance tab.
Users sign in with email and password. Passwords are hashed by our identity provider and never stored by StaffReady. Facility timesheet approvals use single-use magic links that expire after a short window.
Sensitive configuration (for example, Stripe API keys and webhook secrets) is held in a service-role-only table with no client-facing access policies. Only server-side code running with the service role can read it.
Your data is held in a managed Postgres instance and a private object store in Sydney, Australia (AWS ap-southeast-2), both encrypted at rest and in transit. The platform previously ran in Singapore; it was migrated to Australia and this page was updated only once that migration was verified. If your procurement requires Australian-only data residency, that condition is met today. Ask us and we will confirm it in writing.
Server-side secrets — the database service-role credential, payment provider keys and webhook signing secrets — are held in our deployment platform's encrypted secret store, injected into the server runtime at request time, and never committed to source control or shipped to the browser. The only key the browser receives is a publishable key whose reach is constrained by the row-level security policies above. Secrets are rotatable without a code change, and rotation does not require downtime.
MFA is not available yet. Sign-in today is email and password, with known-breached passwords rejected at sign-up and password hashing handled by our identity provider. MFA for agency administrators is on our roadmap and is not yet scheduled. We would rather tell you that plainly than let a security questionnaire assume otherwise — if MFA is a go-live requirement for your facility, contact us before committing.
Full schema and data export is available on request for every agency, so you're never locked in.
Email security@staffready.com.au with details. We'll acknowledge within two business days.