The incident response plan a small B2B team will actually use

Picture 2 a.m. on a Tuesday. Your on-call engineer sees a ransom note on every screen and a 48-hour deadline. Who decides whether production goes offline? Who calls the lawyer, the insurer, your largest customer? If the answer is "whoever's awake in the group chat," you don't have an incident response plan.

You're not alone. In the UK government's Cyber Security Breaches Survey 2025/2026, a mostly telephone survey of 2,112 UK businesses run by Ipsos for DSIT and the Home Office, only 25% had a formal incident response plan; among medium businesses (50 to 249 employees), 57% did. The survey's 44 follow-up interviews found plans "largely untested or incomplete." One small business put it plainly: "The incident response plan is in the staff handbook but we haven't tested it at all."

The fix for a team of 20 to 500 isn't a 40-page binder. It's a one-page plan and one 90-minute tabletop exercise.

Why does a small B2B company need an incident response plan?

Because ransomware doesn't need you to be big. Verizon's 2026 Data Breach Investigations Report analyzed more than 22,000 confirmed breaches from November 2024 to October 2025 and found ransomware in 48% of them, up from 44%. Among ransomware cases where the victim's size was known, about 96% hit small and medium-sized businesses. Verizon counts anything under 1,000 employees as an SMB, a wider bucket than a 60-person startup, and it describes crews casting wide nets and hitting whoever had compromised credentials or unpatched edge devices.

Incidents also run longer than most plans assume. NIST's incident response guide, SP 800-61 Revision 3 (April 2025), replaced a life-cycle model built for a time when response and recovery "was usually completed within a day or two." Today, NIST writes, recovery "often takes weeks or months." A plan that stops at technical triage misses most of the incident.

What goes in a one-page incident response plan?

CISA's Incident Response Plan Basics fact sheet (January 2024) sets the bar: a written document, approved by senior leadership, that clarifies roles, guides key activities, and lists the people you'll need. Six sections cover it.

1. Who runs it. Name an incident manager and a backup. Per CISA, the incident manager leads, manages communication, delegates, and "does not perform any technical duties." They watch the clock, because people lose track of time under pressure. At a 40-person company, pick the COO, not the CTO, who'll be needed at a keyboard. Add a technical lead and a communications lead.
2. Who makes the big calls. Taking production offline, forcing every credential reset, paying or refusing a ransom. NIST notes leadership may hold authority over high-impact actions "such as shutting down or rebuilding critical services." Write down who decides alone and who must be reached first. On ransom, one data point: 69% of ransomware victims in Verizon's dataset didn't pay.
3. Who calls whom. CISA recommends reviewing the plan with an attorney and choosing an outside investigation firm in advance. If you carry cyber insurance, read the notice clause now and check which firms the policy will pay for. Add your critical vendors: Verizon found third-party involvement in 48% of breaches. Names and phone numbers, not job titles.
4. Who talks to customers. The communications lead holds a pre-drafted holding statement and the list of accounts whose contracts or DPAs carry notification terms. Deadlines depend on where you operate and what you signed, and counsel keeps that list. One example: under GDPR (EU), a processor must notify the controller "without undue delay" after becoming aware of a personal data breach. Whether GDPR applies to you is a question for counsel.
5. What gets preserved. Logs, disk images, and a timeline of who did what. NIST says to preserve the integrity and provenance of investigation records, and treats incident data as evidence even when nobody gets prosecuted. Wiping and rebuilding fast destroys what you need to work out what happened.
6. What gets shut off. Kill switches, written as steps: revoke sessions, rotate API keys and cloud credentials, disable compromised accounts, isolate hosts, restore from tested backups. NIST adds: check backups for signs of compromise before restoring.

Then print it. CISA means that literally: email, chat, and document storage may be down during an incident.

How do you run your first tabletop exercise?

A tabletop is a facilitated role-play: someone reads a scenario out in stages, and the team talks through its response. CISA publishes more than 100 tabletop exercise packages with template objectives, scenarios, and discussion questions, including ransomware, insider threat, and vendor supply chain compromise, as editable Word documents.

CISA's ransomware package runs about three hours: a 20-minute briefing, two 60-minute modules with a break, and a 20-minute hotwash. For a first run, we'd cut it to 90 minutes and play the second module, the one that tests the plan:

• Inject 1 (10 minutes). After hours, monitoring flags unusual DNS traffic and a large outflow of data from HR machines. Who gets paged, and who declares an incident?
• Inject 2 (25 minutes). Ransom notes on every screen, payment due in 48 hours. Who decides on shutdown and payment? Who calls counsel and the insurer?
• Inject 3 (20 minutes). A researcher says a criminal group is offering your data for sale. What do you preserve, and what do you tell customers?
• Inject 4 (15 minutes). Reporters call. Who answers, with what statement?
• Hotwash (20 minutes). What broke, who owns each fix, by when.

Keep it no-fault, as CISA's package instructs, with a note-taker who isn't playing. Invite everyone the plan names, including whoever owns your largest accounts. The output that matters: three to five fixes, each with an owner and a date.

How often should you update the plan?

CISA says quarterly, a sensible rhythm for a company that ships weekly. Also after every real incident and every tabletop, in a blameless retrospective: incidents are "almost always the result of a failure of the overall system," in CISA's words. A new cloud provider, a new enterprise customer with notification terms, or someone on the contact list leaving should trigger an update too.

If you're working toward SOC 2, incident response is one of the controls it shares with ISO 27001. Write the plan once and keep the tabletop notes: a dated record of practice is easier to show than to reconstruct.

Who owns the plan?

It reads like a security document, but it pulls in three practices. Build owns the technical half: centralized logs that survive the incident, backups with restore drills, kill-switch runbooks. Advisory, often through a fractional CISO, owns the plan, the decision rights, and what the board hears. Sales feels it first, because the communications lead needs the account list and the contract terms. Secure is where they meet, which is why we'd run the tabletop with all three in the room. The Secure dimension of the DGTL Readiness Index includes incident response maturity. See the framework.

Related: SOC 2 without the pain → · SOC 2 and ISO 27001 → · Fractional CTO, CMO, and CISO →