A good incident response plan answers the questions you won’t be able to think clearly about at 2am: who’s in charge, who they call, what they do in the first half hour, and who’s allowed to pull a server offline. If your plan doesn’t fit on one page, nobody will read it when it matters.
That’s the gap most SMEs have. They’ve got a document — usually written to pass an audit — and it’s useless under pressure. Here’s how to build an incident response plan your team can actually follow when something goes wrong.
Why most SME incident response plans fail
The plans we’re handed when we take on a new client usually fail for one of three reasons, and often all three.
They’re too long. A 35-page document with a glossary, a RACI matrix and four appendices is not a plan — it’s a compliance artefact. When a finance manager in Hawthorn notices their mailbox sending invoices they didn’t write, they won’t page through a PDF. They need to know who to ring and what to touch, in seconds.
They’ve never been tested. A plan that has only ever been read is a guess. You don’t find out that the listed “incident lead” left eight months ago, or that nobody knows the after-hours number for your IT provider, until you’re already in a live event.
They were written for auditors, not for 2am. A document that satisfies an ISO 27001 control reads very differently from one a stressed staff member can act on. The first describes a process in the passive voice; the second tells a named human to do a specific thing right now. You need both, but if you only have time for one, write the one for 2am.
The six phases, in plain English
Every credible incident response framework — the ACSC’s guidance and the international NIST model both land in the same place — breaks a response into six phases. You don’t need to memorise the jargon, but you do need to understand what each phase is for.
- Prepare. Everything you do before an incident: the plan, the contact list, logging, backups, and training so people recognise an incident when they see one. This phase decides how the other five go.
- Detect. Noticing something is wrong and confirming it’s real. The faster you detect, the less damage gets done. Detection that relies on a customer phoning to say their data is on a forum isn’t detection — it’s notification.
- Contain. Stopping the spread: isolating the affected machine, disabling the compromised account, blocking the malicious sender. Stop the bleeding before you worry about the cure.
- Eradicate. Removing the cause — the malware, the foothold, the dodgy mail rule the attacker created. Containment buys time; eradication makes it safe to come back.
- Recover. Bringing systems back in a controlled way, restoring from clean backups, and watching closely in case the attacker is still around.
- Lessons learned. The bit everyone skips. A short, blameless review of what happened and what you’d change. Skip it and you’ll relive the same incident next quarter.
The mistake is treating these as neat, sequential stages. In a real event you’ll be detecting, containing and notifying at once. The phases are a checklist of what must happen, not a timeline.
What a usable one-page plan contains
The plan people actually follow is short, specific and pinned somewhere everyone can reach. Here’s what earns a place on the single page.
Roles and a call tree
Name an incident lead — one person who owns the response and can make decisions — and a deputy for when they’re on a plane. Then a call tree: who rings whom, in what order. The staff member who spots the problem rings the lead, who decides whether to escalate and who else gets pulled in. Names and mobile numbers, not job titles. “Notify the CISO” is no use to a business that doesn’t have one.
Severity levels
Three is plenty. A simple severity scale stops people either panicking over spam or shrugging at ransomware. Something like:
| Severity | Example | Response |
|---|---|---|
| P1 — Critical | Ransomware, active data exfiltration, business-wide outage | Invoke the plan immediately, all hands, ring the MSP now |
| P2 — Major | Single compromised mailbox, one infected machine, suspected breach | Lead engaged within the hour, contain and assess |
| P3 — Minor | Isolated phishing click with no confirmed compromise | Investigate during business hours, log it |
First-30-minutes actions
The single most valuable part of the page. A short, ordered checklist for before anyone has worked out exactly what’s happening: don’t turn the machine off (you’ll lose evidence in memory), disconnect it from the network instead, change the affected user’s password, ring the incident lead, and start a timestamped log of who did what and when. That log matters later — for your insurer, for the OAIC, and for the lessons-learned review.
Who can authorise disconnecting systems
Spell out, by name, who has the authority to pull production systems offline. In the heat of an incident, the worst outcome is a staff member who can see the problem but is too afraid to act because they’re not sure they’re allowed to take the line-of-business server down. Pre-authorise it. The incident lead, or a named director, can make that call without waiting for a meeting.
Communications
Decide in advance who says what to whom. Internally: how you tell staff without tipping off an attacker who may be reading the same mailboxes (use a phone tree or an out-of-band channel, not the compromised email). Externally, you may have legal duties:
- The OAIC. If personal information is breached and serious harm is likely, the notifiable data breaches scheme requires you to notify the Office of the Australian Information Commissioner and affected individuals. We’ve covered the timing and thresholds in our piece on the OAIC obligations for Melbourne businesses. Build the assessment trigger straight into your plan.
- ReportCyber and the ACSC. Cybercrime should be reported to the Australian Cyber Security Centre (ACSC) through ReportCyber. It doesn’t replace your other obligations, but it’s the right channel.
- Customers. A pre-agreed holding statement saves you drafting one while the phones are ringing. Honest, brief, no speculation.
Recovery priorities tied to RTO and RPO
Not everything comes back at once, so the plan should rank what comes back first. That ranking comes straight from your recovery time objective (how long you can be down) and recovery point objective (how much data you can afford to lose). If you haven’t set those, our guide on RTO versus RPO walks through how. The short version: the systems with the tightest RTO get restored first, and your backup design has to actually meet the RPO you’ve promised — tested, not assumed.
An IR plan is not a BCP or DR plan
People use these terms interchangeably, then wonder why the documents contradict each other. They answer different questions.
| Plan | Answers | Triggered by |
|---|---|---|
| Incident response (IR) | How do we stop and clean up a security incident? | A cyber attack, breach or compromise |
| Disaster recovery (DR) | How do we get IT systems back up? | Any outage — attack, hardware failure, flood |
| Business continuity (BCP) | How does the business keep operating while IT is down? | Any major disruption to operations |
They overlap. A ransomware event might trigger all three: the IR plan handles containment and eradication, the DR plan handles restoring systems from backup, and the BCP keeps invoices going out and staff paid while it happens. Keep them as separate, linked documents rather than one giant file, and make sure the recovery steps in your IR plan point at the same RTO/RPO targets your DR plan uses.
Test it before it’s real
An untested plan is a hypothesis. The cheapest, most effective test is a tabletop exercise: get the people named in the plan around a table for 90 minutes and walk through a realistic scenario. “It’s 7am Monday, finance can’t open any files and there’s a ransom note on the desktop. Go.” Then watch what breaks.
Every tabletop we run surfaces the same gaps: the after-hours number is wrong, two people both think they’re the lead, nobody knows where the offline backups are, or the plan assumes a tool the business doesn’t have. None of those are failures — finding them in a meeting room beats finding them in a real breach. Run one at least annually, and again whenever something significant changes. It’s a core part of being Essential Eight aligned, not a nice-to-have.
Decide who you’re calling before you need them
When a P1 hits, you do not want to be googling “incident response Melbourne” at 2am. The contact list — current numbers, on the page — should include the people you’ll genuinely need:
- Your MSP. The team that knows your environment and can contain the incident technically. Response time is the whole game here.
- Your cyber insurer. Most cyber policies require you to notify them early, often within hours, and many provide a breach-response hotline and panel of specialists. Notify late and you risk the claim.
- Your lawyer. For anything involving personal data, regulatory notification or potential liability, get legal advice early. It also helps protect privilege over the investigation.
A manufacturing business in Dandenong we work with learned this the practical way. A staff member clicked a convincing invoice link, credentials were phished, and within an hour the attacker was setting up forwarding rules to skim payment redirections. Because their plan named us as first call and pre-authorised us to disable accounts, we killed the session, reset the credentials and locked the mailbox down before money moved. The plan didn’t prevent the click — nothing does entirely — but it turned a potential six-figure fraud into a contained, two-hour incident.
TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers and no offshore helpdesk. We target sub-15-minute response on critical incidents from our 24/7 NOC in Tecoma — which is exactly when an incident response plan stops being a document and starts being a clock. If you want a plan that holds up under pressure, our security and SOC services and broader cybersecurity services are built around detection and response, not just policy. Happy to pressure-test your current plan with a tabletop before something forces the issue.
Frequently asked questions
How long should an incident response plan be?
The part people act on should fit on one page: roles, call tree, severity levels, first-30-minutes actions and the key contacts. You can keep longer supporting detail — runbooks, notification templates, the OAIC assessment process — in a separate document, but the action page has to be short enough to use under pressure.
What’s the difference between an incident response plan and a disaster recovery plan?
The incident response plan covers how you detect, contain and clean up a security incident. The disaster recovery plan covers how you get IT systems back online after any outage, including non-security ones like hardware failure. A serious cyber attack usually triggers both, plus your business continuity plan, so keep them linked but separate.
How often should we test our incident response plan?
At least once a year with a tabletop exercise, and again after any significant change — a new core system, a major staffing change, or a merger. Testing is where you find the broken phone numbers and unclear roles before a real incident does.
Who do we have to notify after a breach in Australia?
If personal information is involved and serious harm is likely, you must notify the OAIC and affected individuals under the notifiable data breaches scheme. Cybercrime should also be reported to the ACSC through ReportCyber. Notify your cyber insurer early too — most policies require prompt notification.
Can our staff disconnect a server during an incident?
Only if your plan says so, by name. Pre-authorise specific people to take systems offline, because the worst outcome is a staff member who can see the problem but hesitates because they’re not sure they’re allowed to act. Spell out who has that authority before you need it.