The Privacy Act does not use the words 'breach response plan', but the Notifiable Data Breaches scheme and APP 11 require you to assess suspected breaches quickly, notify when serious harm is likely, and protect personal information. A tested plan is how most organisations meet those duties under pressure. We suggest getting advice for your situation.
Most boards and executives want one thing after a data incident: to show that the organisation acted quickly, made reasoned decisions and told the right people on time. A plan is what makes that possible, and the question is really whether you can afford to improvise.
What the Privacy Act actually requires
The Privacy Act 1988 does not contain a line saying every organisation must hold a documented data breach response plan. What it does contain is Part IIIC, the Notifiable Data Breaches (NDB) scheme, and Australian Privacy Principle 11, which requires reasonable steps to protect personal information. Together they create duties that are very hard to meet without a plan.
Under the NDB scheme, an organisation covered by the Act that suspects an eligible data breach must assess it, and notify the OAIC and affected individuals if serious harm is likely. The assessment must be done promptly, and the scheme sets a 30-day window for completing it. Each of those steps needs someone to own it, a way to escalate, and a record of the decision.
So the honest answer is this. The law does not name the document, but the obligations it creates are the contents of the document. An organisation without a plan is still bound by the duties. It simply has to work out who does what while the clock is running.
This article explains what typically applies and what organisations usually do. It is not legal advice, and you should get advice on your own circumstances, especially if you operate in a regulated sector or hold health, financial or children's information.
Why regulators and courts treat slow response as its own failure
The clearest Australian example is the Federal Court outcome involving Australian Clinical Labs and the Medlab Pathology breach. The court ordered $5.8m in penalties, made up of $4.2m for failing to protect data, $800k for inadequate breach assessment and $800k for failing to notify promptly [4].
The useful lesson is the structure. Protection, assessment and notification were each penalised separately [4]. A strong technical response does not cancel out a slow or poorly reasoned assessment, and a good assessment does not excuse late notification. A plan is the tool that keeps all three on track.
There is also a growing litigation dimension. Individuals can now sue directly for serious invasions of privacy, including against small businesses that sit outside the APPs [1]. That sits on top of OAIC enforcement, so how you respond to an incident can matter in a courtroom as well as in front of the regulator.
The regulator is also paying attention to how organisations handle information more broadly. The OAIC's 2025-26 priorities target power and information imbalances, privacy in emerging technology such as biometrics and location tracking, and information governance in the public service [3]. A breach tends to put all of those practices under a spotlight at once.
Who is most likely to need one
If you are covered by the Privacy Act, you have NDB duties and should plan for them. Coverage usually turns on turnover and the type of information you handle, so check your position with an adviser. Some smaller organisations are covered regardless of turnover, for example health service providers.
Sector rules can add to the baseline. Queensland government agencies now operate under a mandatory notification of data breach scheme as part of the IPOLA reforms, alongside a single set of Queensland Privacy Principles [2]. NDIS providers are being brought under the NDIS Commission's Practice Standards, which include information management and privacy, with transitional arrangements applying [5]. If you serve government or work in a regulated sector, expect your clients, funders or regulator to ask what your plan looks like.
Many organisations also face contractual pressure. Cyber insurers, major customers and government buyers increasingly ask for evidence of a tested response plan, and supplier contracts often contain their own notification clauses. A plan lets you answer those questions with a document rather than a promise.
What a workable plan contains
A plan is only useful if people can follow it at 2am on a Saturday. Length is not the test. The OAIC's guidance structures the response around four steps: contain, assess, notify and review. A good plan is built around those steps and answers a handful of practical questions.
Who is on the response team, and who are their deputies? A contact tree that names one person for each role fails the first time that person is on leave.
Who can declare an incident, and who decides whether to notify? Decision rights need to be explicit, including when to involve legal counsel, communications and the executive.
How do we assess serious harm? The plan should set out the criteria, what information to gather and where the decision is recorded. A decision log matters because it shows the assessment was reasoned and prompt.
What do we say, and to whom? Templates for the OAIC statement and for notices to individuals save hours when time is short.
What do suppliers owe us, and what do we owe them? Many breaches start with a third party. The plan should reflect the notification clauses in your key supplier contracts.
What happens afterwards? Review closes the loop: what failed, what to change, and what goes in the breach register.
Ransomware changes the plan
Ransomware adds a separate legal clock. The Cyber Security Act 2024 introduced ransomware payment reporting, and TFIQ's plans build in the 72-hour reporting obligation that applies where a payment is made. If your plan was written before those rules, it likely does not mention it.
This is a good example of why plans date quickly. A plan that covers privacy notification but ignores ransomware payment reporting leaves an executive team discovering a second obligation in the middle of an extortion event. Designing it in beforehand is far cheaper than remembering it on the day.
It is also worth checking whether your plan treats ransomware as a purely technical event. The decisions that carry the most risk, such as whether to engage with an attacker, who authorises a payment and what you tell customers, are executive decisions. They belong in the plan and in the exercise that tests it.
Why testing matters as much as writing
A plan that has never been used is a hypothesis. The usual failure points are not in the document. They are in the handoffs: IT does not know when to call legal, communications waits for approval that nobody is empowered to give, or the executive assumes someone else owns the notification decision.
A facilitated tabletop exercise puts the executive team through a realistic scenario with timed injects, such as a customer complaint, a media enquiry or a supplier admitting a compromise. It tests whether the 30-day assessment and any ransomware reporting deadline are workable in practice. It also shows which decisions people are uncomfortable making, which is exactly what you want to learn before a real event.
The output should be an after-action record of what worked and what did not, with the plan updated before it is finalised. That record also gives the board something concrete to oversee, rather than a general assurance that the organisation is prepared.
Common challenges, framed as questions
If you are unsure where you stand, these questions help.
Is the person responsible for privacy doing it on the side? An accidental privacy officer often owns breach response without time, authority or a rehearsed process. A plan with clear roles and deputies takes pressure off that one person.
Do we have an inventory of what personal information we hold and where? Without one, scoping an incident takes much longer, because you cannot quickly say whose information is involved. Data mapping and an information asset register make assessment faster.
Is our security and incident tooling fragmented? Several tools and teams can mean nobody holds the full picture. The plan should say who pulls it together.
Does our plan predate recent rules? If it was written before ransomware payment reporting, or before your supplier arrangements changed, it needs review.
Has our executive ever practised a decision? Reading a plan is not the same as making a call with incomplete information.
A practical first step
If you have no plan, or one that has not been tested, the first step is a short, fixed-scope piece of work rather than a large program. TFIQ's Data breach response plan & tabletop exercise runs over 4 weeks. It starts with a review of existing incident and breach plans, cyber insurance requirements and the notification clauses in key supplier contracts, then interviews up to six leads across IT, legal, communications, privacy and the executive.
From there TFIQ drafts a plan aligned to the NDB scheme, including OAIC statement and individual notification steps, plus playbooks for ransomware and extortion (including 72-hour ransomware payment reporting), lost devices, misdirected email and supplier breaches. You also receive roles, a contact tree, a decision log template and notification templates. A half-day executive tabletop exercise follows, and the plan is updated from an after-action report.
This service does not cover live incident response, forensic investigation, legal advice on notification decisions, technical cyber recovery runbooks or business continuity plans. If you are not sure how your wider privacy practice looks, a Privacy health check is a 1 to 2 week option that scores current handling against the Australian Privacy Principles and identifies the five things to fix first.
Frequently asked questions
Is a data breach response plan legally mandatory?
The Privacy Act does not name a plan as a standalone requirement. It does require assessment and notification of eligible breaches under the NDB scheme and reasonable steps to protect personal information under APP 11. A plan is the usual way to meet those duties. Seek advice on your situation.
Does a small business need one?
It depends on whether the Privacy Act covers you, which turns on factors such as turnover and the information you hold. Individuals can also sue for serious invasions of privacy, including small businesses outside the APPs [1]. A short plan is sensible either way.
How quickly must we assess a suspected breach?
The NDB scheme expects a prompt assessment and sets a 30-day window to complete it. The Medlab Pathology case shows inadequate assessment and late notification were each penalised separately [4]. Your plan should set internal deadlines well inside the limit.
What about ransomware payments?
The Cyber Security Act 2024 introduced ransomware payment reporting, and TFIQ's plans build in the 72-hour obligation. If your plan predates those rules, review it. Get legal advice on whether and how the reporting duty applies to you.
How often should we test the plan?
Many organisations test at least annually and after major changes, such as a new platform, a key supplier change or a restructure. The right frequency depends on your risk, so set it with your risk and compliance lead.
Does this replace our cyber incident response plan?
No. A breach response plan covers privacy assessment, notification and executive decisions. A technical cyber incident plan covers containment and recovery. They should reference each other and share a contact tree.
Start with the Data breach response plan & tabletop exercise: a 4-week engagement that gives you a tested plan, playbooks and an executive exercise.
Related: Compliance and Privacy · Privacy Compliance Review and Audit Readiness · Information Asset Register Services · Fractional Privacy Officer Service
Sources
- OAIC – Statutory tort for serious invasions of privacy (OAIC)
- OIC Queensland – IPOLA Overview (Office of the Information Commissioner Queensland)
- OAIC releases regulatory action priorities for 2025-26 (OAIC)
- OAIC – Australian Clinical Labs ordered to pay penalties in relation to Medlab Pathology data breach (OAIC)
- NDIS Commission – Mandatory registration (NDIS Quality and Safeguards Commission)
