You find out how good your incident response plan is at 6am on a Tuesday, with systems encrypted, staff locked out, and a reporting clock that started before anyone noticed. A working plan names who decides, who they call, and which deadlines apply.
Large organisations used to be the only ones writing an incident response plan. The obligations attached to an incident are now specific, and several run on deadlines measured in hours.
Where the requirement comes from
There is no single Australian law that says “you must have an incident response plan” in those words. Several separate obligations add up to the same requirement.
The Privacy Act and the Notifiable Data Breaches scheme
APP 11 requires reasonable steps to protect personal information. Under the NDB scheme, where you suspect an eligible data breach you must assess it quickly and notify the OAIC and affected individuals where serious harm is likely. The assessment window is a maximum of 30 days, and the expectation is “as soon as practicable” rather than on day 29.
The OAIC has been explicit that the clock starts when any employee becomes aware of the incident, not when it reaches management or when IT confirms it. If a staff member notices something on Friday afternoon and mentions it on Monday, you have already spent three days of your window.
Your logs set the limit on what you can assess. Deciding whether a breach is notifiable means answering “what was accessed, by whom, and whose data was it?” Without audit logging you cannot answer that, so you notify every client, because you cannot rule anyone out. That notification costs you more than the breach warranted.
The Cyber Security Act 2024
Since 30 May 2025, businesses with annual turnover of $3 million or more must report ransomware or cyber extortion payments to government within 72 hours of making the payment, or of learning that someone paid on their behalf, including an insurer or an incident response firm. There is no minimum payment threshold, and civil penalties for failing to report run to $19,800.
This obligation sits on top of the NDB scheme rather than replacing it. One ransomware incident involving customer data triggers both, with different triggers and different clocks.
Your insurer
Most businesses meet this requirement first, because they see it as a question on a renewal form. Cyber policies now ask whether you hold a documented and tested incident response plan, and many require notification before you engage a third-party responder. Engaging your own IT firm first, in good faith, can prejudice cover.
Certification and procurement
An incident response plan is an explicit control at SMB1001:2026 Gold, and a standing expectation under ISO 27001. If you tender for government or enterprise work, or supply larger businesses, expect to be asked for evidence.
Directors’ duties
The Federal Court’s decision in ASIC v RI Advice Group established that effective cyber risk management is part of an adequate risk management system. The reasoning is not confined to financial services: an organisation that had no plan, no tested backups and no idea who to call is in a weaker position when asked whether it acted reasonably.
Sector obligations
Law firms, accounting practices and other professional services now sit inside the AML/CTF regime following the Tranche 2 reforms of 1 July 2026, which brings AUSTRAC obligations and seven-year record-keeping into the picture. Tax practitioners have quality management obligations under the TPB Code Determination. Critical infrastructure operators have obligations under the SOCI Act. Write down each notification path before you need it.
The clocks overlap
Any one of these obligations is manageable. A single incident triggers several at once, each with a different trigger event and a different deadline, while you are also restoring systems and answering worried clients.
| Obligation | Trigger | Deadline |
|---|---|---|
| NDB scheme (OAIC) | Personal information accessed, disclosed or lost, and likely to result in serious harm | As soon as practicable; 30 days maximum to assess |
| Ransomware payment report | A payment was made, or made on your behalf ($3m+ turnover) | 72 hours from payment or from awareness of it |
| Cyber insurer | Suspected incident, often before engaging any responder | Immediately. Check your policy wording |
| Clients and partners | Their data or funds affected, or contract requires it | Per contract or engagement terms |
| Regulator or professional body | Sector-specific: AUSTRAC, ATO, TPB, APRA, ASIC, law society | Varies; identify yours in advance |
Deciding which of these applies, in the middle of an outage, without a written reference, is how you end up over-notifying or missing a deadline.
What a plan actually needs to contain
A useful plan is short. Decide six things in advance instead of debating them under pressure.
Who decides
One named incident lead, and a named backup for when the lead is on a plane or unreachable. Someone has to be able to authorise taking production systems offline without convening a meeting.
Who they call
Real phone numbers for IT support, insurer, lawyer, bank and accountant, filled in now. Searching for your insurer’s after-hours line at 2am is a waste of the hours that matter most.
Which obligations apply
Mapped to triggers, so the question becomes “did this happen?” rather than “what does the legislation say?” Work this out once, calmly, and write it down.
What gets said, and by whom
One voice to clients, one to the regulator, one to staff. Uncoordinated messages create their own problems, and early speculation turns into a statement you have to correct later.
An incident log
Contemporaneous notes of what happened, what was decided and why. You will use it to make your notification decisions, support your insurance claim, and show that you acted reasonably.
Somewhere it survives
Printed, or on a device outside the affected environment. A copy stored only on the file server gets encrypted along with it. We see this gap more than any other.
Download the template
We have put together a fillable incident response plan template covering the six elements above, built around the Australian obligations rather than a generic overseas framework. It is a PDF with form fields. Complete it on screen and share it with your team, or print it and keep it in the folder that survives the outage.
Free download
Incident Response Plan Template
Six pages, 138 fillable fields, no sign-up required. Covers organisation details and plan ownership, your internal response team with 24/7 contacts, external contacts including insurer and bank fraud lines, severity definitions, a first-response checklist with timestamps, the notification obligations checklist with deadlines, a 13-row incident log, and a post-incident review with action tracking.
Fill it in on screen or print it. Either way, do it before you need it.
Download the PDF template
PDF · 6 pages · 61 KB
General template only. It is not legal advice and does not account for your particular circumstances. Confirm your own obligations with your advisers.
Testing the plan
The gaps appear when you walk through a scenario out loud: who rings the insurer? Does anyone know the policy number? If the file server is encrypted, where is the contact list? Who talks to clients if the director is overseas?
A tabletop exercise costs an hour of a few people’s time, and it turns up two or three things that would have cost days during a real incident. Run one annually, and again after any significant change to your systems, staff or obligations.
The failures we see most often
| × | The plan exists, but only as a file on the server that just got encrypted |
| × | Contact fields left blank because someone would “look it up at the time” |
| × | No named backup for the incident lead |
| × | Written before 2025, so it has no 72-hour ransomware reporting step |
| × | Backups that have never been restore-tested, so recovery time is unknown |
| × | No audit logging, so “what was accessed?” cannot be answered |
An hour spent on this now is the difference between meeting the 72-hour deadline and missing it.
How Mobile Techs helps
The plan assumes the technology underneath it works. Several steps in the template take for granted that you can isolate an endpoint, restore a backup, and read a log to see what was touched.
Mobile Techs IT Consulting builds and maintains that layer for Gold Coast businesses and firms across Australia: ThreatDown EDR to detect and contain an incident before it spreads, RMM patching and device management to close known vulnerabilities, tested backup and recovery so you know how long a restore takes, and logging so you can answer the notification question.
Incident readiness review
Would your plan hold up on the day?
We will walk through your environment against the scenarios in this template: containment, recovery, logging, backup restoration and the notification decisions you would have to make. You get a written, prioritised list of what needs attention now and what can wait.
No jargon and no obligation. You get a clear picture before someone else asks for one.
Book a review
Talk to us first
Call 1300 644 588 · office@mobiletechs.com.au
Supporting Gold Coast businesses on-site since 2008, and firms across Australia remotely.
More on our managed IT services and remote security audit.
General information only. This article and the accompanying template cover the technology and security implications of current Australian regulation. They are not legal advice and do not account for any particular organisation’s circumstances. Obligations under the Privacy Act, the Cyber Security Act, the AML/CTF Act and sector-specific regimes vary and continue to change. Confirm your own obligations with your advisers.
