An incident response plan a five-person team will follow

Most incident response plan templates are written for a company with a security team. They have an incident commander, a communications lead, a legal department, and a forensics firm on retainer. At five people, those are the same two or three people, and a forty-page plan that nobody has read will not get opened on the day it is needed.

This guide builds a plan that fits on one page, from NIST’s current incident response guidance, with a template to copy and a 30-minute way to test it. No plan stops an incident from happening, and nothing here is legal advice. What a plan does is settle the questions ahead of time: who leads, who decides, who gets told. On the day, the only new problem is the incident itself.

Policy, plan, and playbook

Three documents get called the same thing. They do different jobs.

• The policy says what you require of yourself. Our guide to the first five security policies covers it. NIST’s list of what most incident response policies include has one line a small team tends to skip: which roles have “the authority to confiscate, disconnect, or shut down technology assets.”
• The plan is what this guide is about. NIST calls it “the roadmap for implementing the incident response capability” (ID.IM-04): who does what, how, and in what order.
• Playbooks are step lists for one kind of incident. In NIST’s words, they “provide actionable steps or tasks for people to perform during various scenarios or situations.” You don’t need them on day one. Start with the plan, and add a playbook later for one of “the most common types of incidents and threats” you are likely to face.

What changed in NIST’s guidance

Many templates organize the plan around four phases: preparation; detection and analysis; containment, eradication, and recovery; and post-incident activity. That cycle comes from NIST SP 800-61 Revision 2, from 2012. Revision 3, published in April 2025, supersedes it and organizes its guidance around the six functions of the NIST Cybersecurity Framework 2.0. It explains that the old cycle fit a time when “incidents were relatively rare” and response and recovery “was usually completed within a day or two.”

It does not tell you to throw the old phases out. “Organizations should use the incident response life cycle framework or model that suits them best.” For a five-person team, the four phases are still a fine outline. What matters more is that the plan names people and decisions, which is what the rest of this guide does.

The plan, section by section

Eight sections. The structure follows NIST; the examples, the numbers, and the order are our judgment for a team of about five.

1. What counts as an incident

NIST’s definition is broad: an occurrence that “actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies.” In plainer words: anything that puts your data or systems at risk, or breaks your own rules. At a small software company, that looks like:

• a laptop with access to company systems is lost or stolen;
• a password, API key, or token turns up where it shouldn’t: a public repository, a chat channel, a support ticket;
• someone signs in to a company account who shouldn’t;
• customer data goes to the wrong person, or sits behind a public link;
• a provider tells you it had an incident that touches your data;
• a stranger writes in to say they found a vulnerability.

The rule to write down: when in doubt, report it. Deciding it was nothing takes a few minutes.

2. How anyone reports one

One place that everyone knows: a chat channel, a phone number, or an email address. Then a second way that doesn’t depend on your main systems, because sometimes email or chat is the thing that was compromised.

Reports also come from outside. NIST says to “have mechanisms in place for third parties to report possible incidents” (RS.MA-02). For a small company, that can be a security address on your website that reaches a named person, not a shared inbox nobody reads.

3. Who leads, and who can pull the plug

NIST’s advice is short: “Consider designating an incident lead for each incident” (RS.MA-01). At five people, write down four jobs and a name for each:

• Incident lead. Runs the response, keeps the log, sets the severity, and decides what happens next.
• Hands-on. Does the technical work: revokes access, rotates keys, restores systems. Usually whoever knows the affected system best.
• Communications. Talks to customers and anyone else outside the company. Often the founder.
• Authority to shut down. Who can take the product offline or cut off an integration. Decide it now, not during the incident.

One person can hold two of these jobs. If you can, keep the lead and the hands-on work apart: someone needs to keep the log and think about who to call while someone else fixes. Name a backup for each job, because the usual person may be on a plane.

Write down the outside help too. NIST notes that incident handlers can be on staff, on contract, or “available when needed” from a provider. For most small teams that means your cloud provider’s support, a lawyer, and, if you carry cyber insurance, whoever your policy tells you to call first.

4. Severity, in three levels

When a report comes in, NIST says to estimate “the severity of the incident and the level of urgency needed to respond to it” (RS.MA-02). Three levels are enough at this size. An example:

• High. Customer data exposed or likely exposed, the product down for customers, or an attacker who may still have access. The response team drops other work, and the founder is told right away.
• Medium. A real problem, contained to internal systems, with no sign that customer data was touched. A stolen laptop with an encrypted disk, or a leaked key that was rotated before anyone used it. Handled the same day.
• Low. Something to check. A phishing email nobody clicked, or a vulnerability report to verify. Handled the next business day.

Pick response times your team can meet. A plan that promises a 15-minute response from a team with nobody on call will be broken the first time it is used, and a customer who reads it will hold you to it.

5. The first hour

1. Open a log. A shared document with times: what you saw, what you did, who you told. NIST says the record can be kept “by many means, including a paper logbook” (RS.AN-06), and warns that “incident response records can contain sensitive information,” so limit who can read it.
2. Contain it. “Containment refers to preventing the expansion of an incident” (RS.MI-01). End the session, rotate the key, disable the account, take the public link down.
3. Keep the evidence. The FTC’s breach guide is blunt: “Do not destroy evidence.” For equipment, it says to “take all affected equipment offline immediately — but don’t turn any machines off until the forensic experts arrive.” For a cloud team, our reading is: export or snapshot the logs and the affected resources before you delete or rebuild anything, and know how long each provider keeps its logs.
4. Set the severity and tell the team who is leading.
5. Call for help if the incident is beyond the team: your provider, your lawyer, your insurer.

6. Who you tell, and who decides what to say

