When a security incident hits a small or medium-sized business, the difference between a bad afternoon and a business-ending event usually comes down to one thing: whether someone wrote the plan down before the phones started ringing. You don't need a 200-page playbook to be ready. You need a short, clear document that your team can actually follow at 2 a.m.

Start with the four questions

Every SMB incident response plan should answer four questions in plain language:

  • Who decides? Name a single incident lead and a backup. Not a committee.
  • Who do we call? Your IT provider, your cyber insurance carrier, your attorney, and law enforcement if needed. Numbers on one page.
  • What do we shut down? Know which systems to isolate first - usually email, file shares, and any system with customer data.
  • What do we tell people? Draft holding statements now for staff, customers, and regulators. You will not write good ones during a crisis.

The six phases, simplified

The standard NIST framework has six phases, and they map cleanly to SMB reality:

  1. Prepare - write the plan, train the team, run one tabletop exercise a year.
  2. Identify - know how alerts reach you. Endpoint detection, email flags, or a staff member noticing something odd.
  3. Contain - disconnect the affected machine from the network. Do not power it off; you lose forensic evidence.
  4. Eradicate - remove the threat with help from your IT provider or an incident response firm.
  5. Recover - restore from clean backups. Verify integrity before reconnecting.
  6. Learn - write a short post-incident review. What worked, what didn't, what changes.

The tabletop exercise

Once a year, gather your leadership team for ninety minutes. Present a realistic scenario - a ransomware note on the accounting workstation, or a phishing email that captured the CFO's credentials - and walk through the plan out loud. You will find gaps every single time. That is the point.

Key takeaways

  • A one-page plan that people follow beats a fifty-page plan that lives in a shared drive.
  • Name a decision-maker before the incident, not during it.
  • Test the plan at least once a year with a tabletop exercise.
  • Keep contact information printed on paper - you may not have access to your systems.