AUSTRALIAN PRIVACY ACT 1988 (CTH) PART IIIC · OAIC NDB SCHEME · RACGP 5TH ED. C6.4

Data Breach Response Plan (OAIC NDB Scheme) — DIAGNIFY.AI

Version 1.0 (Go-Live Release) · Effective Date: 26/10/2026 · Next Scheduled 6-Monthly Drill: 26/04/2027

Seller / Platform Operator: Arundhati Health Services Pty Ltd trading as DIAGNIFY.AI · 18 Springfield Lakes Boulevard, Springfield Lakes QLD 4300, Australia · D-U-N-S® 890136315 · Incident Commander & Privacy Officer: Dr Dushyant Singh (clinical@diagnify.ai)

← Diagnify OS (/practice) 1. Privacy Policy (APP 1–13) 2. Data Breach Plan (OAIC NDB) 3. Terms of Service (Seller to User) 4. Seller-to-Clinic DPA (Schedule A) 5. Patient Privacy & AI Consent (1.3)

Executive Summary — 4-Step OAIC Notifiable Data Breaches Protocol

Diagnify maintains and tests a formal Data Breach Response Plan (ops/compliance/DATA_BREACH_RESPONSE_PLAN.md) under Part IIIC of the Privacy Act 1988 (Cth), the OAIC Data Breach Preparation and Response Guide, s 75 of the My Health Records Act 2012 (Cth), and RACGP 5th Edition Criterion C6.4:

  • Step 1 — Contain & Preserve Forensic Evidence (Hours 0 to 4): We immediately isolate and contain any suspected unauthorised access, disclosure, or loss (locking compromised accounts via AUTH_LOCKOUT, revoking active sessions/devices, revoking leaked patient triage tokens via /triage_revoke, or rotating API/database credentials) without destroying forensic evidence. We snapshot the affected host and archive our append-only, hash-chained security ledger (emr_core.audit_events, public.chart_access_log, and public.patient_audit).
  • Step 2 — Assess Within 30 Calendar Days (Target < 72 Hours, s 26WH & s 26WG): Our Incident Commander & Privacy Officer conducts a formal written NDB Assessment to determine: (a) what occurred and which patient/practice records were touched; (b) whether data was protected by AES-256 encryption without key exposure; (c) whether prompt remedial action under s 26WF (such as verified unread destruction by a bound healthcare recipient) has eliminated any likelihood of serious harm; and (d) whether a reasonable person would conclude that the breach is likely to result in serious harm to any individual.
  • Step 3 — Mandatory Notification (s 26WJ, s 26WK & s 26WL):
    • Affected Medical Practice Notification (Within 24 Hours): We notify the Practice Owner of any affected <practice>.diagnify.ai tenant within 24 hours of discovery so the Practice can alert its Medical Defence Organisation (Avant / MIPS / MDA National / MIGA) and coordinate joint response under s 26WJ.
    • OAIC & Affected Individuals Notification: Where an Eligible Data Breach is confirmed, we lodge a formal statement via the OAIC Notifiable Data Breaches Portal (oaic.gov.au · 1300 363 992) and notify affected individuals directly with clear protective recommendations (including Medicare card replacement on 132 011 and free national identity support via IDCARE on 1800 595 160).
    • ADHA Notification (My Health Record / HI Service): If My Health Record data or NASH PKI credentials are involved, we notify the ADHA System Operator (1300 901 001) and the OAIC as soon as practicable under s 75 of the My Health Records Act 2012.
  • Step 4 — Post-Mortem, Engineering Prevention & Breach Register (Within 14 Days): We ship permanent engineering guards through our automated release train, record every incident and near-miss (including s 26WF remediated incidents) in our Internal Data Breach Register, and run 6-monthly tabletop and restore drills.

1. Purpose and Regulatory Mandate

Because Diagnify EMR processes sensitive health information for Australian medical practices, any unauthorised access, unauthorised disclosure, or loss of data where unauthorised access or disclosure is likely carries a high risk of serious harm (physical, psychological, emotional, financial, or reputational harm) to patients and clinicians.

Under Part IIIC of the Privacy Act 1988 (Cth) (the Notifiable Data Breaches or NDB Scheme):

  1. Strict 30-Day Assessment Clock (s 26WH): Once Diagnify becomes aware of reasonable grounds to suspect an Eligible Data Breach may have occurred, we must take all reasonable steps to complete an assessment as soon as practicable and within 30 calendar days.
  2. Mandatory Notification (s 26WK & s 26WL): As soon as practicable after determining that an Eligible Data Breach has occurred (unless remedial action under s 26WF has completely prevented any likelihood of serious harm), we must notify the Office of the Australian Information Commissioner (OAIC) and affected individuals.
  3. Joint Holding with Medical Practices (s 26WJ): Where patient records are held jointly by the treating Medical Practice (Controller/Custodian) and Diagnify (Cloud EMR Processor), compliance by one entity satisfies the NDB notification requirement for both, provided we coordinate immediately so neither party drops the ball.
  4. My Health Record Incidents (My Health Records Act 2012 s 75): Where Diagnify's My Health Record (MHR) B2B adapter is active, any actual or potential breach involving MHR system credentials (NASH PKI) or MHR data must be reported to the Australian Digital Health Agency (ADHA) System Operator and the OAIC as soon as practicable.

2. Incident Response Team & Emergency Contacts

