Most businesses invest serious time and money into preventing cyber attacks. Very few have a written plan for what to do when one gets through. That gap matters, because something will get through eventually, and the first 30 minutes of a cyber incident are usually the most damaging.
An incident response plan will not stop a breach. It will stop your team from freezing, making it worse, or accidentally destroying the evidence you need to recover and report.
Why most businesses don't have one
The honest answer is that IR plans feel like a compliance exercise. Something you write once, file somewhere, and never look at again. That reputation is earned, because most IR plans are exactly that: dense documents written by consultants to satisfy an auditor, with no resemblance to how a real business operates under pressure.
A useful IR plan looks different. Short enough to read in two minutes, kept somewhere accessible when your network is down, tested at least once even if just over coffee. The common thread in every plan that actually works is that the people named in it know they are in it.
What your plan actually needs to cover
Incident response frameworks like NIST SP 800-61 break the process into five phases. For an SMB the language matters less than the substance.
1. Identify: recognise that something is wrong and figure out what you are dealing with. A ransomware note is obvious. Unusual logins, slow systems, or staff reporting strange emails are less so. Your plan should define who makes the call that an incident is underway and what the threshold is.
2. Contain: stop the bleeding. Isolate affected systems from the rest of the network. This might mean physically unplugging a device, disabling a user account, or cutting off a compromised cloud integration. Speed matters here, but so does doing it without destroying evidence.
3. Eradicate: remove the threat. Delete the malware, close the exploited access path, patch the vulnerability. This step should not happen until containment is complete, and it should not be rushed.
4. Recover: restore systems and resume operations. This is where your backups either save you or fail you. Your plan should document what a clean recovery looks like and what testing needs to happen before systems go back online.
5. Review: once the dust settles, work out what happened, how it got in, and what needs to change. A post-incident review is not a blame exercise. It is the only thing that stops you from going through this again in six months.
The reporting obligations you need to plan for
Two separate reporting obligations can apply to your business, and both need to be baked into the plan before an incident happens.
The Notifiable Data Breaches scheme under the Privacy Act applies to any organisation with an annual turnover above $3 million, as well as certain other categories (health service providers, credit providers, tax file number recipients) regardless of size. If an eligible data breach occurs, you must notify the Office of the Australian Information Commissioner and affected individuals as soon as practicable. In practice the OAIC expects notification within 30 days of becoming aware.
The Cyber Security Act 2024 introduced a separate 72-hour reporting obligation specifically for ransomware payment decisions. If your business pays a ransom demand, you are legally required to report that payment to the government within 72 hours. For the full breakdown of who this applies to, see our post on the 72-hour ransomware reporting rule.
Working out who to notify and what to say in the middle of an active breach is not the time you want to be reading the Privacy Act.
What to put in each section
A usable IR plan for a small business does not need to be long. One to three pages is enough if the right information is in it.
Contact list: this is the single most important section. Who do you call first? It needs to include internal contacts (IT, management, legal), external contacts (your IT provider or MSSP, your cyber insurer's claims line, your lawyer), and regulatory contacts (OAIC, 1300 CYBER1). Mobile numbers, not just email. People need to be able to reach each other at 2am.
You also need a way to classify what you are dealing with. Not everything is a major breach. A phishing email caught by your filter is a different situation to an attacker inside your network, and the response should be different too.
Containment steps need to be specific enough to use under pressure. "Isolate the affected device" is useful. "Contain the incident" is not. Include the decision on whether to shut systems down entirely or keep them running for forensic purposes. Your IT provider or insurer will have a view on this, and you want that answer before the phone is ringing at 2am.
Communication templates: draft language for internal staff notifications, customer notifications if data was exposed, and regulator notifications. You do not want to write these under pressure with lawyers and insurers waiting. Having a template that gets reviewed and personalised is far faster than starting from scratch.
Evidence preservation checklist: what not to touch, what to screenshot, what logs to capture before systems are restored. Evidence is regularly destroyed in the panic to recover, and you need it for insurance claims, regulatory responses, and any future legal action.
Recovery criteria: what does a clean system look like before it goes back online? Who signs off on that? Document this before you need it.
The mistakes that make IR plans useless
It only exists as a PDF on a shared drive. If your network is down or your systems are encrypted, you cannot access it. Keep a printed copy somewhere physical. Keep a copy in a cloud service that does not touch your main infrastructure.
Nobody knows they are in it. An IR plan that names specific people works only if those people know what is expected of them. Run through it with the relevant staff at least once a year.
It has never been tested. A tabletop exercise does not need to be a full simulation. Sit three or four people down, describe a scenario ("our finance system shows unusual activity at 7am, the IT manager is on leave, what do we do?") and walk through it. You will find gaps within ten minutes.
The insurer's number is not in it. Your cyber insurance policy almost certainly requires you to contact the insurer before taking major recovery steps. If you restore from backup or pay a ransom before calling them, you may have voided coverage. That number belongs in your plan before anything else.
It is too long to be read under pressure. Structure it in two parts: a quick reference card covering the first 30 minutes, and a full phased process for later stages. A dense document nobody reads in advance will not be read under pressure either.
Get the free template
We have put together a free fillable template that covers everything above. It is structured in two parts: a quick reference card for the first 30 minutes when your systems may be down, and a full phased process from Identify through to Review. Pre-written actions are paired with fillable fields for your specific contacts, systems, and thresholds. The OAIC and ASD hotline numbers are pre-filled. Fill it in once, print it, and store it with your insurance policy.
Download the free incident response plan template
If you want help reviewing your current security posture before an incident forces your hand, get in touch.