Trust

Data residency

Last updated 4 July 2026
This page states plainly where CiaraLink stores and processes your data today, and the work in progress to bring all data at rest onshore. We would rather be honest than over-claim. We do not currently claim full Australian data residency — 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. Our participant and care records at rest are, today, stored in a managed database hosted in AWS Seoul, South Korea. We are working to migrate that database to AWS Sydney so all data at rest is also onshore.

Status today: application compute in Sydney (syd1); database, authentication and file storage at rest in AWS Seoul (ap-northeast-2). Target: database migration to AWS Sydney (ap-southeast-2). We will update this page and our marketing copy only once the Sydney migration is confirmed.

02 Where each system runs

SystemWhat it holdsLocation today
Application & API
(Vercel serverless functions)
Transient request processing only — no data stored hereSydney · syd1
Database, Auth & File storage
(Supabase / Postgres)
Participant and care records, user accounts, uploaded documentsAWS Seoul · ap-northeast-2
Static site / CDNPublic HTML, CSS and JavaScript — contains no customer dataGlobal CDN by design
Billing
(Stripe)
Subscription and card payment dataStripe 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 The move to Sydney

Managed database regions are fixed when a project is created, so bringing the database onshore is a planned migration rather than a switch we can flip. Our path is to stand up a new database in AWS Sydney (ap-southeast-2), apply our schema and security policies, migrate data, authentication accounts and stored files, re-point the application, and decommission the old region only after end-to-end verification.

Until that migration is confirmed, we keep the wording on this page and in our Privacy Policy deliberately precise about what is and is not yet in Australia.

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 (currently AWS Seoul; migrating to AWS Sydney).
  • 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.

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.