Scribe — Data Breach Response Plan
DRAFT for legal review. Items marked [CONFIRM] need a named person or a business decision. Version 1.0 draft · prepared 2026-09-03
Required by the Notifiable Data Breaches (NDB) scheme, Part IIIC of the Privacy Act 1988 (Cth). Scribe handles health information, which is sensitive information — the threshold for "serious harm" is correspondingly low.
This plan is worth nothing unread. It is short on purpose so that it is read.
The clock
30 days. From the moment you suspect an eligible data breach, you have 30 days to complete an assessment. If it is an eligible breach, you must notify the OAIC and affected individuals as soon as practicable — not at day 30.
Start the log at the moment of suspicion, not the moment of confirmation.
Roles
| Role | Who | Responsible for |
|---|---|---|
| Response lead | [CONFIRM] | Runs the response, makes the notification call |
| Technical lead | [CONFIRM] | Contains it, works out scope |
| Communications | [CONFIRM] | Talks to affected pharmacies and patients |
For a business this size these may be the same person. Name them anyway — an unnamed role is one nobody performs.
Step 1 — Contain (immediately)
- Stop the exposure. Disable the account, revoke the session, pull the instance off the network.
- Do not destroy evidence. Preserve logs, disk images, the offending file. You will need them for the assessment and possibly for the OAIC.
- Start the incident log now. Every entry gets a timestamp and a name: what was observed, what was done, what was decided and why.
- Change credentials that may have been exposed.
Step 2 — Assess (within 30 days, faster if you can)
Answer four questions in writing:
- What information? Consultation notes? Transcripts? Patient identifiers, Medicare numbers, medication histories? Pharmacist AHPRA numbers? Booking details? Health information is the aggravating factor — say plainly whether it is involved.
- Whose? How many individuals, at which pharmacies. If you cannot tell, say so — inability to scope is itself a finding, and it pushes toward notifying.
- Who could have accessed it, and is it still exposed?
- Is serious harm likely? Weigh: sensitivity (health information — high), whether it was encrypted or otherwise unreadable, who obtained it, and whether it can still be recovered before harm occurs.
If remedial action prevents serious harm, it is not an eligible breach and you do not have to notify. Record that reasoning — that record is the defence.
Step 3 — Notify (as soon as practicable)
If serious harm is likely:
The OAIC — via the online Notifiable Data Breach form at oaic.gov.au. State: your details, what happened, the kinds of information involved, and what affected individuals should do.
Affected individuals — directly if practicable. Patient contact details are usually held by the pharmacy, not by you, so in practice this runs through the pharmacy. Agree in advance, in your customer contract, who notifies patients and how fast. [CONFIRM]
Affected pharmacies — always, immediately, whether or not the breach is eligible. They have their own obligations to their patients and cannot meet them if you tell them late.
Also consider: cyber insurer (notify early — late notice can void cover), the Australian Cyber Security Centre if criminal, police if theft, and the Pharmacy Board if a practitioner's registration details were exposed.
What the notice must say
- What happened and when
- What information was involved
- What you have done about it
- What the person should do — the part that actually helps
- How to contact you and how to complain to the OAIC
Write it in plain language. A patient reading it is not a security professional.
Step 4 — Review
Within 30 days of closing the incident, write down:
- Root cause. Not "human error" — what made the error possible and what would have caught it.
- What is changing: code, configuration, process, training.
- Whether the same class of failure exists anywhere else in the product.
Scribe's own engineering habit already fits this: every fixed defect gets a written note explaining the failure it prevents. Breaches get the same treatment.
Breach scenarios specific to Scribe
Worth thinking through before one happens.
| Scenario | Likely severity | First move |
|---|---|---|
| Consult-room PC stolen or lost | High — local consults.db holds notes and identifiers | Was the disk encrypted? If yes, harm is probably prevented. If no, treat as eligible. |
| Cross-tenant leak — one pharmacy reading another's records | High | Contain, then determine which pairs of pharmacies. The store-scoping and podium_store_id uniqueness guards exist to prevent exactly this. |
| Pharmacist account left active after they leave | Medium | Deactivate; check what was accessed since departure |
| Hosted instance exposed to the internet without auth | High | Take it offline first, ask questions second |
| Cloud language model provider breached | Medium–high | Only affects pharmacies that enabled it; identify which, notify them |
| Export written to a shared drive | Medium | Common and mundane — the most likely real incident |
| Backup media lost | Depends on encryption | Encrypted backups make this a non-event; that is why they are encrypted |
Test this
Run a tabletop exercise annually: pick a scenario above, walk the four steps, time yourself. [CONFIRM — who schedules it]
An untested plan fails on the day it is needed, and the day it is needed is the day everyone is already panicking.
Register. Keep a log of every breach and suspected breach, including those assessed as not eligible, with the reasoning. The OAIC may ask, and "we assessed it and here is why we concluded no serious harm" is a complete answer. "We didn't write it down" is not.