Writing a data breach response plan: roles, the assessment clock and the notification decision

Why the plan is the control, not the policy

A data breach response plan is the operational document that turns the Notifiable Data Breaches obligations in Part IIIC of the Privacy Act 1988 into named people, timed steps and a decision record. A privacy policy tells the public how you handle personal information; the response plan tells your own staff what happens in the ninety minutes after someone reports a lost laptop.

The Office of the Australian Information Commissioner sets out the elements it expects in Part 2 of its data breach guidance: a clear explanation of what constitutes a data breach, a strategy for containing, assessing and managing breaches, the roles and responsibilities of staff, how the entity will record data breach incidents, and a strategy to identify weaknesses and assess the effectiveness of the response.

Having such a plan is also how an entity evidences the practices, procedures and systems obligation in APP 1.2 and the security obligation in APP 11. A regulator assessing a breach response looks first for whether a plan existed before the incident, and second for whether the incident was handled the way the plan said it would be.

The roles the plan must name

The OAIC is explicit that the plan should carry "a current list of response team members and clearly detail their roles, responsibilities, and authorities, as well as their contact details", that "each role on the response team should have a second point of contact in case the first person is not available", and that team members need clear escalation procedures and reporting lines for suspected breaches.

At minimum, name a role for each of these functions and a backup for each:

Two design choices separate a plan that works from one that stalls. First, the response lead must be able to declare an incident without an executive present — a plan that requires a chief executive to convene the team loses a day to calendars. Second, the escalation path must start from wherever a breach is actually discovered, which is usually a service desk or a customer-facing team, not the privacy officer. Write the first hop from the front line, not from the top.

Containment and the first working day

The OAIC frames the response as four steps: contain, assess, notify, review. Containment comes first because it is the step that can remove the obligation entirely — section 26WF of the Privacy Act provides an exception where remedial action means the breach would not be likely to result in serious harm.

Practical containment on day one covers revoking the credential or access path, isolating the affected system, recalling or remotely wiping the device, requesting deletion and confirmation of deletion where information was sent to the wrong recipient, and preserving logs before any rebuild. Preserve first, remediate second: rebuilding a compromised host before imaging it destroys the evidence you need to scope the breach, and an unscoped breach cannot be assessed.

Record the containment steps as they happen. The incident and breach register entry created on day one is what later proves when awareness began — and awareness is what starts the clock.

The 30-day assessment clock

Where an entity has reasonable grounds to suspect an eligible data breach but not yet to believe one has occurred, section 26WH requires it to carry out a reasonable and expeditious assessment and to take all reasonable steps to complete that assessment within 30 days. The OAIC confirms in its quick reference guide that the entity "must take all reasonable steps to complete this assessment within 30 calendar days after the day you become aware of the grounds/information that caused you to suspect an eligible data breach" (checked August 2026).

Thirty calendar days is a ceiling, not a target. Two features of the section are routinely misread. It runs on calendar days, not business days, so a breach discovered before a long weekend loses the same days as any other. And it starts from suspicion, not from confirmation — an entity that delays forming a suspicion in order to delay the clock has not stopped it running.

The plan should therefore fix a shorter internal deadline, assign the assessment to a named role, and require a written assessment record whatever the outcome. The NDB timer converts an awareness date into the statutory deadline; the assessment record is what justifies the answer you reached.

The notification decision

An eligible data breach arises where there is unauthorised access to, or unauthorised disclosure of, personal information the entity holds, or a loss of that information, and a reasonable person would conclude it would be likely to result in serious harm to any of the individuals to whom the information relates, and remedial action has not removed that likelihood.

Once there are reasonable grounds to believe an eligible data breach has occurred, the entity must prepare a statement and give a copy to the Commissioner as soon as practicable. Section 26WK(3) fixes the content: the identity and contact details of the entity, a description of the eligible data breach, the particular kind or kinds of information concerned, and recommendations about the steps individuals should take in response. The eligible data breach statement walkthrough covers the drafting.

Notification to individuals under section 26WL follows a strict order of preference, and this is the part plans most often get wrong. The three options are not equivalent choices. The entity must notify each of the individuals to whom the relevant information relates; or, if that is not practicable, notify only those individuals at risk of serious harm; and only if neither of those is practicable may it publish the statement on its website and take reasonable steps to publicise its contents. Website publication is a fallback, not a convenience. A plan that lists the three as alternatives will produce a defective notification.

Where the incident also touches critical infrastructure, government systems or a ransomware payment, separate reporting duties run in parallel on much shorter clocks. Run the cyber incident notifications decision tree alongside the privacy assessment rather than after it.

Testing the plan before you need it

The OAIC's guidance directs entities to "regularly review and test your plan to make sure it is up to date and that your staff know what actions they are expected to take."

A useful test is narrow. Take a realistic scenario — a misdirected bulk email containing client records, a stolen laptop, a compromised supplier account — and run it against the plan with the actual named people, on the actual contact details in the document. The failures a tabletop exercise surfaces are almost always structural rather than intellectual: the after-hours number belongs to someone who left, nobody can reach the executive decision-maker, the forensic provider has no engagement in place so procurement becomes the bottleneck, or the service desk has no script for escalating a suspected breach.

Fix those in the document, date the version, and record that the test occurred. The test record is itself APP 1.2 evidence.

Review, and what non-compliance now costs

The fourth step is the one skipped most often. Review asks what allowed the breach, whether the response worked, and what changes — technical, contractual or procedural — follow. Where the breach involved a new or changed way of handling personal information, that review is often the point at which a privacy impact assessment should have been run.

The enforcement backdrop has sharpened. A serious interference with privacy under section 13G carries a maximum civil penalty for a body corporate of the greater of $50 million, three times the value of the benefit obtained, or 30% of adjusted turnover during the breach turnover period, and $2.5 million for an individual (checked August 2026 against the OAIC's civil penalties guidance). The Privacy and Other Legislation Amendment Act 2024 removed the "repeated" element from section 13G and added a mid-tier civil penalty in section 13H for interferences that do not meet the serious threshold, plus a lower-tier provision in section 13K supported by infringement notice powers. The penalty-unit amounts for sections 13H and 13K are widely reported but should be read from the Act itself, because the Commonwealth penalty unit rose to $364 on 1 July 2026 and every dollar conversion published before that date is stale.

Volume is rising with it. The OAIC recorded 1,205 data breach notifications in the 2025 calendar year, an 8% increase on 2024 and the highest since the scheme began, with malicious or criminal attack the source of 716 of them. Test the plan on that basis.