How we handle your data.

Database and API: Sydney. Full stop.

Production data is stored on Supabase Postgres running on AWS infrastructure in the Sydney region (ap-southeast-2). Our API runs on Fly.io in their Sydney region (syd). Same city, same regulatory jurisdiction, sub-5ms latency between the two. File storage (Cloudflare R2) is the one exception: it sits in the Oceania region, a broader footprint than Australia alone, and an Australia-pinned move is planned.

• Participant and worker records are stored on Australian database infrastructure. A small number of US sub-processors handle narrow jobs (error reporting, payments, AI features), each is named in our privacy policy
• Single-region Australian deployment for the database: no offshore database replicas. The only other places data goes are Cloudflare R2 (Oceania region, for file storage) and the named sub-processors (error reporting, payments, AI), all listed in our privacy policy
• Postgres project provisioned 2026-04-17: Supabase's own dashboard labels the region "Oceania (Sydney)", its umbrella name for this specific Sydney datacentre, not the broader multi-country Oceania region Cloudflare R2 uses above

Daily, automated, verified.

Supabase takes a physical (block-level) backup of the database every 24 hours, retained for a rolling 7-day window. We monitor backup status and confirm completion before claiming a successful day.

• Daily automated backups: physical (block-level) via continuous WAL archiving
• 7-day rolling backup retention
• All recent backups completing successfully (last verified 2026-05-14, audit on file)
• Backups stored in the same AWS Sydney region as the live database
• Point-in-time recovery (PITR) is available on request for enterprise customers, not enabled by default on standard plans

Encrypted at rest, encrypted in transit.

Every connection to Clearline uses TLS 1.2 or higher. Database storage is encrypted at rest. Application secrets (API keys, database credentials, signing keys) live in platform secret management, never in source code or committed config files.

• TLS 1.2+ enforced on every endpoint: HTTP is rejected, not redirected silently
• Postgres encrypted at rest (Supabase default, AES-256)
• NDIS numbers are matched by a keyed hash (HMAC-SHA256 with a server-side pepper), never by the number itself. Pilot and Scrive records store the number encrypted at rest; Aura and Compass records are being migrated onto the same encrypted storage and still hold a readable copy until that completes.
• Application secrets held in Fly.io's secret management, separated from the application image
• Audit log on every state-changing action across the platform (~22 distinct event types live today)

Removed before it reaches a model. Restored before you read it.

Shift-note summarisation, live today, works like this: before a shift note is sent to an AI model, we remove the names of the participants and workers we hold a record for, along with NDIS numbers, Medicare numbers, tax file numbers, individual healthcare identifiers, phone numbers and email addresses. A separate, independent check then re-scans the text: if it can't confirm the removal worked, the request is refused rather than sent. The real details are put back locally once the model responds, so your team sees the full record and the model never did.

• Covers the people we hold a record for. A visiting GP, a neighbour, or anyone else named in a note but not in our system is not covered by this
• AI processing runs through the named US providers listed in our Privacy Policy § 4.2. The scrub happens locally before anything leaves for the model, and the restore happens locally once it returns

The participant is the centre of their data.

Clearline Connect (our cross-product layer) routes every data flow through the participant's nominated consent owner. Families approve who joins their participant's care team, and every connection waits on a tap from both sides: a home-screen nudge shows who's asking, and nothing is shared until both approve. Either side can revoke at any time. Every cross-product access is logged for the consent owner to see.

• Participants and their nominees can request a data export by emailing support@clearlinehealth.com.au
• Consent revocation flows are wired into the platform via the Connect identity layer, revoke from your account at any time
• On revocation, cross-product data flow stops within seconds. The provider sees a notice in their app; further reads of the revoked scope return 403
• On account closure: data deleted within 90 days, except where retention is required by law
• NDIS compliance records (shifts, incidents, participant records) are retained for 7 years per NDIS requirements: the legal floor we have to meet. See the full retention table in our Privacy Policy § 5.4

One person to email.

Security disclosures and data-handling questions go to a single mailbox monitored by the founder. No security@ alias, no triage tier, no support runaround. Faster for everyone.

Built for the NDIS, not adapted from generic SaaS.

Clearline is built specifically around NDIS workflows: PACE reports, Practice Standards, SIL operational compliance, support-coordinator funding justifications, family consent. We build Clearline to help providers meet their obligations under the NDIS Practice Standards and the NDIS Code of Conduct, and to give participants and families clear visibility over their own data. The Practice Standards apply to registered NDIS providers, not to software vendors, but the workflows we build are shaped around them. A dedicated NDIS compliance page is in development covering how the platform maps to specific Practice Standards and audit expectations.