What a Security Incident Response Plan Actually Needs to Include

Most growing companies find out they don't have a real incident response plan at the worst possible moment: an hour into an active incident, when someone finally asks who's supposed to be making decisions. By then the questions that should have been answered weeks earlier, who has authority to take a system offline, who calls the client, who calls counsel, are being improvised in real time. A written plan doesn't prevent every incident. It's what keeps a bad day from turning into a bad quarter.

What an Incident Response Plan Actually Is

The Cybersecurity and Infrastructure Security Agency (CISA) defines an incident response plan as a written document, formally approved by senior leadership, that guides an organization before, during, and after a confirmed or suspected security incident. That definition matters because it rules out two things people often mistake for a plan.

The first is a purely technical runbook: a list of steps for isolating a compromised server, with no mention of who decides to pull the trigger or who tells the client. The second is a policy document that describes intentions ("we will respond promptly to security incidents") without describing mechanics. A real plan names people, defines authority, and specifies what happens in what order, so that decisions during an incident are executions of a plan rather than negotiations under pressure.

The Four Phases Every Plan Is Built Around

The National Institute of Standards and Technology's Computer Security Incident Handling Guide (SP 800-61) has defined the standard incident response lifecycle for over a decade, and it still anchors how most organizations structure a plan:

Preparation. Building the plan itself, training staff, and putting monitoring and access controls in place before anything happens.
Detection and analysis. Identifying that an incident is occurring and scoping what's actually affected.
Containment, eradication, and recovery. Stopping the incident from spreading, removing the cause, and restoring normal operations.
Post-incident activity. Reviewing what happened and updating the plan based on what was learned.

NIST released a major update to this guidance in April 2025 (SP 800-61 Revision 3), which reframes incident response around its broader Cybersecurity Framework 2.0 rather than treating it as a standalone technical process. The practical shift is a stronger emphasis on incident response as continuous risk management, woven into how the organization already governs, protects, and monitors its systems, rather than a bolt-on procedure that only gets attention during a live event. For a growing company, the four-phase structure is still the right way to organize a plan. The 2025 update is a reminder that the plan needs to connect to how the business actually manages risk day to day, not sit in a folder until it's needed.

Who Needs to Be Named Before Anything Breaks

CISA's incident response planning guidance is specific about roles, because vague ownership is one of the most common reasons plans fail under pressure. At minimum, a plan needs:

An incident manager, who has the authority to make and enforce decisions during an active incident, including the decision to take systems offline.
A technical lead, who directs the actual containment and recovery work.
A communications lead, who owns internal updates and any external notifications, so that clients and employees aren't hearing conflicting information from different people.
Legal counsel, identified in advance, not found for the first time after an incident starts. Breach notification laws vary by state and by the type of data involved, and figuring out which ones apply while an incident is still active costs time the organization doesn't have.
A pre-built notification list covering people who won't be top of mind mid-incident: board members, key investors, and critical vendors or partners whose own operations depend on yours.

What a Plan Actually Needs to Include

Beyond naming roles, a written plan needs to cover a specific set of ground. This is the checklist a growing company can hold itself to.

Plan Element	What It Actually Covers
Roles and ownership	Named incident, technical, and communications leads, not "the IT team will handle it"
Communication plan	A pre-built contact list for the board, investors, and key vendors, built before an incident, not during one
Legal and regulatory steps	Counsel and notification deadlines identified in advance, specific to your states and data types
Technical response phases	Preparation, detection and analysis, containment and recovery, and post-incident review
Staff training	Every employee knows how to recognize and report a suspected incident, not just IT
Post-incident review	A structured retrospective that updates the plan itself, not a one-time debrief

None of these elements are unusual or difficult to write down individually. What's actually rare, especially among companies in Elevaire's 25 to 200 employee range, is having all six documented, current, and reviewed on a regular cadence rather than written once and forgotten.

The Real Cost of Not Having One

The financial case for a tested plan has gotten sharper. IBM's 2025 Cost of a Data Breach Report found that a tested incident response plan was the single largest cost-reducing factor a company could have in place, saving an average of $2.66 million per breach, ahead of extensive use of AI and automation ($1.9 million saved) and zero-trust architecture ($1.76 million saved). The prior year's edition of the same report found that organizations with an incident response team and a regularly tested plan had an average breach cost of $3.26 million, compared to $5.29 million for organizations with neither, a 58% difference.

