Data Processing Addendum
Last updated: Draft — not yet finalised (pending legal review)
1. Definitions
Controller means the Provider organisation that determines the purpose and means of processing personal information entered into Caira. Processormeans Caira Pty Ltd, processing that information on the Controller’s documented instructions. Personal Information and Sensitive Information have the meanings given in the Privacy Act 1988 (Cth). Sub-processor means a third party engaged by Caira to process personal information as part of the service. Data Breach means an eligible data breach as defined by the Notifiable Data Breaches scheme.
2. Roles of the parties
For records the Provider enters or authorises (including participant health information), the Provider is the Controller and Caira is the Processor, acting only on the Provider’s documented instructions (these Terms, this Addendum, and in-product configuration). Where a participant’s record is shared across more than one Provider organisation under a nominee’s consent (a dual/triple-capacity arrangement), the nominee’s determination of who acts as Controller for the shared record is confirmed as part of legal review; each Provider organisation remains the Controller for the entries its own workers make.
3. Scope & purpose of processing
Caira processes personal information solely to provide, secure, support and improve Caira, for the duration of the Provider’s subscription, and for no other purpose.
4. Processor obligations & security measures
- Process personal information only on the Controller’s documented instructions.
- Ensure personnel with access are bound by confidentiality obligations.
- Encrypt data at rest and in transit.
- Enforce tenant isolation at the database layer (row-level security) so one organisation cannot access another’s data.
- Apply role-based access control, scoped to the minimum access each role needs.
- Maintain an immutable audit log of sensitive actions (create/edit/delete, consent changes, role changes).
- Scrub personal identifiers from free-text care notes before AI text processing, using a dictionary of known names plus regex and heuristic redaction for emails, phone numbers, NDIS/Medicare numbers, dates of birth, and likely person names.
- Gate audio transcription behind an explicit deployment flag (
AI_TRANSCRIPTION_ENABLED) defaulting to off, because audio cannot be scrubbed before it reaches the AI provider.
5. Sub-processors & data disclosed
Caira uses the following sub-processors as at the date of this draft. The table states what categories of data each receives. We will give the Controller reasonable advance notice before adding or replacing a sub-processor that will process the Controller’s data, with an opportunity to object on reasonable grounds.
| Sub-processor | Purpose | Data received | Region |
|---|---|---|---|
| Supabase (on AWS) | Primary database, authentication, and file storage | Participant profiles, care records, shift logs, progress notes, incidents, consent records, uploaded documents, and organisation/worker account metadata. Encrypted at rest. | Sydney, Australia (ap-southeast-2) |
| Google Gemini API | AI-assisted note generation, clarifying questions, meeting summaries, and audio transcription | Text prompts are scrubbed of personal identifiers before transmission (names tokenised; emails, phone numbers, NDIS/Medicare numbers, and heuristic name matches redacted). Audio recordings sent for transcription, and document/pill images sent for OCR, cannot be scrubbed beforehand and may contain spoken or printed personal information — this is a disclosed, consent-gated exception. Google processes data per its API terms; we do not use customer data to train models. | Google Cloud (region per Google's API terms — may be outside Australia) |
| Vercel | Application hosting, serverless compute, and content delivery | HTTP request metadata, session cookies, and transient request/response payloads while serving the application. Does not store participant records persistently. | Edge network; primary compute region configurable |
| Stripe | Subscription billing and payment processing | Provider organisation billing contact, payment method tokens, invoice metadata. No participant health records. | Per Stripe's infrastructure (may include US processing) |
| Resend | Transactional email (magic-link login, notifications) | Recipient email address, message subject/body for service emails. No participant care records in routine mail. | Per Resend's infrastructure |
| PostHog | Product analytics (de-identified / aggregated where possible) | Page views, feature usage events, coarse device/browser metadata. Configured to avoid capturing free-text care notes or participant identifiers. | Per PostHog's infrastructure (may be outside Australia) |
| Sentry | Error monitoring and performance tracing | Stack traces, request paths, release tags. Personal identifiers are stripped before capture where technically feasible. | Per Sentry's infrastructure (may be outside Australia) |
| Upstash | Rate limiting and spend-cap counters (Redis) | Opaque worker/org identifiers and request counters for throttling AI and API usage. No care-note content. | Per Upstash region selected for the deployment |
6. Cross-border disclosure (open item — pending legal advice)
Several sub-processors above (notably Google Gemini for AI features, and potentially Stripe, PostHog, and Sentry) may process data outside Australia. For text-based AI calls, personal identifiers are scrubbed before transmission; for audio transcription and image OCR, raw media may cross borders as a disclosed exception when explicitly enabled. Whether this satisfies Australian Privacy Principle 8 (cross-border disclosure), or whether additional contractual protections are required, is one of the specific questions we have put to our NDIS specialist lawyer and this clause will be finalised once that advice is received.
7. Assistance with data subject rights
Caira will assist the Controller, to the extent reasonably possible, in responding to a request from an individual to access, correct, or erase their personal information, including via the in-product right-to-erasure (de-identification) workflow.
8. Data breach notification
Caira will notify the Controller without undue delay after becoming aware of a Data Breach affecting the Controller’s data, and will cooperate with the Controller’s notifications to the OAIC and affected individuals under the Notifiable Data Breaches scheme. [Specific notification timeframe to be confirmed on legal review — see our internal data-breach response plan.]
9. Audit rights
On reasonable notice, and no more than once per year absent a suspected breach, the Controller may request evidence of Caira’s compliance with this Agreement (e.g. a summary of security measures or relevant certifications), subject to reasonable confidentiality protections.
10. Return or deletion of data
On termination of the Provider’s subscription, Caira will make the Controller’s data available for export for a reasonable period, then delete or de-identify it in line with the retention schedule described in our Privacy Policy, unless a longer period is required by law.
11. Liability & term
Liability under this Agreement is subject to the limitation of liability in our Terms of Service. This Agreement remains in effect for as long as Caira processes personal information on the Controller’s behalf.