Data security.

Caredly handles sensitive NDIS participant data — health information, behaviour observations, medication records, and stakeholder reports. Security is a first-class product concern at every layer of the stack, not a checkbox to tick before launch.

Our security programme is aligned with the Australian Privacy Principles (APPs) under the Privacy Act 1988 (Cth), the Notifiable Data Breaches (NDB) scheme, and the expectations set by the NDIS Quality and Safeguards Commission. Where formal certifications (ISO 27001, SOC 2 Type II) are on our roadmap rather than complete, we say so explicitly on this page.

This page describes:

• where data is stored and how it is protected in transit and at rest;
• who can access data and how that access is governed;
• how we detect, respond to, and recover from incidents and vulnerabilities;
• the sub-processors who help us deliver the service; and
• the responsibilities customers retain in keeping their own use of Caredly secure.

All customer data — including participant records, shift notes, BSPs, medication records, behaviour observations, audit logs, and stakeholder contacts — is stored in Australia, in the Sydney region (ap-southeast-2) on Supabase infrastructure. Supabase itself is built on AWS, which holds SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018, and IRAP certifications upstream.

Customer data does not leave Australia for storage. Limited cross-border processing occurs only for specific operational functions:

• AI features — the minimum context required for an AI request is sent to Anthropic, processed in the United States, under contractual safeguards;
• Transactional email — Resend processes message metadata in the United States;
• Frontend delivery — Vercel serves static assets from global edge locations, including points of presence in Australia, and does not persist customer data.

• In transit. All connections to the Caredly platform use TLS 1.2 or higher, with HSTS enforced. We disable known-weak cipher suites and rotate certificates automatically through our hosting provider.
• At rest. Storage volumes and databases are encrypted at rest using AES-256.
• Backups. Backups are encrypted using AES-256 and stored in the same Australian region as the primary database.
• Column-level encryption. Highly sensitive fields (NDIS numbers, payment metadata) receive an additional layer of application-level encryption beyond the storage-layer encryption.
• Voice recordings. Voice recordings used for shift-note dictation are encrypted on the client device prior to upload and re-encrypted server-side after storage. Recordings are deleted following successful transcription unless the customer has explicitly opted to retain them.

• User authentication. Email and password with optional magic-link sign-in. Passwords are hashed using a modern adaptive algorithm (Argon2id / bcrypt as configured by Supabase Auth).
• Two-factor authentication. Available for all users via authenticator app, and required for administrator-level roles by default.
• Session expiry. Sessions expire after twelve (12) hours of inactivity, with shorter expiry for elevated operations.
• Single sign-on (SSO). SAML and OIDC SSO available on Enterprise plans, with support for SCIM provisioning.
• Role-based access control (RBAC).Built-in roles include administrator, supervisor, support worker, on-call, and stakeholder, each with its own permission profile. Customers can tailor roles within the limits of the platform’s permission model.
• Row-level security (RLS). Supabase row-level security policies ensure that authenticated users can only read or modify data that belongs to their organisation and that they are authorised to access. Policies are tested in CI on every change to the data model.
• API authorisation. All API endpoints are authenticated and authorised. Sensitive operations (delete, export, grant elevated access) are audit-logged.

Every access to a participant record is logged: which user, at what time, on which record, and from what IP address. This includes reads as well as writes. Customers can review logs for their own organisation in the platform.

• Hot retention. Logs are retained in queryable form for twelve (12) months.
• Archive retention. Logs are archived in tamper-evident storage for seven (7) years to meet NDIS record-keeping obligations.
• Append-only. Audit logs are append-only and cannot be modified or deleted by customer-facing accounts.

• Continuous backups. Continuous incremental backups with point-in-time recovery (PITR) to within five (5) minutes of any point in the last seven (7) days.
• Daily full backups. Encrypted full backups taken daily and retained for thirty (30) days.
• Weekly archival backups. Encrypted weekly backups retained for twelve (12) months.
• Disaster recovery objectives. Recovery point objective (RPO) of five (5) minutes; recovery time objective (RTO) of four (4) hours.
• Restoration drills. Backup restoration drills are performed at least quarterly and documented in our internal runbook.

