A data breach response plan earns its keep in the first seventy-two hours. The organisations that come through an incident well are not the ones that avoided it; they are the ones that could say, within days rather than weeks, exactly what happened, which systems were touched, whose personal information was in them, and whether serious harm was likely. That assessment is the hinge the entire Notifiable Data Breaches scheme turns on. Make it quickly and defensibly, and you notify where notification is required, tell your customers something useful, and get back to work. Make it slowly, from incomplete logs and guesswork, and the incident costs more in legal fees and reputational damage than the intrusion ever did.
What the plan has to produce
Under the Privacy Act, an eligible data breach is unauthorised access to, unauthorised disclosure of, or loss of personal information held by an entity, where a reasonable person would conclude that serious harm to any affected individual is likely, and remedial action has not prevented that harm. The OAIC's guidance on data breaches and the Australian Privacy Act sets out that test. Not every security incident is a breach, and not every breach is notifiable — a laptop lost with full-disk encryption and remote wipe confirmed is a very different proposition from a mailbox accessed for three weeks by someone running forwarding rules.
Where an entity has grounds to suspect an eligible data breach but is not yet certain, the NDB scheme requires a reasonable and expeditious assessment, completed within 30 days of becoming aware of those grounds. Thirty days sounds generous until you have spent eighteen of them trying to work out whether mailbox auditing was switched on. The OAIC also refreshed its quick-reference guide for responding to data breaches on 25 February 2026, which is the single most useful page to print and attach to your plan as an annexe.
So the plan is not a compliance document. It is an instruction set for producing four answers under time pressure:
- What happened, and is it still happening?
- What data was in scope, and in what form?
- Whose data was it, and can we contact them?
- Is serious harm likely, and can remedial action remove that likelihood?
Everything else in the plan exists to make those four answers obtainable.
Named roles, and someone who can actually decide
The most common structural failure is a plan full of actions with no names against them. Write the plan with people, not departments.
- Incident lead. One person who runs the response, keeps the timeline, and is not simultaneously doing the technical remediation. Name a deputy, because incidents happen in January.
- Technical lead. Whoever can read the logs, isolate a device, revoke sessions and reset credentials — internal, your MSP, or both, with the split written down.
- Decision maker. The person with authority to notify, to take a system offline during business hours, to engage external counsel, and to spend money without a procurement cycle. If that is the managing director, say so, and give an after-hours number.
- Privacy and legal contact. Your privacy officer, and the external firm you would call. Agree the engagement in advance; privilege arrangements are easier to set up before the event.
- Communications owner. One voice to customers, staff and media.
Add an escalation path with times attached: who is called at hour one, hour four, and hour twenty-four, and what triggers each step. Include your cyber insurer's notification number and the policy conditions on engaging responders, because many policies restrict who you may use.
The things that must already be running
A response plan is only as good as the evidence available when you open it. These are the dependencies, and they are built in advance or not at all.
Central logging with retention that outlasts a slow discovery. Attackers are often inside an environment for weeks before anyone notices. If your sign-in logs, audit logs and endpoint telemetry roll off before the dwell time, the investigation produces an unresolvable "cannot determine" — and an unresolvable assessment tends to push organisations toward over-notifying, which is expensive and erodes trust. Retention varies by licence tier and tenant configuration, so check what your tenant actually keeps rather than assuming.
Mailbox audit logging. Business email compromise rarely involves malware. The attacker signs in with valid credentials, creates an inbox rule, watches for an invoice and changes the bank details. Without mailbox audit logs you cannot establish which messages were read, and if you cannot establish that, you cannot scope the personal information that was accessed. Alerting on new forwarding rules and anomalous sign-ins belongs in the same category.
An asset and data inventory. You need to know what systems exist, who owns them, and what categories of personal information each one holds — identity documents, health information, financial details, credentials. Serious harm is assessed against the sensitivity of the data, so a data map is not administrative housekeeping, it is the input to the legal test. This is the piece most organisations do not have, and the single biggest cause of slow assessments.
Backups you have restored from. A restore test is the only evidence that a backup works. Backups also need to be protected from the administrator credentials that would be compromised in a ransomware event.
Evidence preservation. Write down the rule now: isolate rather than rebuild, snapshot before you remediate, export logs before retention windows close, and record who did what and when. The instinct to wipe and reimage a compromised laptop at 9am destroys the evidence you need at 9am three days later.
This is the ongoing operational layer, and it is where managed security and compliance work — keeping logging, alerting, backup verification and evidence in order between incidents — does most of its quiet value. ASD's Essential Eight places weight on detection and response capability alongside the preventative controls, and the distinction between owning a tool and operating it is real: ASD reported that only 22 per cent of Commonwealth entities reached Essential Eight Maturity Level 2 or higher in 2025, up from 15 per cent in 2024. Those are well-resourced organisations. The gap is consistency, not budget.
Drafted communications, written while calm
Draft these before the incident, with legal sign-off, and keep them where you can reach them if the network is down:
| Audience | Needs to contain |
|---|---|
| Affected individuals | What happened, what data, what harm is possible, what you are doing, what they should do, how to reach you |
| The OAIC | The statement required under the NDB scheme, filed through the Commissioner's notification form |
| Staff | Plain facts and a single escalation point, so nobody improvises with a customer |
| Key customers and partners | Contractual notification obligations, which often have shorter clocks than the Privacy Act |
| Insurer | Policy number, timeline, and what you have done so far |
Keep a holding statement for the first few hours that is accurate without speculating on scope. Most reputational damage comes from a confident early number that later moves.
Where plans fail
Three failures account for most of the pain. No logs — the data to answer the question was never captured or had already expired. No data map — the technical facts are known but nobody can say which individuals were affected, so the assessment stalls. Nobody empowered — the plan reaches a decision point and waits two days for a board that does not meet until Thursday.
A fourth, quieter failure: the plan exists in a document on a file share that is encrypted along with everything else. Keep an offline copy, and a contact list that does not depend on corporate email.
Testing is the part that proves it
Run the plan as a tabletop exercise against a scenario your business would plausibly face — a finance mailbox compromised for three weeks, or a shared drive encrypted overnight. Walk through it in real time with the real people. You are not testing whether anyone knows the Privacy Act; you are testing whether the logs are there, whether the decision maker can be reached, and whether anyone knows what is in the affected system. Write down what you could not answer, and fix those gaps before the next run.
Start here
Pick your single most sensitive system — the one holding customer identity documents, health records or payment details — and establish three things in writing: what personal information it holds, how long its access logs are retained, and who has authority to take it offline. If you cannot answer all three today, you have found the first gap in your plan, and it is the same gap that would stall an assessment.
If you would rather have the whole picture assessed properly, Precision IT will review your current logging coverage and retention, your data inventory, your backup restore evidence and your escalation structure against what the NDB scheme actually requires, and come back with a scoped remediation plan, a drafted response plan with named roles, and a plain answer on which gaps matter and which do not. Ask for a breach readiness consultation and we will tell you what the work involves and what it costs before you commit to any of it.