NIST says to notify affected parties “in accordance with regulatory, legal, and contractual requirements” (RS.CO-02). For a small company those come from three places:

• Your contracts. A customer agreement or a data processing agreement may set a deadline for telling the customer. Keep a list of which customers have a notice clause and what it says, so nobody has to search contracts during an incident.
• The law. The FTC’s guide says: “All states, the District of Columbia, Puerto Rico, and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information.” Which laws apply depends on whose data it is and where they live. That is a question for a lawyer, so the plan names one.
• Your own words. Your privacy notice, your security page, and your questionnaire answers may already promise something.

Then decide who writes and who approves: the communications owner drafts, the founder approves, and a lawyer reads anything that may be a breach notice. The FTC’s rule for what goes out: “Don’t make misleading statements about the breach.”

7. Contacts, kept where you can reach them

Everyone on the team, with a mobile number. Your cloud provider’s support and your account ID. Your identity provider, email provider, domain registrar, and payment processor. Your lawyer, and your insurer and policy number if you have one. The security contacts of the customers whose contracts have a notice clause.

Keep a copy outside the systems on the list. If your password manager or your email is what was compromised, you still need the numbers.

8. Recovery, and closing it out

• Check a backup before you restore from it. NIST: “Check restoration assets for indicators of compromise, file corruption, and other integrity issues before use” (RC.RP-03).
• The lead declares the end, so everyone knows the response is over.
• Write a short after-action report. One that “documents the incident itself, the response and recovery actions taken, and lessons learned” (RC.RP-06). At five people, one page within a week, about what happened rather than who to blame.
• Change one thing. In the plan or in the system, so the report leads somewhere.

A one-page template to copy

Fill in the brackets. Each one is a decision for your team; none of them is a number we recommend. NIST’s own advice for any plan is to “base each cybersecurity plan on the organization’s unique requirements, mission, size, structure, and functions” (ID.IM-04).

1. Scope. This plan covers [product], its production systems on [cloud provider], company accounts in [identity provider], and company laptops.
2. Report an incident. Post in [channel]. If that is down, call [phone number]. Outside reports reach [security address], read by [name].
3. Roles. Incident lead: [name], backup [name]. Hands-on: [name], backup [name]. Communications: [name], backup [name]. Authority to take [product] offline: [name].
4. Severity. High: [definition], response [time]. Medium: [definition], response [time]. Low: [definition], response [time].
5. First hour. Open the log at [location]. Contain. Export logs before changing anything. Set the severity. Call for help if needed.
6. Notification. Customer notice terms are listed at [location]. Counsel: [name, phone]. [Name] drafts, [name] approves.
7. Contacts. Kept at [location], with a copy at [location outside company systems].
8. Closing. The lead declares the end. After-action report within [number] days, filed at [location].
9. Review. Reviewed every [interval] and after every High incident. Last reviewed [date] by [name].

The last line matters. NIST says to “review and update all cybersecurity plans periodically or when a need for significant improvements is identified” (ID.IM-04). A plan with last year’s names in it fails on the day you need it.

For a fuller example, the home page has a sample Incident Response Policy and Plan, written for a fictional 14-person company.

Test it in 30 minutes

NIST says exercises “prepare staff and involved third parties … for future incident response activities” (ID.IM-02), and points to its SP 800-84 “for more information on simulations, tabletop discussions, and other forms of exercises.” A tabletop is the cheapest of these: the team on a call, one scenario read aloud, the plan open, no systems touched.

A scenario to start with (fictional):

On a Friday afternoon, a developer finds that a key for your production cloud account was committed to a public repository three days ago.

Walk through it with the plan in front of you:

1. Who is the lead, and where is the log?
2. What do you revoke first, and who has the access to do it?
3. Which logs would show whether the key was used, and do they go back three days?
4. What severity is this, and does it change if the key was used?
5. Does any customer contract require notice? Who checks?
6. Who would write to customers, and who approves it?

Every “we don’t know” is a gap in the plan. Fix one or two that week, and write down the date and what you found. If a customer’s questionnaire asks whether your plan has been tested, that record is your answer.

What a plan doesn’t do

• It doesn’t prevent incidents. It makes the response faster and the decisions calmer.
• It isn’t a promise to customers, unless you share it or put its numbers in a contract. Then a customer may hold you to it, so share only what you meet.
• It doesn’t satisfy SOC 2 by itself. As our policies guide notes, incident response maps to criteria CC7.3 through CC7.5. A document shows what you intend; the log, the after-action reports, and the test notes show what you do.
• If you don’t have one yet and a questionnaire asks, say so. Our guide to answering when you don’t have the control shows how.

If you would rather hand off the writing

Blank Slate Creative, LLC does readiness and documentation only. We never audit or attest. This guide draws on public guidance from NIST and the FTC and on our own judgment, not on client work.

• The five core policies, Incident Response among them. Information Security, Access Control, Incident Response, Acceptable Use, and Data Classification, tailored to your intake answers: your cloud, your identity setup, your team size, and how you work, for a flat $85. Order the five policies, $85.
• A person reads your policies. Each custom policy set is read before it is sent to you. We can’t promise how a customer or an auditor will judge them.
• See it first. The sample policies on the home page are written for a fictional company. We have no client work to show yet, and would rather say so.

Sources

All read on 2026-10-06.

• NIST, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile (April 2025), sections 2.1, 2.2, and 2.3, the Community Profile rows named in the text, and the glossary’s definition of a cybersecurity incident. Read in the NIST PDF.
• Federal Trade Commission, Data Breach Response: A Guide for Business (evidence, equipment, state notification laws, and statements about a breach).