A cyber incident response plan turns a chaotic breach into a managed event with clear roles, clear steps, and a clock that starts ticking the moment someone spots trouble. This guide walks you through building one for an SMB in 2026, step by step, with the legal deadlines and testing routines that actually get followed.
TL;DR
- A cyber incident response plan for small business needs six documented steps, not a 40-page binder nobody opens.
- Australia's Notifiable Data Breaches scheme gives you 30 days to assess a suspected breach once you become aware of it.
- Untested plans fail during real incidents. A tabletop run every 6 months catches gaps a document review never will.
- Staff who fear blame stay quiet about mistakes, and that delay turns a phishing click into a full breach.
Why this matters
Most SMBs don't get breached because they lack antivirus software. They get breached because nobody in the building knows what to do in the first two hours after someone clicks a bad link.
A written cyber incident response plan for small business fixes that. It assigns a decision-maker, sets a reporting trigger, and tells staff exactly who to call before the attacker has finished moving laterally through your network. Under Australia's Notifiable Data Breaches scheme, you have 30 days from becoming aware of a suspected breach to complete your assessment. A plan that hasn't been written yet burns through that window fast.
2026 has already seen SMBs treated as the soft entry point into larger supply chains, precisely because response plans sit unfinished in a shared drive nobody has opened since onboarding.
What you'll need
- A named incident lead and a backup, ideally not two people who take leave at the same time
- A contact list for your IT provider, insurer, and legal counsel, stored offline
- An asset inventory covering the systems, data, and vendor accounts worth protecting, ranked by impact if lost
- Communication templates for staff, customers, and regulators
- 2-3 hours of uninterrupted time to draft the first version
- A test date already in the calendar, not "sometime next quarter"
The steps
1. Assemble your response team and assign roles
Every incident needs one person with authority to make the call: isolate the server, notify customers, engage the insurer. Without a named lead, decisions stall while three people wait for someone else to act. Name a lead, a technical responder, and a communications contact, then review those names each quarter of 2026 as staff change.
Common mistake: naming the same person for all three roles. When that person is unreachable, the plan has no second option.
2. Inventory what you're actually protecting
You can't respond to a breach of a system you forgot existed. List every system that touches customer data, payment details, or supplier accounts, and rank each by what happens if it goes down for a day. That ranking becomes your triage order during a live incident.
Common mistake: listing every laptop in the office instead of the systems that hold or process sensitive data.
3. Set your detection triggers
Define, in writing, what counts as "report this now" versus "log it and move on". A single unusual login attempt is different from five staff reporting the same suspicious invoice email. Staff need a low bar for reporting, and training them to recognise cyber security threats only works when reporting carries no blame.
Common mistake: setting the bar so high that staff self-filter and never report near-misses, which removes your early warning system entirely.
4. Write the containment steps
For each major system on your inventory, write one paragraph: how to isolate it, who holds the access to do so, and what gets disabled first. If ransomware hits a shared drive, the instruction should be specific enough that a stressed staff member at 7pm can follow it without calling three people. Teams who have been through ransomware incident response training execute this faster because the steps aren't new to them.
Common mistake: writing containment steps that assume the IT lead is available immediately. Assume they're not, and write for the backup.
5. Build the notification and communication plan
Map who gets told, in what order, and within what timeframe. A breach likely to cause serious harm requires OAIC notification and notification of affected individuals once your assessment closes. Draft the customer notification email now, while you're calm, not mid-incident at 11pm.
Common mistake: drafting only a technical postmortem and skipping the plain-language version staff and customers actually need.
6. Test the plan with a live drill
A plan that has never been rehearsed fails in ways a document review never surfaces: the contact list is outdated, the isolation step assumes access nobody has anymore, the comms template names a spokesperson who left. Run a tabletop exercise or a simulated attack drill at least twice in 2026.
Common mistake: treating the first draft as finished. Plans go stale within months as staff, vendors, and systems change.
7. Document lessons and update the plan
After any real incident or drill, spend 30 minutes writing down what broke in the plan itself, not just what broke in the network. Update the contact list, containment steps, and templates before the details fade.
Common mistake: patching the technical vulnerability and never touching the plan document, so the same process gap resurfaces next time.
Get your team incident-ready
Build the staff-side habits your response plan depends on.
Troubleshooting
- Nobody reports incidents. Staff who fear blame for clicking a bad link hide it instead. Make the first report a no-blame conversation, every time, and write that into the plan.
- The incident lead is unreachable. This is what the backup in step 1 exists for. If you skipped that step, name one now.
- The plan references systems that no longer exist. Vendor changes and migrations date a plan within a year. Review the asset inventory every 6 months.
- Staff don't know the plan exists. A document in a shared drive isn't something staff can execute under pressure. Walk the team through it once a year, minimum.
- The ransomware payment question isn't answered. Decide in advance, with legal counsel, whether payment is ever on the table. Deciding it mid-incident under time pressure produces worse outcomes.
Tools and resources
- A tested cyber incident response plan document, reviewed at least twice yearly
- Staff trained to spot the trigger event, not just the technical team
- A reference sheet covering your breach reporting obligations and the 30-day assessment window
- Communication templates drafted before an incident, not during one
- An offline copy of your contact list, because a compromised email system shouldn't be where your incident contacts live
FAQ
What is a cyber incident response plan for a small business?
It is a written document naming who leads the response, what triggers a report, and how containment and notification happen. For an SMB it should fit on a few pages, not a 40-page manual nobody reads.
Is a written incident response plan legally required in Australia?
There is no blanket legal requirement to hold a written plan, but the Notifiable Data Breaches scheme requires a 30-day assessment and timely notification once you suspect a breach. A plan is how you meet that deadline in practice.
How often should an SMB test its incident response plan?
Test it at least twice a year with a tabletop exercise or simulated drill. Staff turnover and system changes date a plan faster than most owners expect.
What is the difference between an incident response plan and a business continuity plan?
An incident response plan covers the first hours and days after a cyber event: detection, containment, notification. A business continuity plan covers how the whole business keeps operating over weeks, including non-cyber disruptions.
Do I need to report a data breach to the OAIC?
You need to notify the OAIC if the breach is likely to result in serious harm to affected individuals, after completing your assessment within the 30-day window under the Notifiable Data Breaches scheme.
How long does it take to write an incident response plan?
A workable first draft takes 2-3 hours if your asset inventory and contact list are already prepared. Refining it after a test run takes less time than the first draft.
What is the first thing to do when you suspect a breach?
Isolate the affected system if you can do so without destroying evidence, then notify the named incident lead immediately. Speed in the first hour matters more than getting every step perfect.
Should general staff be trained separately from the IT team on incident response?
Yes. Staff need to know how to report a suspected incident, not how to technically contain it. Separate, simple training for general staff gets incidents reported faster.
One last thing
The biggest predictor of whether a cyber incident response plan works isn't how detailed it is. It's whether anyone has read it since it was written. A plan tested twice in 2026 beats a plan updated once and never rehearsed, every time.