Data Processing
Caireo · Commitments to provider organisations · Effective 7 September 2026
This page is for the person at a provider organisation who has to answer for its data — a privacy officer, a quality manager, or whoever is sitting across from an NDIS auditor. It forms part of the Terms of Service and records what Caireo does with the information you put into the Platform, in enough detail to be checked rather than taken on trust.
1. Roles
You are the APP entity for Customer Data. We process it on your behalf and on your instructions, which are given by the settings you choose and the features you use. We do not determine the purposes of processing, and we will not process Customer Data for our own purposes.
If we ever receive a request from a regulator, a court or a law enforcement agency for your Customer Data, we will tell you before responding unless legally prohibited, so that you can take your own advice.
2. What we do with Customer Data
Only these things:
- store it, and serve it back to the people you have authorised;
- transmit it between the app, the dashboard and the database;
- back it up, and restore it if something fails;
- send the operational notifications your settings ask for;
- calculate the figures the Platform is designed to calculate;
- investigate a fault or a security incident, with access logged; and
- comply with a law that applies to us.
We do not sell it, share it with advertisers or data brokers, use it to train machine learning models, or permit our sub-processors to do any of those things.
3. Where it is held
The record system is operated by Supabase in Sydney, Australia (ap-southeast-2). Participant records, progress notes, incident reports, medication entries, uploaded documents and the backups of all of it stay in Australia.
We say this first and plainly because it is the question that matters most for your own compliance, and because it is the one an auditor asks before any other. If your funding agreement, a state health records obligation, or your own policy requires participant information to remain onshore, this arrangement meets it.
The supporting services below do not all run in Australia — push delivery, app updates, transactional email, payments, address lookup, and the language model behind optional voice commands. What reaches each of them is listed against its name and never includes the clinical record. Those are cross-border disclosures, and under section 16C of the Privacy Act we remain accountable for how each recipient handles what it receives.
4. Sub-processors
| Provider | Purpose | Location | Data |
|---|---|---|---|
| Supabase | Database, authentication, file storage and server functions — the primary record system | Sydney, Australia (AWS ap-southeast-2) | All platform data, including participant records, progress notes, incident reports and uploaded documents |
| Vercel | Hosting and delivery of the web dashboard | United States, with edge delivery worldwide | Request metadata and data in transit; no separate copy of the record system is stored |
| Expo (EAS) | Mobile app distribution, over-the-air updates and push notification delivery | United States | Device push tokens and notification content (operational only — never health information) |
| Apple, Google | App distribution and push notification transport to the device | United States and global | Device push tokens and notification content |
| Groq, Google (Gemini API) | Parsing a spoken command into an action, where an organisation enables voice control | United States | The text of the spoken command only, which may include a worker or participant name |
| Brevo | Transactional email — invitations, password resets, alert digests | European Union (France) | Recipient email address and the content of that email |
| Stripe | Subscription billing and payment processing for provider organisations | United States and Australia | Billing contact and payment details of the organisation. Card numbers are handled by Stripe and never reach Caireo |
| Xero | Accounting sync, only where an organisation connects it | Australia and New Zealand | Invoice and billing totals. No participant health information, progress note or incident record is sent |
| OpenStreetMap Foundation (Nominatim) | Turning a typed address into map coordinates for shift locations | European Union | The address text being looked up. It is not linked to a named person in the request |
Each is engaged under terms requiring APP-equivalent handling, purpose limitation, security, prompt breach notification, and equivalent obligations on their own sub-processors. We will give provider organisations 30 days' notice before adding a sub-processor that receives participant information, and you may terminate without penalty if you object.
5. Security controls
| Control | What is actually in place |
|---|---|
| Encryption | TLS in transit; AES-256 at rest, including file storage and backups. |
| Tenant isolation | Every table carries an organisation, and row-level security in the database enforces it. A query that omits the organisation filter returns nothing rather than another organisation's rows — the boundary is in the database, not only in the interface. |
| Access control | Role-based: platform administrator, organisation administrator, support worker, participant. A worker sees their own shifts and the participants they are rostered to. A participant sees only their own record. |
| Authentication | Credentials are hashed and never visible to us or to you. Sessions expire. Password reset is email-verified. |
| Audit trail | Administrative actions are logged with actor and timestamp. Clinical records such as medication administration are append-only — a correction is recorded as a correction and the original remains. |
| Backups | Automated daily, point-in-time recovery, restores tested. Backups carry the same encryption and residency as the primary database. |
| Personnel | Production access is limited to the people who need it, is logged, and is removed on departure. Support staff access a provider's data only to resolve a request. |
| Change management | Changes are version controlled and reviewed. Database schema changes are applied as migrations that are recorded and replayable. |
6. Breach response
On becoming aware of a suspected breach we contain it, preserve evidence, and assess it within 30 days as Part IIIC of the Privacy Act requires. We notify affected provider organisations without undue delay and in any event within 72 hours of becoming aware, with what happened, what data was involved, what we are doing, and what you should do. Where a breach is likely to result in serious harm, notification goes to the OAIC and to affected individuals. Where you are the APP entity, we support your notification rather than making one in your place, and we give you what you need to make it.
7. Retention and return
We retain Customer Data for as long as your subscription runs. On termination you have 60 days to export it, and we will provide a machine-readable export on request. We then delete it from live systems, and from backups within a further 90 days.
Your NDIS obligation to retain records for 7 years — and until age 25 where the participant was a child — is yours and continues after you stop using the Platform. Export before you leave.
8. Assisting you with individual rights
Workers and participants exercise access, correction and complaint rights with you. Where you need data we hold to answer them, or need something corrected or deleted that you cannot reach through the interface, ask us and we will action it within 14 days at no charge.
9. Audit
On reasonable notice, once a year, and more often after a breach affecting you, we will answer a written security questionnaire and provide the evidence available to us about the controls above. Where a sub-processor holds a certification or report, we will pass on what we are permitted to share.
10. Contact
careconnectsupports@gmail.com, addressed to the Privacy Officer. See also the Privacy Policy and Terms of Service.
© 2026 Caireo.