At rest
AES-256 on the PostgreSQL database and every Cloud Storage bucket, with Cloud KMS-managed keys and per-domain rotation.
Trust & security
Built for an audit, not just a demo.
You hold some of the most sensitive records in the country. We treat them that way — your participants' data lives in Australia, your records survive everything, and every claim of "compliant" is something you can show an auditor.
Australian data
residency
residency
Encrypted in transit
& at rest
& at rest
Hash-chained
audit trail
audit trail
Granular
RBAC + MFA
RBAC + MFA
Privacy Act
& APP aligned
& APP aligned
ISO 27001
on the roadmap
on the roadmap
Our locked stack: Google Cloud australia-southeast1 (Sydney) · DR in australia-southeast2 (Melbourne) · Essential Eight-aligned by build.
Data residency & hosting
Your data stays in Australia. Full stop.
Every piece of participant and worker data is hosted, processed and backed up inside Australian Google Cloud regions. No overseas support desk quietly reading records, no participant record ever crossing a border — the only overseas services we use are operational ones (email delivery, error monitoring) that never carry participant records, and every one is listed on our published subprocessor register.
- Primary region — Google Cloud Sydney (australia-southeast1). All application, database and document storage runs here.
- Disaster recovery — Google Cloud Melbourne (australia-southeast2). Backups replicate cross-region, so recovery stays onshore too.
- A hard cross-border rule (APP 8). Care data never leaves the country — enforced by key policies that deny use outside the Australian regions.
- Australian AI, too. Any AI note-assist runs on Google Cloud's AI platform in Sydney — no OpenAI or US endpoints ever see care data.
Where your data lives
Primary · Sydney
australia-southeast1
App · PostgreSQL · Cloud Storage documents · audit anchors
DR & backups · Melbourne
australia-southeast2
Cross-region snapshots · document replication
Both regions are inside Australia — residency is preserved even during a full failover.
Encryption
Encrypted the whole way — disk, wire, and the phone in the field.
Encryption isn't one checkbox. It's applied at every layer data rests or travels, including the offline app that carries care records into dead spots.
In transit
TLS 1.2 minimum, 1.3 preferred, HSTS with preload on both domains. No public database endpoints.
Field-level
The highest-risk identifiers — worker screening numbers, bank details, NDIS numbers — get an extra application-layer encryption pass, searchable via blind index.
On the device
The offline store is an encrypted database with a key held in the phone's secure Keychain / Keystore. Remote-wipe and a 7-day offline lock bound a lost phone.
Audit trail
An audit trail you can't switch off — or tamper with.
A log you can turn off is just analytics. Ours is append-only and hash-chained: the database role can insert and read, but can't update or delete. Every record links to the one before it by a SHA-256 hash, so any alteration breaks the chain and shows.
- Reads are logged, not just writes. Who viewed a participant's health record — the piece most systems miss — is captured too.
- Anchored beyond reach. Each tenant's chain head is written nightly to locked-retention storage (Bucket Lock, 7-year retention); a weekly job re-verifies it and alerts on any mismatch.
- Signatures carry evidence. Every e-signature embeds signer, timestamp and device; every form keeps immutable version history — corrections are new versions, never destructive edits.
- Offline truth survives. Field events carry both the device time they happened and the server time they landed, so a clock-in dispute has an answer.
Evidence · chain verification
Verifiedexport.claims · Naya S. · 08/07/2026 14:02
prev 9f2a…c1 → hash 4b7e…d0
view.participant · Auditor · 08/07/2026 14:03
prev 4b7e…d0 → hash a15c…8f
sign.agreement · Family/Nominee · 08/07/2026 14:07
prev a15c…8f → hash 77b3…2e
Read, export and signature events all chained. Break one link and verification fails.
Access & roles
Least privilege, down to the field.
Access is a matrix of role × module × action — and "can see" is a different permission from "can change", enforced server-side, not just hidden in the UI. Every role is editable, including a first-class Auditor (read + export only) and Family / Nominee role.
The permission matrix — View and Edit are separate, enforced permissions.
Real view-vs-edit split
A role with View but not Edit gets a read-only record and a blocked save at the API — not a button that's merely greyed out.
Field & row scoping
Mask individual fields (43•••••12) and scope rows by region, home or assigned participants — enforced in policy and at the database.
MFA where it counts
TOTP two-factor is mandatory for any role that can administer or export sensitive data; biometric unlock on mobile.
Regulatory alignment
Mapped to the rules you're audited against.
We build the software so the standard is unmissable — and so you can show, not just claim, alignment. Here's the regulatory surface and how the product answers it.
| Regime | What it requires | How Tendaroo answers it |
|---|---|---|
| Privacy Act 1988 · APPs 1–13 | Collection notices, use limits, security, access & correction, cross-border limits | Collection notice in intake; per-module purpose binding; onshore-only processing; participant record export (APP 12); corrections as new versions (APP 13) |
| NDIS Practice Standards | Accurate, secure, retrievable records; governance & information management | NDIS vocabulary throughout; one-export audit packs for any date range; records stay read-only if billing lapses — never deleted |
| Incident Management & Reportable Incidents Rules 2018 | 24-hour initial + 5-business-day detailed notification; records kept 7 years | Statutory timer engine: category-driven reportability, live countdowns, escalation, validated Commission reference — not configurable off |
| Notifiable Data Breaches scheme | Assess suspected eligible breaches, notify the OAIC and affected individuals | Documented breach runbook; contractual commitment to notify affected providers within 72 hours (see below) |
| Worker Screening Rules · Fair Work s535 | Verify & record clearances; employee records kept 7 years | Screening records with expiry countdowns and roster blocks; 7-year retention on worker and payroll records |
Tendaroo is your data processor; you remain the APP entity and NDIS-regulated party. We build to make your obligations easy to meet and easy to evidence.
Reliability & your data
Your records survive everything — and they're always yours.
Backups are onshore, tested, and long-lived. And there's no lock-in on the data itself: you can export it any time.
≤ 5 min
Recovery point (RPO)
Continuous point-in-time recovery, 35-day window
≤ 4 h
Recovery time (RTO)
Target for a single-region loss, restored onshore
7 years
Record retention
Care, worker and audit records held to statute — soft-delete, never hard-delete in-window
Quarterly
Restore drills
Full restore to staging with checksum verification, logged
Leaving is a feature, not a fight
Full export any time (JSON + a human-readable PDF pack). On offboarding: export delivered, a 90-day hold, then per-tenant keys are crypto-shredded. The 7-year records duty transfers to you with the export — spelled out in the DPA.
If something goes wrong
Continuous monitoring, a rehearsed incident runbook, and an incident-response retainer with an Australian firm signed before launch. We commit contractually to notifying affected providers within 72 hours of a confirmed eligible breach.
Responsible AI
AI that suggests. It never decides, and it never invents care.
Where we use AI — like drafting a note from your dictation — it's suggestion-only, stamped "AI-assisted", and always waits for a human to sign off. It processes care data only inside Australia, and it never adds a care action you didn't record.
- Draft-only, human sign-off required
- Runs on Google Cloud's AI platform in Sydney — no US endpoints
- Your data never trains a model
- Must pass a safety test suite before it ships
Assurance roadmap
Secure by build today, certified tomorrow.
We're honest about where we are. The controls on this page are live from day one; formal certification is a dated commitment, not a vague "coming soon".
-
Now
Secure by build
ACSC Essential Eight (ML1) self-assessed; all controls on this page in code; MFA everywhere; policy pack written.
-
Next
ISMS formalised
Compliance-automation platform wired to our cloud and code; internal audit; Statement of Applicability.
-
Planned
ISO 27001:2022
Stage 1 + Stage 2 certification with a JAS-ANZ-accredited body, scoped to the production platform.
-
Planned
NDIA digital partnership
Cyber clearance off the back of ISO certification, opening the path to direct API claiming.
We also run external penetration tests before launch and annually (CREST-accredited AU firm), with dependency, secrets and cloud-posture scanning in continuous CI.
Transparency
The documents an evaluator actually asks for.
No email wall, no "contact sales". Our security posture is meant to be read before you ever talk to us.
The links just work. Give us your email only if you'd like us to keep you posted.
Evaluate it with your own eyes.
Start a free trial and see the audit trail, the residency and the role model for yourself — no credit card, no sales call. Or read the whitepaper first; it's right there.