What Your Data Breach Response Plan Has to Prove, and the 72-Hour Clock Coming With It

Some organisations I audit have a data breach response plan. Very few can show me it has ever been used, tested or reviewed. It exists as a document, usually written when the information security policy was written, naming a response team that has changed since and a decision-maker who has left.

That has been a quiet weakness for years. The exposure draft of Australia’s next round of privacy reform, released on 31 August 2026, would make it an explicit one. Consultation on that draft closed on 18 September 2026 and it is not law, but it is worth reading now for what it says about evidence, because the answer to “do you have a plan” is about to stop being yes or no.

What a data breach response plan has to prove

Strip away the format and a response plan is answering four questions, and each one is answered with a record rather than a paragraph.

• Who decides, and when. Not who is on the team. Who declares that this is an incident, at what point, and what they are authorised to do without asking anyone. If that person is unavailable at 6pm on a Friday, who decides instead.
• What the clock is, and when it started. The single most valuable line in an incident record is the timestamp on which somebody first suspected something, and the separate timestamp on which suspicion became belief. Almost nobody records the first one.
• What you did to contain it. Disabling accounts, cutting access, telling a supplier to stop processing, telling affected people what to do. Actions with times against them.
• That the plan works when it is used. A plan that has never been run is a hypothesis. The only evidence that it works is a record of it being exercised, and the changes you made afterwards.

The fourth is the one that separates organisations at audit. When I ask for the last time the plan was tested, the good answer is a tabletop exercise record with a date, a scenario, who attended, what broke and what was changed as a result. The common answer is that the plan is on the intranet.

The exposure draft, and what it would add

Dated 31 August 2026. The Attorney-General’s Department released an Exposure Draft of the Privacy Amendment (Personal Data Protection) Bill 2026 and a Consultation Paper. Submissions closed on Friday 18 September 2026. The department states plainly that the Bill “remains subject to further consideration by government”, so what follows is a proposal, not a requirement. The quotations below are from the Consultation Paper.

Two clocks, not one

This is the part most summaries get muddled. The draft does not replace the existing timeframe. It adds a second one.

The 30 day window to assess a suspected eligible data breach is retained. What is added is a requirement to give the Commissioner a statement within 72 hours “of becoming aware of reasonable grounds to believe that an eligible data breach has occurred”. The paper aligns that expressly with the timeframes in the SOCI Act and the Cyber Security Act 2024. If you cannot complete the statement in time, the draft would let you provide an incomplete one, with written notice of what is missing and why, then update it as soon as practicable. Failing to provide anything within 72 hours “may result in an infringement notice or compliance notice”.

So the sequence would be: suspicion starts a 30 day assessment, and the moment that assessment produces reasonable grounds to believe, a 72 hour clock starts. We looked at how much work the word “potential” does in that first stage when Origin Energy described an incident as potential, and that distinction becomes considerably more expensive if the second clock arrives.

The plan itself becomes an obligation

The draft would separately define a “data breach”, so that obligations “to manage and contain a data breach may apply even if the serious harm threshold for an eligible data breach is not met”. Underneath that, entities “would expressly be required to take reasonable steps to implement practices, procedures and systems that enable them to respond effectively to data breaches”.

The obligation is deliberately non-prescriptive and scaled to an organisation’s “size, resources, and the nature of the personal information it handles”. But the paper gives its own example of what meeting it looks like: “maintaining, regularly reviewing and testing a data breach response plan”. Failure would be an interference with privacy. There is also a positive, ongoing duty to mitigate harm as soon as practicable after becoming aware of reasonable grounds to believe or suspect a breach has occurred.

Knowing what personal information you hold

The draft would require an entity to “take any steps needed to ensure it is able to identify personal information to which APP 11.1 and 11.2 apply”, on the straightforward reasoning that it “must know what personal information it holds in order to protect that information appropriately”. It would also require you to consider whether to destroy personal information no longer needed, then destroy or de-identify it.

This is the same failure we described in software supply chain security, wearing different clothes. Most organisations have an asset register that stops at things with a purchase price. Personal information sits in mailboxes, shared drives, form submissions, an old CRM nobody logs into, and a spreadsheet somebody exported in 2021.