Speed matters as much as preparation. IBM's 2025 data put the average time to identify and contain a breach at 241 days, the lowest figure in nine years, credited largely to faster detection tooling. Organizations without a tested plan and a practiced team take meaningfully longer to reach that point, and every additional day a breach goes uncontained adds to both direct cost and reputational exposure.

The headline global average cost of a breach was $4.44 million in IBM's 2025 report, down from $4.88 million the year before. That decline is a global average across every company size and every industry, and it should be read with real caution: it isn't a specific figure for a 25 to 200 employee company, and U.S. breach costs moved in the opposite direction, reaching a record $10.22 million on average in the same report. The consistent finding across both years, and the one most relevant here, isn't the exact dollar figure. It's that having a plan and testing it produces a large, repeated, measurable cost reduction.

Where Third Parties Fit Into This

Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year over year, from 15% to 30%. A growing company's incident response plan can't stop at its own walls. It needs to account for what happens when a vendor, contractor, or software provider is the source of an incident, including who's responsible for coordinating with that vendor and how the notification obligations change when customer data was exposed through a third party rather than directly.

This is also where the plan needs to be explicit about how your managed service provider fits in. Your MSP handles day-to-day infrastructure, patching, and helpdesk support, and that operational relationship is essential during an incident: they're often the ones with direct access to the systems that need to be contained. What an MSP relationship typically doesn't include is ownership of the plan itself: who has authority to make the call to take a system offline, who talks to the board, who manages the legal notification timeline. Fractional IT leadership is built to own that layer, working alongside the MSP rather than replacing what it already does well, so the plan has both technical execution and clear decision-making authority in place before it's needed.

The Cyber Insurance Angle

Cyber insurance underwriting has shifted from taking an applicant's word for its security posture to asking for evidence. A written incident response plan, ideally with documentation of a recent tabletop exercise or test, has become one of the small set of baseline controls underwriters now expect alongside multi-factor authentication, endpoint detection and response, and tested backups. Carriers are also more willing than they used to be to scrutinize claims after the fact, and a gap between what an organization attested to during underwriting and what was actually in place at the time of a breach is a real basis for a denied claim. A plan that exists on paper only, and hasn't been tested, doesn't close that gap.

Frequently Asked Questions

How much does it cost to build a formal incident response plan?

For a company in the 25 to 200 employee range, building a plan from scratch typically involves a readiness assessment, plan documentation, and at least one tabletop exercise to test it, work that a fractional IT leader can usually complete in a matter of weeks rather than months. The ongoing cost is mostly time: a plan needs to be reviewed and re-tested at least annually, and updated any time the organization's systems, vendors, or leadership team change materially.

Does our MSP already have an incident response plan for us?

Usually not in the sense that matters. Your MSP may have internal procedures for handling technical issues on your systems, but a real incident response plan requires named decision-making authority, a legal notification process, and a communications plan that sits above what most MSP contracts are scoped to own. Fractional IT leadership is designed to build and own that layer while your MSP continues handling day-to-day infrastructure.

How is this different from just having cyber insurance?

Cyber insurance helps cover the financial impact of an incident after it happens. An incident response plan is what determines how well the incident itself is handled, how quickly it's contained, how accurately it's communicated, and whether legal obligations are met on time. Increasingly, having a tested plan is also a condition insurers expect to see before they'll underwrite a policy at all.

How often should the plan be tested or updated?

At least once a year, and after any material change: a new critical vendor, a leadership change in one of the named response roles, or a shift in what data the company handles. A plan that hasn't been tested in over a year is a plan nobody can be confident will actually work when it's needed.

Do we need a different plan for ransomware specifically?

The core plan structure, roles, communication process, legal steps, and technical phases, stays the same. What changes with ransomware is the decision tree around specific questions: whether to engage law enforcement, whether backups are actually clean and restorable, and who has authority to make a call about payment. Those decisions are worth thinking through in advance rather than during an active ransomware event, when the pressure to decide quickly is highest.

How do we get started if we don't have anything documented today?

Start with a readiness assessment that maps what you actually have today, incident response related or not, against the core elements above: named roles, a communication plan, legal steps, and a testing cadence. That assessment tells you exactly which of those elements already exist informally and which need to be built and documented from the ground up, which is the input any realistic plan and timeline depends on.