An Incident Response Plan for a Small Company

NIST's incident response guidance, SP 800-61 Revision 3, was finalized in April 2025 according to NIST's incident response project page, read on 2026-10-17. It ties incident response to the six functions of the NIST Cybersecurity Framework. Govern, Identify and Protect are preparation activities that support incident response but are not part of it. Detect, Respond and Recover are the incident response itself (NIST incident response project).

NIST also maps its older, widely taught phases onto those functions (NIST SP 800-61r3):

NIST notes that revision 3 deliberately leaves out detailed how-to steps, because they "change so often and vary so much across technologies, environments, and organizations" (NIST incident response project). That is a useful hint for small companies: keep the plan about decisions and roles, and put the technical steps in playbooks that are easy to update.

NIST observes that incident response is no longer the job of one team. It depends on many internal and external parties, including leadership, incident handlers, technology staff, legal, human resources, facilities and the owners of affected systems and data (NIST SP 800-61r3). It describes leadership as the group that "may have decision-making authority on high-impact response actions, such as shutting down or rebuilding critical services." It also notes that incident handlers can be on staff, on contract, or available when needed from a provider or partner.

In a company of ten or fifty people, those roles collapse onto a few names. Each needs a backup:

• Incident lead. Runs the response, keeps the timeline, decides what happens next. Usually the most senior technical person.
• Executive decision maker. Approves shutdowns, payments, customer notices and calls to law enforcement. Usually the CEO.
• Technical responders. Contain, investigate and restore. Engineers, plus an outside firm if you have a retainer.
• Communications owner. Drafts every message to staff, customers and partners. Nobody else speaks externally.
• Legal and insurance contact. Decides on notification duties and keeps the insurer informed. Often outside counsel.

Google Cloud's template guide adds external parties to the roles list: external counsel, forensics, public relations and insurance providers (Google Cloud). NIST adds cloud and internet service providers, which share responsibility for incidents on their platforms and should have that division written into contracts. Put the contact details and contract numbers for each in the plan before you need them.

A severity matrix tells people when to wake someone up. Google Cloud's guide calls for definitions that separate an event from an incident from a crisis, and a matrix where it is clear which category each incident falls into (Google Cloud). Fortinet lists severity levels, incident types and definitions among the items every plan should contain (Fortinet).

A simple three-level scheme works for most small companies:

Make declaring an incident cheap. Anyone should be able to call one, and calling a false alarm should cost nothing. It is far better to stand down after an hour than to discover a week later that a "probably nothing" was the start of a breach.

The systems you normally use to coordinate may be the ones under attack. CISA's incident response playbook tells organizations to establish communication channels such as chat rooms and phone bridges and a "method for out-of-band coordination." It also warns against "tipping off" an attacker, giving the examples of submitting malware samples to a public analysis service or emailing users about potentially compromised machines (CISA playbooks).

Fortinet recommends that the roles section include "primary and out-of-band contact information" for every team member (Fortinet). Google Cloud's summary of the NIST guidance lists the pieces of a communications plan: contact information, reporting mechanisms, an issue tracker, a war room and encrypted communications (Google Cloud).

Practical choices for a small company:

• A phone list on paper or in each responder's personal phone, not only in the company directory.
• A backup chat channel on a separate account, set up and tested in advance.
• Pre-written, lawyer-reviewed templates for a staff notice, a customer notice and a regulator notice, with blanks for facts.
• One person approves every external message.

Fortinet suggests choosing playbooks by looking at the risks highest on your risk register, with ransomware and data breach as common starting points. A playbook should name the specific actions for each phase and the person responsible, and the actions can be technical, such as restoring a file server from backup, or non-technical, such as drafting a customer notice (Fortinet). Google Cloud advises developing specific runbooks for the most likely threat scenarios (Google Cloud).

For most small software and service companies, five playbooks cover the bulk of real incidents:

1. Compromised account. Reset the password, revoke sessions and tokens, re-register MFA, review what the account touched.
2. Leaked secret or API key. Rotate the key, deploy the replacement, read the provider's logs from the time of exposure.
3. Ransomware or malware on a device. Disconnect the device from the network without powering it off, preserve it, check backups, restore from a known-good copy.
4. Customer data exposure. Stop the exposure, scope what data and whose, preserve logs, involve legal on notification duties.
5. Payment or invoice fraud. Call the bank immediately, freeze affected accounts, preserve the emails, report to law enforcement.

Each playbook should fit on one page. The CISA playbook's emphasis on collecting and preserving data before cleanup applies to all of them: logs, disk images and emails are much harder to recover after systems are rebuilt (CISA playbooks).

A one-page plan skeleton:

INCIDENT RESPONSE PLAN            Approved by: ______  Date: ______
1. Scope: all company systems, data and accounts, including vendors
2. Roles: Lead / Backup | Executive / Backup | Comms | Legal | Insurer
3. Contacts: phone numbers, backup chat, outside IR firm, bank, counsel
4. Severity: Low / High / Critical with examples and who is called
5. First hour: declare, contain, preserve evidence, start a timeline
6. Playbooks: account, secret, ransomware, data exposure, payment fraud
7. Notices: staff, customer and regulator templates (legal reviewed)
8. After: review within two weeks, update this plan and playbooks
9. Testing: tabletop exercise each quarter, plan review on a fixed schedule

A tabletop exercise is a discussion-based simulation in which key people walk through a hypothetical incident to test their plan and find weaknesses. Sophos describes three formats that scale with effort (Sophos):

• Rapid-fire scenarios need little preparation and run about 10 to 30 minutes, citing ISACA.
• Technical-only scenarios run one to two hours and start from a "seed" event that grows as details are added.
• Full stakeholder scenarios run two to four hours and bring in legal, marketing and HR alongside technical staff.

Sophos also suggests letting teams join at different points in the scenario, the way they would in a real incident, and involving legal when personal data is affected (Sophos).

You do not need to write scenarios from scratch. CISA publishes Tabletop Exercise Packages, each with template objectives, scenarios, discussion questions and planning documents, including cybersecurity scenarios on ransomware, insider threats and phishing (CISA tabletop packages).

A good first exercise for a small company takes 30 minutes: "At 9 a.m. on a Monday, a customer emails to say they received an invoice from us with different bank details." Walk through who notices, who is called, what is checked and what is said. Write down every question nobody could answer. Those are your plan's gaps.

Post-incident review is where the plan improves. Google Cloud's summary of the NIST approach poses the core questions: what happened, when, and which steps by the response team may have impeded recovery (Google Cloud). NIST's current guidance maps post-incident activity to the Improvement category of the Identify function, so findings feed back into preparation rather than sitting in a report (NIST SP 800-61r3).

Fortinet recommends a "bi-annual review of the plan" and a review after each major incident (Fortinet). Keep the review blameless and short:

1. Build a timeline from the logs and chat history.
2. List what went well and what slowed the response.
3. Pick a small number of changes, each with an owner and a date.
4. Update the plan, the playbooks and the contact list.

The contact list goes stale fastest. Check it at every review, and whenever someone in a named role leaves.