How to write a cyber incident response plan for a small business

Why a plan beats improvisation

When something goes wrong, the first hour is usually wasted on confusion. Is this serious? Who decides? Should we turn things off? Where is the insurance policy? Who has the IT provider's after-hours number? Meanwhile an attacker may still be active, evidence is being overwritten and staff are making well-meaning changes that make recovery harder.

A plan answers those questions in advance, when people are calm. It does not need to anticipate every scenario. It needs to get the right people talking, stop the damage spreading and avoid the common mistakes, such as wiping infected machines before anyone has looked at them or paying a fraudulent invoice twice while investigating the first.

Define what counts as an incident

Give staff examples so they know when to raise the alarm: ransom notes or files that will not open, unexpected password reset emails, someone reporting an email from you that you did not send, a payment that went to the wrong account, a lost laptop or phone, or security software warning about a threat it could not remove. Make it clear that reporting something that turns out to be nothing is welcome. Include a simple severity guide. A single suspicious email that nobody clicked is minor. A compromised mailbox is serious. Encrypted servers or confirmed data theft are critical. Severity decides who gets called and how quickly.

Roles and decision rights

Name an incident lead, usually the owner or a senior manager, with a deputy in case they are unavailable. That person makes decisions such as disconnecting the internet, calling the insurer, notifying customers or bringing in outside specialists. Name a technical lead, often your IT provider, responsible for investigation and recovery. Name someone to handle communications with staff and customers.

Write down which decisions the technical lead can make without asking, such as isolating a computer or disabling an account. In an active attack, waiting for permission can cost hours. Agree too who can authorise spending on outside help, and up to what amount, so a specialist can be engaged at night without tracking down the owner on holiday.

The first-hour checklist

Keep this part short enough to follow under pressure. Typical steps: write down the time and what was seen; disconnect affected devices from the network but leave them on; do not delete anything or pay anything; call the incident lead; call the IT provider; if insured, call the insurer's incident line; start a written log of every action and decision. Add specific steps for the most likely incidents. For a compromised mailbox, reset the password, revoke sessions and check forwarding rules. For a suspected payment fraud, call the bank immediately, because recovering funds depends on speed.

Contacts that work when systems do not

List phone numbers and email addresses for the incident lead, deputy, IT provider, insurer, bank, broker, lawyer and key suppliers such as your internet provider and line-of-business software vendor. Add the NCSC reporting details and the Privacy Commissioner's website. Include policy numbers and account numbers you might need. Store this list somewhere you can reach if email, Microsoft 365 and the file server are all unavailable: printed copies at the office and at home, and on a personal phone. A plan saved only on the server that has just been encrypted is no help at all.

Communication and recovery priorities

Decide how staff will communicate if email and Teams are down, such as a text message group. Prepare short template messages for staff, customers and suppliers that can be adapted quickly. Agree that external statements go through the incident lead and, where relevant, the insurer. List your systems in recovery order with a target time for each. For most businesses, the order is identity and email, then the main line-of-business application, then shared files, then everything else. This tells the technical team where to focus and helps you judge whether your backups can meet those targets.

Testing and maintenance

A plan nobody has read is barely better than no plan. Walk through it with the people named in it at least once a year, using a realistic scenario. You will find out-of-date phone numbers, unclear decisions and missing steps. Update the plan after any real incident and whenever key people or systems change. Keep the document versioned and dated. Insurers and clients increasingly ask whether you have a tested plan, and a dated record of your annual review answers that question with evidence rather than assurance.