Trust

Data residency

Last verified 20 August 2026 · Sydney at rest · Seoul decommissioned

This page states plainly where CiaraLink stores and processes your data. Participant and care data at rest is in Australia (AWS Sydney, ap-southeast-2). The migration from the previous Seoul region completed in July 2026 and the old region has been decommissioned. See the status below.

01 The short version

CiaraLink is built in Australia for Australian NDIS and healthcare teams, and our application runs from Sydney. Participant and care records at rest are stored in a managed database hosted in AWS Sydney (ap-southeast-2).

Status today: application compute in Sydney (syd1); database, authentication and file storage at rest in AWS Sydney (ap-southeast-2). Cutover from the previous Seoul region completed July 2026. The old Seoul project has been decommissioned.

02 Where each system runs

System	What it holds	Location today
Application & API (Vercel serverless functions)	Transient request processing only — no data stored here	Sydney · syd1
Database, Auth & File storage (Supabase / Postgres)	Participant and care records, user accounts, uploaded documents	AWS Sydney · ap-southeast-2
Static site / CDN	Public HTML, CSS and JavaScript — contains no customer data	Global CDN by design
Billing (Stripe)	Subscription and card payment data	Stripe global

Our application compute is pinned to Sydney (syd1) in our deployment configuration, which also keeps latency low. The static site is served from a global content-delivery network — that is standard practice and those files contain only public app code, never care data.

03 Data residency

Managed database regions are fixed when a project is created, so bringing the database onshore was a full migration rather than a switch we could flip. We stood up a new database in AWS Sydney (ap-southeast-2), applied our schema and security policies, migrated the data, authentication accounts and stored files, re-pointed the application, and decommissioned the old region after end-to-end verification. That cutover completed in July 2026.

Participant and care data at rest is now in Australia. Some third-party services we rely on (for example, card payment processing via Stripe) operate globally and handle only the limited data needed for their service, under their own security and privacy obligations.

04 Sub-processors

We keep a short register of the providers that hold or process customer data on our behalf:

Supabase — database, authentication and file storage (AWS Sydney · ap-southeast-2).
Vercel — application hosting and serverless functions (compute pinned to Sydney; static assets served via a global CDN).
Stripe — subscription billing and card payments, processed globally under Stripe's own security and privacy obligations.
Anthropic and OpenAI — where AI drafting features are enabled, the relevant text is processed by these providers (located overseas, in the United States) under their own security and privacy obligations. OpenAI is a fallback used only when the primary provider is unavailable.

Any new sub-processor that would store customer data is assessed for Australian residency before we bring it into service.

05 When data touches other services

Some services we rely on operate globally. Card payments are processed by Stripe, and where AI drafting features are enabled the relevant text is processed by our AI provider. These handle only the limited data needed for their function, under their own security and privacy obligations. When you connect an external accounting system such as Xero or MYOB, only the specific invoices or bills you choose to send are shared, under your own account with that provider — your participant records are not sent to them by CiaraLink.

06 Questions

If you need our current data-residency position in writing for a procurement or compliance review, contact us at admin@ciaralink.com.au. See also our Security & trust page and Privacy Policy.