Most small businesses either have no incident response plan or have a forty-page document nobody has opened since it was written for a questionnaire. Neither helps during an actual incident. What helps is a short, specific document that answers four questions under pressure, when the people involved are tired and the information is incomplete.

Who decides

Name one person with authority to take systems offline, and one alternate. Not a role — a name, with a mobile number. The most damaging delays in real incidents are almost never technical; they are twenty minutes spent working out who is allowed to authorise disconnecting a production system.

Who gets called, and in what order

A single contact list: internal decision maker, whoever administers your systems, your cyber insurer if you have one, your bank's fraud line, and outside help if you use any. Include account numbers and policy numbers inline. Keep a copy that does not depend on the systems that may be down — printed, or on a phone.

What gets contained first

Decide in advance, calmly, what matters most: customer data, payment processing, production systems, or the ability to keep operating. Write the order down. During an incident this ordering will be contested by whoever is loudest, and a decision made in advance is a better decision than one made in the first frantic hour.

What must not be destroyed

The instinct to wipe and rebuild immediately destroys the evidence needed by insurers, regulators, and anyone determining what was actually taken. Before rebuilding, preserve disk images or snapshots of affected systems and export logs — authentication, email, and any security tooling. Logs frequently roll over within days, and the window closes quietly.

Practical controls worth more than the plan itself

  • Phishing-resistant multi-factor authentication on email and remote access — passkeys or hardware keys, not SMS.
  • Offline or immutable backups, and a restore that has actually been tested. An untested backup is a hypothesis.
  • Removal of standing administrative access that is not being used today.
  • A written verification rule for payment-detail changes, requiring a callback to a number already on file.
  • Centralised logging with retention long enough to investigate — months, not days.

Rehearse it once

Spend one hour walking through a plausible scenario out loud: ransomware on the file server, or a compromised finance mailbox. You will find the gaps immediately — the contact who left last year, the backup nobody can decrypt, the fact that the person with the credentials is the person on holiday. Finding those during an exercise costs an hour. Finding them during an incident costs considerably more.