Incident Response Plan for Australian SMEs: A Practical Guide

An incident response plan is a written, practised set of steps your business follows when a cyber incident hits, so that people act decisively instead of improvising under pressure. For an Australian SME it does not need to be a hundred-page document. It needs to answer, in advance, who does what, who to call, and how to keep the business running, because the middle of a ransomware attack is the worst time to work that out.

Key facts

• An incident response plan defines roles, contacts, and steps to follow during a cyber incident, decided in advance rather than in the moment.
• The ACSC recommends an "assume compromise" posture: plan for incidents as something that will happen, not something that might.
• A plan is only useful if it is tested. An untested plan tends to fail at the first step, usually because contact details are stale or nobody knows who decides.
• Businesses with annual turnover of AU$3 million or more must report ransomware payments under Australia's mandatory reporting regime, so your plan should include the reporting obligation.
• The average self-reported cost of a cybercrime incident for an Australian small business was AU$56,600 in 2024-25, and fast, organised response is one of the biggest levers on that cost.

What is an incident response plan?

An incident response plan is a documented procedure that sets out how your business detects, contains, and recovers from a cyber incident, and who is responsible for each part. It covers the practical questions that matter when something goes wrong: how an incident gets reported internally, who has authority to make decisions like taking systems offline, who contacts your IT provider, insurer, and if needed the authorities, and how you keep essential operations running while you recover. The point is to convert panic into a checklist. When people know their role in advance, response is faster and mistakes are fewer.

Why does an SME need one?

Small businesses need an incident response plan precisely because they lack the depth to improvise well under pressure. A large organisation has a security team that has rehearsed this. A ten or thirty-person business does not, so the plan is what stands in for that experience. The ACSC's guidance for 2024-25 is explicit that organisations should adopt an "assume compromise" mindset, treating a serious incident as a matter of when rather than if. Across the SMEs we support, the ones that come through an incident with the least damage are not the ones that were never hit. They are the ones who knew who to call and acted in the first hour instead of losing a day deciding what to do.

What should the plan contain?

A workable SME plan is short and specific, and it covers a handful of essentials. It names the people involved and their roles, including who has authority to make the hard calls. It lists the contacts you will need in a hurry: your IT provider or MSP, your cyber insurer, key staff, and the ACSC reporting channel. It describes the first containment steps for the most likely scenarios, such as isolating an affected machine or disabling a compromised account. It sets out how you communicate, internally and with customers, if data is affected. And it records where your backups are and how to restore them. Length is not the measure of a good plan. A two-page plan people have read beats a fifty-page plan sitting unopened on a shared drive.

How often should you test it?

A plan should be tested at least annually, and the test can be as simple as a tabletop exercise where you talk through a realistic scenario and check each step holds. Testing is where plans earn their keep, because it surfaces the things that quietly break: the emergency contact who left the company, the backup nobody has ever tried to restore, the assumption that someone specific would be available. We run these exercises with clients and the most common finding is not a technical gap, it is that the contact list is out of date or the decision-making authority was never clearly assigned. Fixing those before an incident is cheap. Discovering them during one is not.

What are your reporting obligations in Australia?

Your plan should account for Australian reporting obligations, because they now carry legal weight. Under the mandatory ransomware reporting regime, businesses with annual turnover of AU$3 million or more must report ransomware payments to the government within the required timeframe. Separately, under the Notifiable Data Breaches scheme, businesses covered by the Privacy Act 1988 must notify the OAIC and affected individuals when a breach is likely to cause serious harm. Building these into the plan means the reporting decision is considered calmly in advance rather than missed in the chaos, and it makes clear who is responsible for making the notification. Getting the reporting wrong adds a regulatory problem on top of the incident.

Frequently asked questions

What is the difference between an incident response plan and a disaster recovery plan?

An incident response plan covers how you handle a security incident: detection, containment, decision-making, and reporting. A disaster recovery plan covers how you restore systems and data after any disruption, including non-security events like hardware failure or fire. They overlap in the recovery phase, and a complete approach has both. The incident response plan gets you through the event; the disaster recovery plan gets your systems back.

How long does it take to create an incident response plan?

A practical SME plan can be drafted in a matter of days once you gather the inputs: your key contacts, your systems and backups, and agreement on who makes decisions. The bigger investment is keeping it current and testing it, which is an ongoing commitment rather than a one-off. A plan that is written once and never revisited is barely better than none.

Do we need an incident response plan for cyber insurance?

Many cyber insurers now ask whether you have an incident response plan as part of underwriting, and some make it a condition, so having one can affect both your eligibility and your premium. Beyond insurance, it materially reduces the cost and disruption of an actual incident, which is the real reason to have one.

Who should be involved in the plan?

At minimum, a decision-maker with the authority to act (often the owner or a manager), whoever handles IT (internal staff or your MSP), and someone responsible for communications. For a small business these roles may be held by only two or three people. The important thing is that the roles are assigned and understood before an incident, not worked out during one.

If you do not have an incident response plan, or you have one but have never tested it, that is something we can help you put right before you need it. Call 4iT on 1800 367 448 or book a chat and we will build a plan that fits how your business really runs.