Assessing whether your security is working

The provision with the longest tail is short to state. Under the draft, “an entity must regularly assess the effectiveness of its compliance with APP 11”, including the reasonable steps it has taken and whether information it de-identified has stayed de-identified.

Read that as an auditor and it is a requirement for monitoring, internal audit and management review. It is the one obligation in the package that a policy-only privacy program produces nothing for. You cannot answer it with a document. You answer it with a dated assessment that found something and changed something. The current APP 11.3 is not lost in the reshuffle: the paper indicates a new APP 11.4(a) preserves it, so the numbering moves. Our guide to securing personal information under APP 11 covers the existing obligation.

If your IT provider holds the data

The draft introduces a controller and processor split. A processor acting within documented instructions is treated as the controller acting, and processors “remain directly responsible for complying with APP 1 and APP 11”. Step outside those instructions and the processor carries it alone.

Note what this does not do. It does not move the notification off you. If a provider is breached and your customers’ information is involved, the statement to the Commissioner is still yours to make, which is the argument we made when a supplier lost the data and the notification stayed with the client. What the split adds is a reason to write the instructions down, because “documented instructions” is doing real work in that sentence. If you have never asked your IT provider what happens on their side when something goes wrong, that is the conversation to have.

The decision point that starts the 72-hour clock

If the 72 hour rule arrives in something like its current form, the practical work is not the notification. It is knowing when the clock started.

The trigger would be “reasonable grounds to believe”, which is a judgement someone has to make and record. In most incident procedures I read, there is no such moment. There is a report, then some investigation, then at some point everyone agrees it is serious. Reconstructed afterwards, that becomes an argument about when you should have known, and it is not an argument you want to be having with a regulator using your own records.

The fix is unglamorous. Name the decision in the procedure, name who makes it, and require it to be written down with a time when it is made. One line in a log. It costs nothing now and it is the difference between demonstrating you met a deadline and hoping you did.

A worked example arrived on 3 September 2026. Mathspace found an intrusion in historical access logs, confirmed that day that data on 1,079,819 people had been taken, and notified the OAIC and the ACSC the following day. One day, against a proposed 72 hours, with the moment belief was formed set out in the company’s own published disclosure. That is what this clock looks like when the decision point is clear, and it is the first clean Australian example of it. How the breach happened, and why the 23 days before it were the real failure, is in the patch was published on 6 August.

Update, 18 September 2026: for some Australian businesses a tighter clock is already running. If you make software or connected hardware and sell it into the European Union, the EU Cyber Resilience Act reporting obligations commenced on 11 September 2026. A manufacturer placing a product with digital elements on the EU market must give ENISA an early warning within 24 hours of becoming aware of an actively exploited vulnerability, a full notification within 72 hours, and a final report no later than 14 days after a corrective measure is available.

It applies wherever the manufacturer is headquartered. Whether it applies to you depends on the product and your role as manufacturer, importer or distributor: free and open source software is generally only in scope when it is supplied in the course of a commercial activity, and open source stewards have a separate, lighter regime. Severe incidents affecting a product’s security have their own notification timeline alongside the vulnerability one.

The full Regulation (EU) 2024/2847 applies from December 2027. Two things follow. Twenty four hours is not twenty four business hours, so the decision to declare has to be reachable on a Saturday, which is a roster question rather than a policy one. And your Annex A 5.24 to 5.27 incident process has to know which of your products are in scope, which is an asset register question before it is an incident one.

Not every clock is a notification clock. Publicly trusted TLS certificates are capped at 200 days today, 100 days from March 2027 and 47 days from March 2029, and an expired one is an availability incident rather than a disclosure. It is answered from the same asset register, and we set out what it asks for in TLS certificates drop to 100 days in March 2027.

Where ISO 27001 already produces the evidence

None of this is new ground for a working ISO 27001 information security management system. That is worth saying carefully: certification would not make you compliant with the Privacy Act, and no certificate does. What a management system does is produce, as a matter of routine, the records these obligations ask for.

