Security overview.

roc.up holds the most sensitive category of personal information that exists under Australian law: the health information of NDIS participants. We treat that responsibility as the first thing we get right. This page lays out the security posture we operate to today — what's in place, what we audit, and what we'd do if something went wrong.

1. Where your data lives

• Australian-hosted. All customer data is stored in the AWS Sydney region (ap-southeast-2) via Supabase, our database and authentication provider. Data does not leave Australia for storage.
• Encrypted at rest. The database and storage volumes are encrypted with AES-256.
• Encrypted in transit. All connections — between your browser and roc.up, between roc.up and its sub-processors, and between background services — are over TLS 1.2 or higher.
• Per-customer scoping. Each customer workspace's data is scoped to the customer through row-level security policies on every database table. A worker on Provider A's workspace cannot read, edit, or even query the existence of a record belonging to Provider B.

2. Access controls

2.1 Inside your workspace

Within each customer workspace, roc.up enforces a layered permission model:

• Account holders & admins have full visibility within the workspace.
• Support workers see only the participants they are rostered to, and within each participant they see only the care-file sections the admin has authorised.
• Row-level security (RLS) on the database enforces these rules at the data layer. Even if an authorised query is constructed incorrectly, the database refuses to return rows the user is not entitled to see.
• Audit log. Edits to care files (medications, routines, risks, plan goals) are written to an append-only audit log capturing who, what, and when. The log is exportable.

2.2 roc.up staff access

• roc.up staff do not access customer production data routinely. Access happens only when required for support or troubleshooting, and only with the affected account holder's knowledge.
• Production access is restricted to a small number of named engineers; access is logged.
• All staff accounts use multi-factor authentication for any service that touches production data.
• We do not allow third-party support tools that record customer data without consent.

3. Authentication

• Customer passwords are never stored in plain text — they are hashed and salted before storage.
• Account holders can enable multi-factor authentication (MFA) on their account. [REVIEW: confirm MFA available on launch — Supabase Auth supports TOTP]
• Sessions expire after a period of inactivity; new sign-ins are logged.
• Suspicious sign-in attempts trigger rate limits and account lockouts.

4. Backups and recovery

• Daily automated backups of the production database, retained for 7 days in the Sydney region.
• Point-in-time recovery available within the retention window — we can restore the database to any moment within the last 7 days.
• Backups inherit the same encryption and access controls as production data.
• File attachments (uploaded photos, documents, training PDFs) are stored in Supabase Storage with versioned object retention.

5. The AI features

Pattern Watch and AI-drafted incident reports send shift-note text and handover text to a third-party AI model provider for analysis.

• Analysis happens under a data-processing agreement with the AI model provider that prohibits the provider from using your data to train their models.
• The model provider processes the text in transit for the request and does not retain a copy of your content after the response is returned.
• You can request that AI features be disabled for your workspace by emailing privacy@caringabode.com.au.
• AI outputs are surfaced inside your roc.up workspace only — they are not shared across customers or used by us for marketing or product development.

6. Sub-processors

The full live list of third parties we use to operate roc.up is at subprocessors.html. Each sub-processor is under a written data-processing arrangement. We commit to giving notice when we add or change one.

7. Incident response

If we become aware of a security incident affecting your data:

• We follow our internal incident-response playbook to contain, eradicate, and recover from the incident.
• We assess whether the incident meets the threshold for an eligible data breach under the Notifiable Data Breaches scheme (Part IIIC of the Privacy Act). The Privacy Act gives us up to 30 days to assess; in practice we aim to assess within 72 hours.
• If the incident is likely to result in serious harm, we notify the Office of the Australian Information Commissioner (OAIC) and the affected individuals as soon as practicable.
• We notify the affected customer (you) directly, with what happened, what data was involved, what we have done, what you should do, and how to contact us.
• For incidents involving the My Health Record system (if applicable), we additionally notify the System Operator under the My Health Records Act.

8. Vulnerability disclosure

If you believe you have found a security vulnerability in roc.up, please tell us at security@caringabode.com.au. We welcome responsible disclosure. Please give us a reasonable window to respond and fix before publishing details; we will acknowledge receipt within 5 business days and give you a status update at least every 14 days while we work on the issue.

We do not currently pay bug bounties, but we will publicly credit security researchers (with permission) once a fix is in place.

9. Compliance roadmap

roc.up is not currently certified to SOC 2 or ISO 27001. We are establishing the controls necessary for one or both, with a target of [REVIEW: target date]. In the meantime, our security posture is aligned with the controls expected in those frameworks even where not formally audited.

10. What you should do on your end

Security is shared. As a customer, you are responsible for:

• Keeping your account credentials confidential and enabling MFA when available.
• Inviting only people who genuinely need access to your workspace, and removing them when they no longer need it.
• Configuring per-worker section permissions correctly for each participant.
• Obtaining all consents you need from participants (or their nominees) to enter their information into roc.up.
• Meeting your own NDIS Quality and Safeguards Commission record-keeping obligations — roc.up enables them, but they remain your obligations.

11. Contact

• Security & vulnerabilities — security@caringabode.com.au
• Privacy & data subject requests — privacy@caringabode.com.au
• OAIC (escalation) — oaic.gov.au or 1300 363 992