An incident response plan a small business will actually use
Most plans fail for one reason: they were written to satisfy a form, not to be read at 2 a.m. by a stressed office manager. Here is the structure that works, with the full outline.
The test of an incident response plan is simple. Hand it to the least technical person who might be first on scene, tell them the shared drive is encrypted, and watch what they do in the next ten minutes. If they can find the right phone number and know not to power off the server, the plan works. If they're reading a section titled "Governance Framework", it doesn't.
Enterprise templates fail this test because they are written for a security team. A small business has an owner, an office manager, and an IT provider on a support contract. The plan has to be written for those three people.
Section 1: Roles (one table)
Five roles, each with a named primary and backup. One person can hold more than one. Incident Lead (runs the response and keeps the log), Decision Maker (authorises spending, downtime, ransom decisions, external statements), Technical Responder (usually the IT provider), Communications (staff, customers, suppliers), and Legal/Privacy (notification duties). The table fits on half a page and is the most-used part of the whole document.
Section 2: Contact roster
Insurer hotline first, because many policies require you to call them before engaging anyone else or coverage is reduced. Then IT provider, legal counsel, bank fraud line, domain registrar, email provider admin, backup provider, police non-emergency, and your national fraud and cyber reporting centres. Print it. Keep a copy off the network, because the network is the thing that's down.
Section 3: Severity levels
Four levels, assigned in the first fifteen minutes and changed as you learn more. Critical: the business cannot operate or regulated data is confirmed exposed. High: a major function is impaired or confidential data is likely exposed. Medium: contained to one system or user with no data exposure evident. Low: an attempt only. Each level says who gets woken up and how fast the insurer is called. Without this, every incident is either panic or shrug.
Section 4: The first hour
A single checklist with tick boxes and a time column, done for every Medium or higher incident before any specific playbook:
- Start the incident log: time, who reported it, what they saw. Every action from here on gets a timestamp.
- Assign a severity and notify the people that severity requires.
- Contain, don't clean. Disconnect affected machines from the network. Do not power off, wipe or reinstall; you destroy evidence and may lose the ability to recover files.
- Preserve evidence: photograph screens and ransom notes, save suspicious emails as attachments rather than forwarding them.
- Call the insurer hotline for Critical or High.
- Reset passwords and revoke sessions for any account that may be involved, starting with email and admin accounts.
- Check that the latest clean backup exists and is disconnected from the affected network. Don't restore yet.
- Brief staff with a holding statement; nothing external, nothing on social media.
- Open the specific playbook.
The time column matters more than it looks. Insurers, lawyers and regulators will ask what you did and when; a log written as it happened is worth ten times a reconstruction.
Section 5: Playbooks
Three cover almost every small-business incident. Ransomware: contain (isolate everything, disconnect backups, pause cloud sync), assess (identify the family, check nomoreransom.org for free decryptors, confirm backup status, assume data was also stolen), notify, then rebuild rather than clean and reset every credential in the organisation. Include a recovery-priority table filled in now, while calm, and a short "should we pay?" section that makes clear this is a Decision Maker call taken with counsel and the insurer, not an IT call. Compromised mailbox: reset and revoke sessions, delete malicious inbox rules, review sign-in logs, find out what the attacker sent, phone every external party they emailed, and call the bank immediately if a payment was diverted; funds can sometimes be recalled in the first 24–48 hours. Lost or stolen device: remote wipe, revoke tokens, police report number for the insurer, and a privacy assessment if the device was unencrypted.
Section 6: Communication templates
Three drafts, adapted on the day: an internal holding statement, an operational-disruption notice for customers and suppliers, and a data-breach notification for legal review. Writing these in advance stops someone improvising a message that admits fault or speculates about cause.
Section 7: Closing and learning
An incident closes when systems are restored, monitoring is quiet for 72 hours, notifications are complete and the Decision Maker signs off. Within ten business days, a one-page post-incident review: what happened, how they got in, what worked, what slowed you down, what it cost, and what changes, owned and dated. Then a 30-minute tabletop exercise every six months, which is also what makes the plan "tested" on your insurance application.
What to leave out
Anything the three people who will use it don't need: threat-intelligence programmes, forensic imaging procedures, regulatory matrices for jurisdictions you don't operate in. If a section wouldn't be read during an incident, it belongs in a policy, not the plan. Thirteen pages is about right.