Access is enforced in the database itself, so each user only ever loads the records they are entitled to.
All traffic is served over HTTPS/TLS with HSTS, and sensitive integration tokens are additionally encrypted at rest.
Recorded consent and role permissions decide who sees what — and participants stay in control of their own information.
Application compute runs in Sydney (syd1). See our data-residency page for the full picture on data at rest.
Every user only sees the records they are allowed to see, and this is enforced in the database — not just in the interface. CiaraLink uses PostgreSQL row-level security (RLS) across its data model: RLS is enabled on the platform's tables, governed by a large set of policies that scope each query to the requesting user's role, organisation and the participants they are connected to.
Access is further shaped by recorded consent and role-based permissions, so a support worker, coordinator, allied-health professional, participant or guardian each sees a view appropriate to their role. Participants stay in control of who can see their information.
In transit. All connections to CiaraLink use HTTPS/TLS, and we send a Strict-Transport-Security (HSTS) header so browsers only ever connect over a secure channel.
At rest. Care data is held in our managed Postgres database and object storage, which encrypt data at rest at the infrastructure layer. In addition, when you connect an accounting integration such as Xero or MYOB, the OAuth tokens we store are encrypted at the application layer using AES-256-GCM before they are written to the database — and in production the platform refuses to persist those tokens at all if the encryption key is not configured, rather than store them in plaintext.
Sign-in is handled by Supabase Auth, a managed authentication service. Sessions are token-based, and each request is authorised against the row-level-security policies described above. Passwords are never stored in application code or in customer records.
The application and its serverless API functions are hosted on Vercel, with compute pinned to the Sydney (syd1) region. Our database, authentication and file storage run on Supabase (managed PostgreSQL).
Today, the database at rest is hosted in AWS Seoul (ap-northeast-2) and we are migrating it to AWS Sydney (ap-southeast-2). We set this out honestly and in full on our dedicated data-residency page.
Our database runs on Supabase's managed PostgreSQL platform, which provides automated backups of the database. Hosting and database infrastructure run on established cloud providers (AWS via Supabase, and Vercel) with their own redundancy and availability engineering.
Every response from CiaraLink carries a set of security headers to reduce the risk of common web attacks:
frame-ancestors — prevent clickjacking;Server-side API inputs such as record identifiers are validated (for example, UUID format checks) to guard against injection, and privileged server operations run only in our backend — never in the browser.
Server-side secrets — including our privileged database service key and payment-processor keys — are stored only in our hosting provider's encrypted environment configuration. They are never shipped to the browser and never committed to source control. The browser only ever receives the public, restricted keys it needs to talk to the database under row-level security.
We want to be straight with you: CiaraLink does not currently hold an independent security certification such as SOC 2 or ISO 27001, and we do not claim one. We build on infrastructure providers (Vercel, Supabase and AWS, and Stripe for payments) that maintain their own independent security and compliance programs, and we design our own controls — row-level security, encryption, least-privilege access and application hardening — to protect care data. As the platform matures we will assess formal certification, and we will only ever publish a certification once it is genuinely in place.
If you believe you have found a security vulnerability, or that an account may have been compromised, please tell us promptly at admin@ciaralink.com.au. We appreciate responsible disclosure and will work with you to understand and resolve the issue. Please give us reasonable time to respond before any public disclosure.
For security questions, a due-diligence questionnaire, or documentation for a procurement review, contact us at admin@ciaralink.com.au. See also our Data residency page and Privacy Policy.