StaffOPs
Where your data lives, and what protects it.
StaffOPs holds your staff's names, hours and pay rates. That is about as sensitive as business data gets, so here is the whole picture — including the parts we have not built yet.
Hosted in Sydney
The database and the application both run in Sydney, Australia, and backups are held in the same region. That was a deliberate choice: New Zealand and Australia are our first markets, so Australian data stays onshore, and New Zealand law permits sending personal information to a country with comparable safeguards, which Australia has.
We are not set up to serve UK or EU customers. If we open those markets we will host their data there rather than send it here.
We do not store location
If your business turns on the clock-in distance check, a phone's position is compared against the workplace address at that moment and then discarded. There is no column for it in our database. We cannot tell you where somebody was, because we do not know — only whether they were close enough when they pressed the button.
How it is protected
Every row is fenced in the database
Row-level security is enforced by Postgres itself, not by the application. A request can only read or change rows belonging to the requester’s own company and role — that holds even if there is a defect in our code, because the database is doing the checking.
Pay rates are scoped to a department
A manager can see rates for the departments they manage and no others. Staff see only their own. The company account sees all of them. Same enforcement — the database, not a hidden button.
Wage records cannot be quietly altered
A signed-off pay period is frozen at the database level. Edits to clock times keep the original alongside who changed it and why, and the audit trail has no update or delete path for anyone, including us.
Encrypted in transit and at rest
All traffic runs over TLS. Data at rest is encrypted by the hosting provider.
No third-party keys in the browser
A Content Security Policy and the standard security headers are set on every response. Address lookups are proxied through our own server, so the mapping provider never sees a visitor’s browser, IP address or cookies.
Least privilege for anything automated
Scheduled jobs and the in-app assistant run with the narrowest access that does the job. The assistant runs under the asking user’s own permissions, so it cannot surface something that person could not already see.
Backups
Automated daily backups of the database, retained for seven days, held in the same Sydney region.
Data goes when it should
Assistant messages are purged automatically after 12 months, and records of who was asked to work a shift after 24 months. Closing an account ends access immediately and permanently erases everything 30 days later — the delay exists so a mistake can be undone, because erasure cannot be.
Who else touches it
Five companies help us run StaffOPs. Each processes only what is described here, for the purpose described, under contract. We do not sell data and we do not advertise.
| Who | What for | What they receive | Where |
|---|---|---|---|
| Supabase | Database, authentication, file storage | Everything: names, emails, rosters, timesheets, pay rates | Sydney (ap-southeast-2) |
| Vercel | Application hosting | Request data in transit; no persistent store | Sydney (syd1) |
| Resend | Sending email — invites, resets, exports | Recipient address and message content | United States |
| Anthropic | The in-app assistant | What a user types to the assistant, plus the rostering data needed to answer | United States |
| Google Maps | Turning a workplace address into coordinates | The address text of a workplace — never a person’s position | United States |
Email, the assistant and address lookup process a limited set of data in the United States. For New Zealand and Australian customers that is a disclosed overseas transfer, and it is set out in full in the data processing agreement.
What we don't claim
Security pages are usually a list of the good news. These are the gaps, as at August 2026, so you can weigh them yourself rather than discover them in a due-diligence questionnaire.
- No multi-factor authentication yet. Sign-in is email and password with email verification, and password reset is by one-time code. MFA is planned.
- Point-in-time recovery is not enabled. We can restore from a daily backup, not to an arbitrary second.
- We have not yet confirmed the assistant provider's retention and model-training position in writing. We know what their terms say; we want it papered before we tell you it is settled. If you would rather not have the assistant at all, it can be switched off.
- No third-party certification. There is no SOC 2 or ISO 27001 report. StaffOPs is a young product from a small New Zealand company, and we would rather say that than imply otherwise.
Questions, or a security concern
Email hello@joytech.nz. If you believe you have found a vulnerability, tell us before telling anyone else and we will work with you on it. Our full privacy notice, generated from the product's own settings, is at staffops.joytech.nz/legal/privacy.
Send us your due-diligence questions
If you have a security or privacy questionnaire, send it over. We would rather answer it now than at contract stage.