Incident response plan for small business: a checklist

An incident response plan is a short written guide that tells your team what to do when something goes wrong with your systems or data. It names who is in charge, what to do first and who must hear about it. A small business can write a useful one in a single afternoon. Without it, people lose time arguing while the damage grows.

What an incident response plan covers

An incident is any event that harms, or could harm, your systems or data. A stolen laptop counts. So does a staff email account that a stranger now controls. So does a file that has been locked by ransomware.

Your plan should fit on two pages. It needs five parts: the people involved, how you spot a problem, what you do first, who you tell, and how you learn from it afterward. Write each part in plain words. If a new hire cannot follow it, rewrite it.

In April 2025, the US standards body NIST published a new version of its incident response guide, SP 800-61 Revision 3. It replaced the 2012 edition. Its main idea is useful for any size of firm: incident response is not a separate project. It is part of how you manage risk every day. Prepare before trouble, reduce how often it happens, and make detection, response and recovery faster.

Source: NIST, "Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile", SP 800-61 Revision 3, April 2025, csrc.nist.gov/pubs/sp/800/61/r3/final.

Name the people and their jobs

Pick one incident lead. This person makes the calls and keeps a clock running. In a small firm it is often the owner or the operations manager. Pick a backup too, because the lead will be on holiday on the worst day.

Then list the other roles. You may not have a person for each one, so one person can wear two hats.

Technical contact: your IT staff member or outside provider. They check systems and cut off access.
Communications contact: the person who speaks to staff, customers and the press. Everyone else stays quiet.
Records keeper: writes down what happened, when, and who did what.
Decision maker for money and legal calls: usually the owner or a director.

Write names, mobile numbers and a backup way to reach each person. Do not store this list only on the systems that might be down. Print it. Keep a copy in a drawer and a copy with your lead.

Source: NIST SP 800-61 Revision 3, April 2025, on preparing for incident response as part of risk management, csrc.nist.gov/pubs/sp/800/61/r3/final.

Know what to watch for

You cannot respond to what you do not see. Tell staff what warning signs look like, and tell them it is fine to report a false alarm. Fear of blame keeps problems hidden.

Common signs include these:

A staff member cannot log in, or sees a password reset they did not ask for.
Files will not open, or their names have changed.
A customer says they got a strange email or invoice that appears to come from you.
A bank or payment partner reports a payment sent to an account you do not know.
A laptop or phone with business data is lost or stolen.

Give staff one simple way to report: one phone number and one email address that is checked all day. Test it once a quarter by asking a person to send a pretend report and seeing how long it takes to reach your lead.

Source: NIST SP 800-61 Revision 3, April 2025, on detection as one part of the incident response cycle, csrc.nist.gov/pubs/sp/800/61/r3/final.

The first hour: contain, record, call

The first hour is about stopping the spread and keeping clear notes. It is not about finding the full cause. That comes later. Use this order.

Start the log. Write the time you learned of the problem and what you saw. Keep adding to it.
Call the incident lead. They take charge and confirm the roles.
Contain it. Disconnect the affected computer from the network. Turn off its Wi-Fi or unplug the cable. Do not wipe it or restart it unless your technical contact says so, because that can destroy clues.
Lock accounts. Change passwords on affected accounts from a clean device. Sign out all active sessions. Turn on two-step login if it is off.
Protect your backups. Check that backups are not connected to the affected machines and have not been touched.
Decide who needs to know. Use the list in the next section.

Source: NIST SP 800-61 Revision 3, April 2025, on response and recovery as parts of the same cycle, csrc.nist.gov/pubs/sp/800/61/r3/final.

Decide who to notify

Make a short list of people you may have to tell, and write down who decides. Your list will differ by business, but it usually has these groups.

Your own staff: tell them what to do and what not to do, such as not opening certain files.
Your bank and payment providers: call them fast if money or card details may be involved.
Your insurer: many cyber policies require quick notice. Read yours now and write the deadline in the plan.
Customers and partners: tell them if their data may be affected, in plain words, with clear next steps.
The data protection regulator and the police: some places require you to report certain data breaches within a set number of days.

The rules on reporting differ from one country to the next. Ask a lawyer or check your regulator's website for your market before an incident happens, then write the deadline and the contact in your plan. Do not guess in the middle of a crisis. Keep your messages short, true and free of blame. Say what happened, what data may be involved, what you are doing and what people should do.

Source: NIST SP 800-61 Revision 3, April 2025, which treats communication and coordination as part of incident response, csrc.nist.gov/pubs/sp/800/61/r3/final.

Review and practice

When the incident is over, hold a review within a week or two. Keep it calm and about facts. Ask four questions. What happened? What worked? What slowed us down? What will we change? Write the answers down and give each change an owner and a date.

Then update the plan. A plan that stays the same after an incident is a plan that did not learn anything. Also update it when staff change, when you add a new tool, or when you move to a new office or cloud service.

Practice once or twice a year. Pick a simple story, such as a staff laptop lost on a train, and walk through the plan around a table in 30 minutes. You will find gaps fast: a phone number that is out of date, a role nobody owns, a backup nobody has tested. Fixing them on a quiet day costs almost nothing.

Source: NIST SP 800-61 Revision 3, April 2025, on improving response through lessons learned, csrc.nist.gov/pubs/sp/800/61/r3/final.