Role Designated Person / Entity Responsibilities Contact Details
Incident Commander & Privacy Officer Dr Dushyant Singh (CEO & Director, Arundhati Health Services Pty Ltd) Declares incident severity; starts the 30-day NDB clock; approves clinic, OAIC, and patient notifications; coordinates legal/insurer advice. clinical@diagnify.ai
Technical & Infrastructure Lead Diagnify DevOps / On-Call Lead Executes Step 1 Containment on Vultr Sydney and Supabase (ap-southeast-2); preserves forensic logs; rotates keys. Vultr Sydney / Supabase Console
Affected Clinic Liaison Practice Owner / Practice Manager of the affected <slug>.diagnify.ai tenant Reviews patient clinical impact; coordinates patient notifications and Medical Defence Organisation (MDO) notice. Looked up via emr_organisation_admin.clinic_onboardings
Regulators & National Cyber Support OAIC · ACSC · ADHA · IDCARE Regulatory reporting, cyber incident triage & patient identity support. OAIC: 1300 363 992 (oaic.gov.au)
ACSC: 1300 292 371
ADHA: 1300 901 001
IDCARE: 1800 595 160

3. Severity Matrix & Escalation Triggers

Severity Examples in Diagnify EMR Target Containment Notify Clinic Owner OAIC NDB Clock
SEV-1 (Critical / Multi-Patient Breach) Compromised database credentials or service-role JWT; unauthorised cross-tenant read; host compromise; leaked unencrypted patient dump. Immediate (< 1 hour) Within 24 hours Starts immediately (Day 0 of 30)
SEV-2 (Single-Patient or Single-Account Incident) Compromised clinician login; misdirected email/SMS/referral containing identifiable patient health data; stolen unlocked clinic workstation. < 4 hours Within 24 hours Starts immediately (Assess s 26WF remediation)
SEV-3 (Near-Miss / Blocked Attempt) Repeated failed sign-ins blocked by AUTH_LOCKOUT; unauthorized API call blocked 403 by sidecar security audit. < 24 hours Log in Practice Audit tab Record in Internal Breach Register

4. Detailed 4-Step Response Protocol

Step 1 — Contain & Preserve Forensic Evidence (Hours 0 to 4)

Critical Forensic Rule: Never wipe logs, never drop database tables, and never destroy forensic evidence. Snapshot before mutating.

  • 1A. Preserve Forensic Evidence First: Take an immediate Vultr VPS snapshot of the Sydney host and export immutable hash-chained audit trails (emr_core.audit_events, public.chart_access_log, public.patient_audit, local spools, and nginx/systemd logs) into an isolated root archive.
  • 1B. Targeted Containment by Vector:
    • Vector A (Compromised Clinician/Staff Account): Deactivate membership via workforce-rbac, trigger AUTH_LOCKOUT, revoke public.user_devices and auth.sessions, and force password + TOTP MFA reset.
    • Vector B (Leaked Patient Intake/Triage Link): Revoke hashed patient token immediately via POST /triage_revoke or set case_state.revoked = true.
    • Vector C (Misdirected Email/Referral/PDF): Contact unintended recipient immediately to obtain written confirmation of unread deletion under s 26WF; verify AES-256 protection status (DOC_PDF_PROTECT).
    • Vector D (Compromised API/Sub-Processor/DB Key): Rotate affected provider or database credentials immediately and restart isolated service units.
    • Vector E (Active Host Intrusion/Endpoint Vulnerability): Block offending IP/route at the gateway and restrict firewall access.

Step 2 — Assess (Days 1 to 30 Maximum · Target < 72 Hours · s 26WG & s 26WF)

  1. What happened? Identify whether there was unauthorised access, unauthorised disclosure, or loss of personal/health information.
  2. Whose data and what fields were involved? Query public.chart_access_log and emr_core.audit_events to list affected practices (organisation_id) and patient records (patient_id).
  3. Has Remedial Action Eliminated Serious Harm (s 26WF)? Determine whether verified unread deletion by a bound healthcare recipient or unbroken AES-256 encryption eliminated any likelihood of serious harm prior to exposure.
  4. Is Serious Harm Likely (s 26WG)? Any unencrypted exposure of identifiable clinical notes, diagnoses, prescriptions, or Medicare/IHI details outside a trusted healthcare setting is treated as an Eligible Data Breach.

Step 3 — Mandatory Notification (s 26WJ, s 26WK & s 26WL)

  • Step 3A — Notify Affected Medical Practice Owner (Within 24 Hours): Deliver formal incident notice with containment status, exact records/fields affected, and coordinated s 26WJ OAIC/patient notification plan.
  • Step 3B — Notify the OAIC (s 26WK) & ADHA (s 75): Lodge formal statement via the OAIC Notifiable Data Breaches Portal (oaic.gov.au · 1300 363 992) and, where My Health Record / HI Service is involved, notify the ADHA System Operator (1300 901 001).
  • Step 3C — Notify Affected Individuals (s 26WL): Notify affected patients/clinicians directly with actionable protective steps (Services Australia Medicare replacement on 132 011 and IDCARE support on 1800 595 160).

Step 4 — Review, Engineering Prevention & Breach Register (Within 14 Days)

  • Conduct blameless technical and clinical root-cause post-mortem.
  • Ship permanent engineering guard + automated regression test through the Diagnify release train.
  • Record complete incident timeline, s 26WG assessment, and OAIC reference in the Internal Data Breach & Near-Miss Register, tested every 6 months alongside day1-clinic-restore-drill.timer.

Contact & Regulatory Reporting

DIAGNIFY.AI — Arundhati Health Services Pty Ltd
18 Springfield Lakes Boulevard, Springfield Lakes QLD 4300, Australia · D-U-N-S® 890136315
Incident Commander & Privacy Officer: clinical@diagnify.ai · OAIC NDB Line: 1300 363 992 (oaic.gov.au)