• The plan, and testing it. Annex A 5.24 covers incident management planning and preparation, 5.26 the response itself, and 5.27 learning from incidents. The tested-plan evidence is the exercise record and what changed after it.
• Knowing what you hold. Annex A 5.9, the inventory of information and other associated assets. Built properly it covers information, not just equipment.
• Supplier instructions. Annex A 5.20, addressing information security within supplier agreements. This is where “documented instructions” would live.
• Regularly assessing effectiveness. Clause 9.1 monitoring and measurement, clause 9.2 internal audit, clause 9.3 management review. Three clauses that exist to answer exactly the question the draft asks.

The reason the overlap is so close is not a coincidence. The draft is non-prescriptive by design, which means it is asking organisations to demonstrate that what they do works. That is what a management system is for.

What to do now

1. Find your response plan and read it. Check the names and phone numbers in it are current, and that the decision-maker still works there.
2. Add the decision point. One named role, one recorded time, for the moment suspicion becomes belief.
3. Run a tabletop. Two hours, one realistic scenario, minutes taken. If you do one thing on this list, do this one, because it is the evidence nothing else produces.
4. Ask where the personal information is. Not the systems you license, the places it ends up.
5. Ask your IT provider what their side looks like, and write down what you are instructing them to do.
6. Watch for what comes back. Consultation closed on 18 September 2026. The department has said the Bill remains subject to further consideration by government, so the next milestone is introduction rather than another round of comment. Nothing else on this list depends on that timing.

Where Streamline fits

You work directly with a qualified ISO Lead Auditor who spends most of his time on the other side of the audit table, testing whether incident procedures hold up when they are sampled. If you already hold ISO 27001, an independent internal audit under clause 9.2 scoped to the incident procedure is the cheapest way to find out what your evidence looks like before anyone else asks. If you are not certified, a gap analysis tells you where you stand.

For most Australian small and medium organisations, ISO 27001 certification takes three to six months and a first-year investment of roughly $15,000 to $30,000. Our ISO 27001 certification cost guide works through the breakdown.

Common questions

Is the 72-hour data breach notification rule law?

No. It appears in an exposure draft released on 31 August 2026. Consultation on that draft closed on 18 September 2026, and the Attorney-General’s Department states the Bill remains subject to further consideration by government. The current obligations, including the 30 day assessment window, continue to apply until any change commences.

What is a data breach response plan?

A documented procedure setting out how your organisation identifies, contains, assesses and reports a data breach: who decides it is an incident, who does what, how affected people and regulators are told, and how the response is recorded. Under the exposure draft, maintaining, regularly reviewing and testing one is given as an example of meeting the proposed obligation.

How often should a data breach response plan be tested?

There is no prescribed frequency. Annually is a reasonable baseline for most organisations, with an additional exercise after any significant change to your systems, suppliers or response team. What matters more than the interval is that the test is recorded and that something changed as a result.

Does ISO 27001 certification make us compliant with the Privacy Act?

No. Certification confirms that your information security management system conforms to the standard. It does not discharge a legal obligation and no certification body assesses your compliance with the Privacy Act. What it does is produce the dated records of assessment, testing and review that the privacy obligations increasingly ask you to evidence.

If our IT provider is breached, who notifies?

On current law, the entity that holds the information is responsible for notifying. The exposure draft would introduce a controller and processor split under which processors remain directly responsible for APP 1 and APP 11, but it does not move the notification obligation away from the controller.

Speak with an experienced ISO auditor

If you want to know what your incident evidence looks like before a regulator or a customer asks, get in touch. Email hello@streamline.business or call Brisbane 07 3667 8280, Sydney 02 8315 7780 or Melbourne 03 9034 3990.

General information only, current at 21 September 2026, and not legal advice. Consultation on the exposure draft has closed and the draft may still change before any Bill is introduced. Streamline ISO Consultants are ISO management system consultants, not lawyers. See our Disclaimer.

Sources

• Attorney-General’s Department: Exposure Draft, Privacy Amendment (Personal Data Protection)
• Cyber Daily: EU Cyber Resilience Act reporting obligations
• EUR-Lex: Regulation (EU) 2024/2847 (Cyber Resilience Act)

Published 3 September 2026 | Facts checked 16 October 2026 | Next review December 2026 | Jurisdiction: Australia (Commonwealth), with the EU Cyber Resilience Act noted | Edition: ISO/IEC 27001:2022