A cyber incident response plan gives a small or medium-sized business a calm, repeatable way to handle a suspected attack. It tells people who makes decisions, what to protect first, how to preserve useful information, and when to bring in outside help. Without that preparation, the first hour is often spent looking for phone numbers and arguing about whether the event is serious enough.
This guide explains how to build a practical plan for an SMB in Australia. It is designed to be used during a busy day, not stored as a policy nobody has opened since it was approved.
Key takeaways
- Name an internal incident owner and a backup before an incident occurs.
- Rank the systems, suppliers and data the business needs to keep operating.
- Write a first-hour checklist that covers containment, evidence, money and communications.
- Give staff one safe route for reporting concerns, including when email is unavailable.
- Exercise the plan at least annually and revise it after major business changes.
Why an SMB needs a response plan
A cyber incident can begin with a suspicious sign-in, a lost device, a fraudulent payment request, malware on a workstation or an account that suddenly stops working. The technical cause may not be clear at first. The business still needs to decide whether to pause payments, isolate an account, contact a provider, warn staff or notify an affected customer.
The Australian Signals Directorate defines a cyber security incident as an unwanted or unexpected event that has compromised business operations, or has a significant probability of doing so. Its guidance recommends an incident management policy and associated response plan, and says the plan should be exercised at least annually. Read the ASD guidance for cyber security incidents alongside the business's own legal, insurance and contractual obligations.
A good SMB plan is short. It does not try to predict every attack. It gives people enough structure to limit harm while a technical provider, insurer, adviser or authority helps with the investigation.
What you will need
- One incident owner and one backup with authority to act
- A list of essential systems, data, suppliers and administrator accounts
- Offline contact details for the bank, technology provider, insurer and advisers
- A private incident log with time, fact, action and owner columns
- A staff reporting route that does not depend on the affected account
- A short communications template for staff, customers and suppliers
The steps
1. Define the trigger and the owner
Write down the events that start the plan: suspected account takeover, unusual payment activity, malware, lost device, exposed customer information, or loss of access to a critical service. The trigger does not need to prove an attack. It needs to identify a credible risk to money, information, availability or access.
Name an internal owner who can declare an incident and a backup who can do the same. Give them permission to contact the technology provider, pause an urgent payment, disable a compromised account and bring in specialist advice. An IT provider can lead technical work, but the business still needs someone who can set priorities and approve communications.
2. Rank what keeps the business running
List the five or fewer services whose loss would cause the greatest disruption. Depending on the business, these may be email and identity, payroll, customer records, online ordering, point-of-sale, bookings or shared files. For each one, record the business owner, supplier, administrator, backup arrangement and recovery dependency.
Rank the list. A long inventory is not a recovery plan. A cyber security gap assessment can help expose missing owners and undocumented dependencies before an incident. The result should be a simple priority order that tells the response team what to protect and restore first.
3. Build the contact and authority sheet
Create a one-page contact sheet with primary and backup contacts for technical containment, payments, legal and privacy advice, insurance, customer communications and relevant authorities. Include the bank's fraud number and the provider's emergency route. Store the sheet in two places, including one offline or separately hosted location.
For each role, state what can be approved immediately and what requires executive or adviser input. Do not leave the team to discover during an incident who can stop a payment or contact a supplier. Review the sheet whenever a contact, provider or responsibility changes.
4. Write the first-hour checklist
The first hour should start with recording the report, time and person who noticed the issue. Identify the affected account, device, service or transaction. Stop an obvious financial loss if the bank or response owner directs it. Then contact the owner and technical provider through a known route.
Tell staff not to delete suspicious messages, wipe devices, forward sensitive material or reset every password before the response lead decides what evidence is needed. Isolate an affected account or device when it is safe and useful, but do not disconnect systems blindly if that could interrupt a critical service or destroy evidence.
5. Control the log and communications
Use one incident log with four fields: time, confirmed fact, action and owner. Mark assumptions as assumptions. This prevents several teams from acting on different versions of the same event. Keep the log private and give access only to people who need it to respond.
Choose one person to approve external statements. Prepare short messages that explain what service is affected, what customers should do, and how suppliers can verify payment instructions. A human risk reporting process can provide a consistent route for staff to report suspicious emails, calls and requests before they become larger incidents.
6. Recover in a deliberate order
Recovery begins only after the owner and technical adviser agree on the containment decision. Revoke or reset affected credentials, confirm that backups are usable, restore the highest-priority service, and test it with the system owner. Record every restored system, changed account and outstanding risk.
Add independent checks for payment and identity changes. A supplier bank-detail change should be verified through a known contact, not the message that requested it. A new administrator account should have a named owner and a documented approval. Restoration is not proof that an attacker has lost access, so keep monitoring and validate the environment after service returns.
7. Exercise and improve the plan
Run a tabletop exercise at least annually, then review the plan after a major software migration, supplier change, office move, payment-process change or real incident. Use a scenario that forces a decision: a compromised mailbox, a fraudulent invoice, a ransomware warning or a lost device.
Measure how long it took to find the contact sheet, declare the incident, identify the owner and choose the first action. Record the three biggest delays and fix those first. An exercise is successful when it finds a weakness while there is still time to correct it.
Troubleshooting
- Nobody knows whether to activate the plan. Use the trigger list and let the named owner act when there is a credible risk; certainty can come later.
- Email may be compromised. Keep the contact sheet and coordination route outside the main email account.
- Staff are worried about blame. Treat an early report as useful evidence and coach the person on the next safe action.
- The plan is too long. Put the first-hour checklist and contacts at the front, then keep technical playbooks in appendices.
- Recovery priorities are disputed. Ask each system owner to document the operational harm caused by loss, alteration or exposure, then rank from that evidence.
- A provider owns all the technical knowledge. Include the provider in exercises, but keep business decisions and contact ownership inside the organisation.
Tools and resources
Keep the ASD incident guidance with the plan and use phishing awareness guidance to teach staff how to report suspicious messages. Cyber Aware security awareness training can reinforce the reporting habits the plan depends on. If the business is comparing platforms, use the security awareness platform comparison to check whether reporting, assignments and evidence fit the operating model.
What to do next
Set a 30-minute meeting with the owner, backup and technology provider. Finish the contact sheet, rank the essential services and run one tabletop scenario before adding more detail.
FAQ
What is a cyber incident response plan?
It is a written set of roles, contacts, decisions and actions for handling a suspected cyber security incident. It helps an SMB contain harm, preserve useful information, communicate clearly and recover its most important services in the right order.
Who should own the plan?
A named internal business owner should own it, with a backup who has the same authority. A technology provider may lead technical response, but the business owner must set priorities and approve operational and customer decisions.
What should staff do when they suspect an incident?
They should stop interacting with the suspicious message, device or request, preserve the available details and report it through the approved route immediately. They should not investigate alone, delete evidence or wait until they can prove an attack occurred.
Should an SMB disconnect a compromised computer?
It should isolate the device when the response owner or technical adviser says that is safe and useful. Blindly unplugging systems can interrupt essential services or remove evidence, so the action belongs in the first-hour playbook.
How often should the plan be tested?
Exercise it at least annually and review it after major changes or real incidents. Test contacts, authority, reporting, communications and recovery priorities rather than simply reading the document.
Does the plan replace security awareness training?
No. The plan explains what the organisation does after a concern is raised. Awareness training helps staff recognise and report that concern early, giving the plan more time to work.
One last thing
The most valuable line in an SMB response plan is often the one that says who can pause a payment or disable an account without waiting for a meeting. Write that authority down, test it and keep it available when the main systems are not.