• Dependency scanning. Every build runs npm audit, Dependabot alerts, and Snyk scans. High and critical findings block deployment.
• Static analysis. Static application security testing (SAST) runs in CI on every pull request. Linting, type checking, and secret-scanning are enforced.
• Penetration testing. Quarterly internal penetration testing led by our engineering team. An annual external penetration test by an independent firm will commence at general availability.
• Patch cadence. Critical security patches are applied within twenty-four (24) hours of public disclosure; high severity within seven (7) days.
• Bug bounty. A bug bounty programme will launch with general availability. Until then, we welcome responsible disclosure via security@caredly.com.au.

We maintain a documented incident response plan covering detection, containment, eradication, recovery, and post-incident review.

• On-call rotation. Engineers carry on-call responsibility with documented escalation paths.
• Severity classification. Incidents are classified P0 (catastrophic), P1 (major), P2 (moderate), and P3 (minor), with response targets matched to severity.
• Customer notification. Affected customers are notified within seventy-two (72) hours of confirming a reportable data breach, with the information they need to meet their own Notifiable Data Breaches obligations to participants.
• Regulator notification. Where required under the NDB scheme, we notify the Office of the Australian Information Commissioner (OAIC).
• Post-incident review. Every P0 and P1 incident is followed by a written post-incident review, shared with affected customers and used to improve our controls.

The following sub-processors help us deliver the service. Each is contractually bound to confidentiality and security obligations consistent with our privacy policy and these security commitments. We will give existing customers reasonable notice before adding or materially changing a sub-processor that processes Participant Data.

• Background checks. Staff with access to production systems are subject to background checks before access is granted.
• Security awareness training. All staff complete annual security awareness training, including phishing, credential-handling, and incident escalation modules.
• Least privilege. Production access is granted on a least-privilege basis, reviewed quarterly, and revoked immediately on role change or departure.
• Production access controls. All production access requires two-factor authentication and is audit-logged.
• Endpoint protection. Staff laptops are encrypted (FileVault on macOS, BitLocker on Windows), enrolled in mobile device management, and configured with screen-lock policies.
• Secrets management. Secrets and credentials are stored in a dedicated secret manager and never committed to source control. CI runs secret-scanning on every commit.
• Change management. All changes to production are made via reviewed pull requests, with required approvals and automated test gates.

• Australian Privacy Principles (APPs) — our processing of personal information is governed by the APPs under the Privacy Act 1988 (Cth). See our privacy policy.
• Notifiable Data Breaches (NDB) scheme — we comply with our notification obligations under Part IIIC of the Privacy Act.
• NDIS Quality and Safeguards Practice Standards — we align our handling of participant data with the expectations set out in the Practice Standards. Caredly is a software vendor; we are not a registered NDIS provider, and we do not deliver NDIS supports directly.
• ISO 27001 — our information security programme is aligned with ISO 27001 principles. Formal certification is on our roadmap.
• SOC 2 Type II — on our roadmap for general availability.

Security is shared. The technical and organisational controls described on this page protect Caredly’s side of the platform; customers retain responsibility for the controls within their own organisation.

• managing their own user access — granting roles appropriately and revoking access promptly when staff leave or change roles;
• using strong, unique passwords and enabling two-factor authentication for all administrator users;
• keeping the devices used to access Caredly secure (operating-system updates, disk encryption, screen lock);
• protecting any data exported from the platform with controls equivalent to those Caredly applies in-platform;
• promptly reporting suspected compromises to security@caredly.com.au; and
• obtaining and maintaining lawful consent from participants and their guardians under the customer’s NDIS service agreements.

We welcome and value coordinated disclosure of suspected vulnerabilities. To report a security issue, email security@caredly.com.au with as much detail as you can: a description of the issue, steps to reproduce, the affected URLs or components, and any supporting evidence.

Our service-level commitments to reporters:

1. Acknowledgement — we confirm receipt within one (1) business day;
2. Severity assessment — we acknowledge severity and initial triage within five (5) business days;
3. Resolution — we work the issue to resolution and provide an estimated remediation timeline appropriate to its severity; and
4. Recognition— with the reporter’s consent, we credit responsible reporters publicly once the issue is resolved.

Please act in good faith: do not exploit a vulnerability beyond what is necessary to demonstrate it, do not access or modify other customers’ data, and give us a reasonable opportunity to remediate before any public disclosure.

We update this page as our security programme evolves. The date of the most recent revision is shown at the top of the page.

Where a change materially reduces the protections described here, we will notify existing customers in writing (by email and via an in-app notification) at least thirty (30) days before the change takes effect.