How to Build an Incident Response Runbook for Your Company

More than two-thirds of ransomware incidents now hit organizations with fewer than 500 employees, and phishing remains the entry point in most of them. A significant share of companies still lack a fully documented incident response plan, and among small and mid-sized businesses, the share operating with nothing written down at all is even higher. That gap is not a staffing problem. It is a documentation problem, and unlike headcount or budget, documentation is something any founder or ops lead can fix this quarter.

An MSP building runbooks for dozens of clients does not write a separate document from scratch for each one. The practical structure is a master template built on the four NIST SP 800-61 Rev. 3 phases, with a small set of clearly marked variable fields: the client's specific tooling, escalation contacts by name, regulatory requirements such as HIPAA or PCI DSS, and any contract-defined notification timelines. Each client's runbook is then an instance of that template with those fields populated, not a wholly independent document. Metadata at the top of every instance carries a "Last Verified" date and a named owner, so both the MSP and the client can tell at a glance whether the document reflects the current environment; when a client changes a tool or adds a compliance requirement, only the relevant fields in their instance get updated, not the entire template rebuilt from nothing.

What a runbook actually is, and how it differs from a plan or a playbook

Three terms get thrown around as if they mean the same thing, and they don't. An Incident Response Plan (IRP) is the broad strategy document: policies, goals, the overall philosophy of how the organization handles security events. A playbook sits one level down. It's the strategic guide for a category of incident, laying out roles, communication paths, and escalation triggers, and it links out to the specific runbooks a responder needs. A runbook is the tactical layer underneath both: the step-by-step checklist for one specific scenario, written with enough detail that someone who has never touched the system before can execute it correctly at three in the morning.

The distinction matters practically, not just semantically. A playbook orchestrates the whole response, telling a team what to do when payment processing fails. The runbook it points to is the technical procedure: how to restart the payment service, in what order, and what to check before declaring it fixed.

A common mistake is treating a checklist as a runbook. A checklist confirms that tasks got done. A runbook does more: it defines sequencing, dependencies, and decision points, particularly where a containment action might disrupt the business it's meant to protect. Disconnecting a compromised server sounds simple until that server also runs the customer-facing database. Good runbooks anticipate that tension instead of leaving it for the responder to discover live.

Format follows from function here. Long prose blocks don't survive contact with a live incident, so the best runbooks lean on checklists, decision trees, and commands that can be copied and pasted directly into a terminal without editing.

The governing reference for all of this is NIST SP 800-61 Revision 3, published in April 2025. It reorganizes incident response around the NIST Cybersecurity Framework 2.0 functions, and its core phases — Preparation, Detection and Analysis, Containment/Eradication/Recovery, and Post-Incident Activity — remain the practical skeleton most organizations use. That alignment matters for smaller organizations specifically, because it makes the standard usable without a dedicated security operations center translating it first.

The four NIST phases as the skeleton of your runbook

NIST SP 800-61 Rev. 3 was built to integrate into general business risk processes, not just security teams, which is exactly why it works as a foundation for organizations that don't have one.

Preparation is the phase that determines whether everything downstream works or falls apart. Skip it, and the rest of the response is pure improvisation. Preparation starts with defining what actually counts as an incident for your organization, because different teams define incidents differently, and that ambiguity costs real time once something is actually happening. It also means assigning roles and escalation paths before there's a crisis to escalate, and identifying who outside IT belongs in the response: HR for internal communication, legal for disclosure obligations and liability, customer support for anything that reaches users.

Detection and Analysis is where the runbook has to say, in specific terms, what triggers it. Vague triggers produce vague responses. This section needs the actual metrics, logs, or signals that define both the incident type and its severity, along with the steps for determining urgency and impact before anyone escalates further up the chain.

Containment, Eradication, and Recovery is the action sequence, and it splits into two containment modes. Short-term containment means immediate isolation, disconnecting an affected system before it spreads further. Long-term containment means fully sanitizing the environment before anything gets restored. Eradication removes the threat itself; recovery restores normal function and verifies it actually works. One caution from operational practice deserves its own line: never attempt to clean a suspected compromised host. Deploy a known clean instance instead, and preserve forensic snapshots first, because that evidence matters later for legal review and for understanding how the compromise happened in the first place.

Post-Incident Activity is the phase almost everyone skips, usually because the crisis feels over and there's a business to get back to. That's a mistake. This phase is a formal review to find the gaps the incident exposed, feeding lessons back into updated runbooks, training, and tooling. NIST recommends reviewing and updating plans at least annually, and more often whenever the threat landscape or the business itself shifts meaningfully.

These four phases aren't bureaucratic overhead. They map directly onto the sections every working runbook needs.

The core components that belong in every runbook

Every runbook needs metadata at the top, plainly: a "Last Verified" date and a named owner, so anyone opening the document during an incident knows instantly whether they're looking at something current or something abandoned two reorgs ago.

Below that sits the incident identification criteria: the specific log entries, alert types, or user reports that trigger this particular runbook, along with the severity level it's built to handle. Then come the step-by-step response procedures themselves, ordered and unambiguous, written so a first-time responder can follow them without needing to interrupt someone else to ask what a step means.

Escalation paths need named contacts, not job titles someone has to look up mid-crisis. Explicit rules should state when to alert senior staff, legal, or executives, including backup contacts for anything that happens outside business hours. Clear criteria here cut both ways: they stop responders from waking up an executive over a minor issue, and they stop a genuinely serious incident from sitting unescalated because nobody was sure it qualified.

Pre-written communication templates belong in the runbook too, drafted well before anyone needs them. Status updates for internal stakeholders, messages for customers, all written in advance so the person sending them isn't composing prose from scratch while the incident is still active.

A dedicated incident channel matters as much as the technical steps. Whether that's a Slack channel or a video bridge, it needs a name and a location separate from normal day-to-day channels, and if there's any chance the primary messaging platform itself is compromised, the runbook should name a verified alternative, a Signal group, for instance, in advance.

Before anyone closes the incident, the runbook needs verification steps confirming the system is genuinely functional again, along with a record of what actions were taken, when, and by whom.

And on format: decision trees beat prose, commands should be copy-pasteable, and any command that changes system state or carries a side effect needs an explicit callout. Nobody should discover that a step deletes data by running it.

Who owns what when there is no security team

Four roles cover most of what a small organization needs, and none of them require a dedicated security hire.

The Incident Commander coordinates the overall response: makes the escalation and communication calls, tracks the timeline, and does not get pulled into hands-on troubleshooting. The Technical Lead owns diagnosis and remediation. The Communications Lead updates the status page, handles anything customer-facing, and keeps internal stakeholders informed. For major incidents, a Scribe records every action taken, who took it, and when, which becomes the raw material for the post-incident review later.

Ownership of the runbook document itself follows a similar logic. Service teams own the runbooks for their own applications; IT or operations owns anything touching shared infrastructure. Beyond that, ownership should be collective in practice: anyone who spots an error in a runbook should be empowered to fix it on the spot. Waiting for the original author to make the correction just creates a single point of failure, and that person might be on vacation, or might have left the company entirely.

Cross-functional roles need defining in advance too. HR handles internal communication and supports affected employees. Legal manages disclosure obligations and liability documentation. Customer support needs scripted responses ready well before an incident, not drafted live while customers are already asking questions.

Practically, this means the runbook lists actual names, or at minimum named roles paired with backup contacts, never a generic title that requires someone to go hunting through an org chart while the clock is running.

How should an MSP build one runbook template system that works across dozens of clients with different tools, contracts, and regulatory requirements?

Building a full library from nothing is the wrong goal, and it's the reason most of these projects stall before they start. Two or three scenarios are enough to begin, chosen for frequency or damage potential, not comprehensiveness.

High-frequency candidates are scenarios your team has already encountered or is most likely to face first. High-impact candidates include ransomware containment, data exfiltration, and compromise through a third-party integration. Each has a recognizable shape once written out. A phishing-led account takeover runbook tells the service desk how to verify the report, disable access, preserve logs, and notify whoever owns that identity. A ransomware containment runbook defines the order of operations: isolate endpoints, preserve forensic artifacts, then activate legal and communications roles, in that sequence.

Writing style decides whether the runbook actually gets used under pressure. Write for a new employee, not for the person who already knows the system, because the curse of knowledge makes authors assume context that a stressed responder simply won't have at three in the morning. Give each runbook one purpose; if it starts sprouting too many decision branches, split it into two. Keep it scannable: numbered steps instead of paragraphs, links to dashboards and scripts rather than pasting them inline where they'll go stale.

Location matters as much as content. Runbooks need to live somewhere central and accessible to everyone who might need them, and alerts should link directly to the relevant runbook so an on-call responder isn't searching a wiki while the incident is unfolding.

The real build process happens through use. Execute runbooks during actual incidents, note what didn't work, and update the document immediately afterward, because the post-incident review is the primary maintenance mechanism, not a separate project. Updates should also happen whenever system architecture changes, and on a scheduled quarterly review regardless of whether anything went wrong.

Testing the runbook before an incident forces the issue

A runbook can read as complete and still fail the moment someone actually tries to follow it. That's not a hypothetical risk; it's the documented pattern behind a lot of failed incident responses. Manual reconstruction after the fact, piecing together what happened from chat logs and monitoring dashboards, wastes 60 to 90 minutes per incident according to research from incident.io. Testing in advance surfaces those gaps before they cost anyone that time.

Two methods work well and don't require much overhead. The first is a new-hire test: hand the runbook to someone recently onboarded and have them attempt to follow it on a clean machine. Missing access permissions, broken links, and unstated assumptions surface almost immediately, because a newcomer has none of the tribal knowledge that lets an old hand paper over a gap without noticing it.

The second is a tabletop exercise: a cross-functional walk-through of a simulated scenario, ransomware, a phishing campaign, a DNS hijack, bringing IT, legal, customer support, and leadership into the same room to rehearse coordination, not just the technical steps. A tabletop reveals things a desk review never will: who actually holds access to what system, where an escalation path quietly breaks down, whether the communication templates make sense to the person who'll actually be sending them.

Testing should happen at minimum before a runbook gets declared ready for use, then on a recurring basis afterward, at least annually per NIST's guidance, and more often if the environment shifts significantly. The financial case for testing is well documented: organizations that invest in regular incident response preparation consistently show lower breach costs, which turns testing from a compliance checkbox into a line item with a real financial case behind it.

After every test, update the runbook immediately, and note who ran the test and when. That's what makes the "Last Verified" date at the top of the document mean something instead of just sitting there as decoration.

Keeping runbooks current as the threat environment and your organization change

Runbooks go stale in three distinct ways, and it helps to name them separately instead of lumping them together. The threat itself changes, AI-generated phishing and deepfake social engineering look nothing like the attacks a runbook might have been written against a few years ago. The system changes, new tools, new integrations, personnel turnover that quietly invalidates an escalation contact. And the organization changes, a new product line, a new compliance requirement that didn't exist when the document was first drafted.

Three maintenance triggers keep pace with that drift. Update after every incident, based on what the scribe recorded and what the post-incident review surfaces. Update after any significant change to architecture or tooling. And update on a scheduled quarterly review, whether or not anything happened in between.

Governance works best when it's distributed rather than centralized on one person. Post-incident updates should fall to the on-call responder who lived through it, then get reviewed by someone else. Mock exercise updates should rotate through the team so the burden, and the institutional knowledge, doesn't concentrate in a single individual.

There's a compliance dimension worth stating plainly. SOC 2 Type II, under its CC7.3 control, and ISO 27001 both require documented incident response procedures with evidence of periodic evaluation. A runbook that's actually maintained, tested, and timestamped satisfies that requirement directly, without generating a second layer of paperwork just to prove it happened.

Integrated platforms combining device management, endpoint security, and identity protection can help here too, by surfacing the live signals a runbook's detection criteria depend on. Continuous enforcement keeps those triggers calibrated against real data instead of a static assumption written once and never revisited.

The deeper value of all this is institutional memory. When the person who wrote a runbook leaves the company, and eventually they will, the organization keeps what they knew, provided the document got updated along the way instead of quietly abandoned. That's the actual return on the effort: not a single well-written document, but one that keeps being true.