Back to Blog
MSP Operations

Incident Response Plans for MSPs: Building, Testing, and Selling IR Services in 2026

Most MSP clients don't have an incident response plan — and every compliance framework requires one. This guide covers the six-phase IR structure, how to run tabletop exercises, and how to package IR planning as a recurring service.

BC
Brett Coffin
Updated July 20267 min read

Incident Response Plans for MSPs: Building, Testing, and Selling IR Services in 2026

TLDR: Most of your clients don't have an incident response plan — and every compliance framework they're subject to requires one. According to JumpCloud's 2025 research, only 55% of organizations have a fully documented IR plan, and only 30% test it regularly. Organizations without a formal plan pay 58% more per breach on average. This guide covers the six-phase IR structure, what each major framework requires, how to run tabletop exercises that actually stress-test the plan, and how to package this as a recurring MSP service.


When a ransomware attack hits one of your clients at 2 a.m. on a Friday, the question that matters most isn't "do you have backups?" It's "does anyone know what to do next?"

Most organizations don't. According to JumpCloud's incident response research, only 55% of organizations have a fully documented incident response plan — and of those, only 30% test it regularly ([JumpCloud, 2025](https://jumpcloud.com/blog/incident-response-statistics)). The rest are operating on hope and a general sense that someone will figure it out under pressure.

The financial stakes are real. IBM's 2025 Cost of a Data Breach Report pegged the global average breach cost at $4.44 million, with organizations averaging 241 days to detect and contain a breach ([IBM Cost of a Data Breach, 2025](https://www.ibm.com/reports/data-breach)). Organizations without a formal IR plan pay 58% more per breach on average compared to those with structured, tested response protocols ([JumpCloud, 2025](https://jumpcloud.com/blog/incident-response-statistics)).

For MSPs, this creates a clear service opportunity with a compliance mandate behind it. IR plan development isn't just a one-time deliverable — it's the foundation of an ongoing engagement, and every compliance framework your clients operate under requires one.

Every Major Compliance Framework Requires an IR Plan

This is the strongest lever MSPs have when clients ask why they need an incident response plan: it's not optional.

  • **HIPAA** requires covered entities and business associates to implement policies and procedures addressing security incidents — including identifying, responding to, and documenting incidents involving electronic protected health information (ePHI). Workforce training on IR procedures is a separate addressable requirement.
  • **SOC 2** maps to the Availability and Security trust services criteria, which explicitly address incident response procedures, notification timelines, and evidence of documented response activities. SOC 2 Type II auditors want to see that the plan was actually used, not just written.
  • **PCI DSS v4.0**, Requirement 12.10, mandates a comprehensive incident response plan covering roles and responsibilities, contact lists, business recovery procedures, breach notification procedures, and annual testing. Requirement 12.10.2 specifically requires IR testing at least once per year.
  • **NIST CSF 2.0** built an entire function — **Respond** — around incident response, encompassing incident management, analysis, mitigation, and communication. The companion **Recover** function covers restoration and post-incident improvement.
  • **CMMC Level 1 and Level 2** include IR practices derived from NIST SP 800-171 that defense contractors must implement and document.
  • **CIS Controls v8**, Control 17, covers incident response management — a requirement across all three Implementation Groups, from the smallest IG1 organizations up through IG3.

In short: if your client handles any regulated data, they have a compliance obligation to document, test, and maintain an IR plan. That's not a sales pitch — it's the regulatory baseline. For help deciding which frameworks each of your clients falls under, see which compliance framework do your MSP clients actually need?.

NIST SP 800-61 Rev 3: The Updated Standard

In 2024, NIST released a significant update to its foundational incident response guidance: Special Publication 800-61 Revision 3. Unlike Rev 2 (published in 2012), the updated guidance aligns directly with NIST Cybersecurity Framework 2.0 and is designed to be practical for a wider range of organization sizes, including SMBs ([NIST SP 800-61 Rev 3](https://csrc.nist.gov/publications/detail/sp/800-61/rev-3/final)).

Key changes in Rev 3 include:

  • Explicit alignment with the CSF 2.0 Govern, Identify, Protect, Detect, Respond, and Recover functions
  • An outcomes-focused rather than prescriptive approach — defining what should be achieved rather than dictating exact procedures
  • Greater emphasis on coordinating with external stakeholders: law enforcement, CISA, cyber insurance carriers, and legal counsel
  • Recognition that IR planning is a governance function, not just a technical one

For MSPs, this matters because a single IR plan framework — built around NIST SP 800-61 Rev 3 — simultaneously satisfies HIPAA's incident procedures requirement, PCI DSS Requirement 12.10, SOC 2 incident response criteria, and CMMC IR practices. You build the plan once and map it across every framework a client falls under.

The Six Phases of a Client IR Plan

A solid IR plan follows six phases. These map directly to the NIST framework and generate the evidence artifacts compliance auditors expect.

1. Preparation

Document the people, tools, processes, and communication channels needed before an incident occurs. This includes: incident response contacts and escalation paths, asset inventories, documented backup configurations, network diagrams, and pre-authorized legal and forensic vendors. For MSPs, this phase also means defining your contractual role: what you're authorized to do at 2 a.m. without a client call, what requires explicit sign-off, and what triggers escalation to a third-party IR firm.

2. Identification

Define what constitutes an "incident" for each client — and at what threshold it triggers the plan. Not every alert is an incident. Document detection sources (SIEM, EDR, user reports, third-party notifications) and the process for classifying and triaging events. Align thresholds with each client's compliance obligations — HIPAA requires formal breach notification analysis even for small ePHI exposure events, where a risk assessment must determine whether notification is required.

3. Containment

Short-term and long-term containment strategies for different incident types. Ransomware has a different containment playbook than an account compromise or business email compromise event. Document both the decision criteria (when to isolate versus monitor to preserve forensic evidence) and the technical steps (which systems to isolate, how to disconnect without destroying artifacts, how to preserve logs).

4. Eradication

Remove the threat — malware, compromised credentials, backdoors, misconfigurations that enabled the attack — and verify the environment is clean before moving to recovery. Document who validates eradication and what evidence is retained for the post-incident review.

5. Recovery

Restore services from verified clean backups, validate restoration, and stage the return to production. For each client, the recovery phase documentation should reference their specific backup architecture, recovery time objectives (RTOs), and the validation checklist before systems go live.

6. Post-Incident Review (Lessons Learned)

This is the phase most clients skip — and auditors notice. A documented post-incident review within 30 days of any declared incident is a SOC 2 Type II best practice and directly feeds the evidence record. This review should cover: what happened, how it was detected, how the plan performed, what gaps were exposed, and what changes are required before the next incident.

Testing the Plan: Tabletop Exercises

A plan that's never been tested isn't a plan — it's a document. Only 30% of organizations regularly test their incident response plans (JumpCloud, 2025). For MSPs, running tabletop exercises is both a billable service and a compliance deliverable: PCI DSS 12.10.2 requires annual testing, and SOC 2 auditors look for evidence of exercises.

A tabletop exercise doesn't require deploying tools or simulating an actual attack. It's a facilitated discussion — typically 90 to 120 minutes — where you walk key stakeholders through a realistic scenario and document how they'd respond.

Effective scenarios for MSP clients:

  • **Ransomware at 2 a.m.:** A user reports that files on a shared drive show a ransom note. What's the first call? Who decides to isolate which systems? When does the cyber insurance carrier get notified? Who officially declares an incident?
  • **Business Email Compromise:** A finance employee flags an urgent wire transfer request from the CEO's email address. It turns out the CEO's mailbox was compromised three days ago. What data was accessible during that window? What are the notification obligations?
  • **Third-party breach:** A vendor your client relies on announces a data breach that may have exposed API credentials shared with your client. What do you do in the next four hours? Who needs to know?

Document the scenario, attendees, decisions made, gaps identified, and remediation assigned. That documentation is the evidence artifact for compliance audits — a paper trail showing the IR program is exercised, not just written.

Packaging IR Planning as a Recurring MSP Service

IR plan development and testing fits naturally into a tiered compliance service offering. A practical structure:

  • **IR Assessment** ($1,500–$3,000 one-time): Review the client's current state — what exists, what's missing, what the compliance gaps are. Produces a gap report and prioritized remediation list. This is the natural entry point after running an initial [MSP security assessment](/msp-security-assessment).
  • **IR Plan Development** ($3,000–$8,000 project): Develop a fully documented IR plan covering all six phases, customized to the client's environment and compliance obligations. Deliver a tabletop exercise to validate the plan and train key stakeholders.
  • **Annual IR Maintenance** ($500–$1,200/year): Annual plan review, one tabletop exercise, and post-incident reviews as needed. This is the recurring revenue component — clients who've already invested in the plan have every reason to maintain it, and every compliance framework with annual testing requirements gives you the renewal hook.

The compliance angle makes the conversation straightforward: if your client is preparing for a SOC 2 audit, PCI DSS assessment, or HIPAA review, the IR plan is a required deliverable — not optional consulting. Build it into your compliance service delivery from the start.

For a broader framework on packaging compliance revenue, see the 5 compliance services every MSP should be selling in 2026. Nuronus maps IR-related controls across all eight supported frameworks simultaneously — so when you assess a client's incident response posture, you see exactly which compliance obligations it touches in a single view. Explore the full MSP compliance services model to see how IR planning fits into a complete compliance practice.


*Ready to run IR gap assessments across your client portfolio from one multi-tenant dashboard? Start free with Nuronus — 2 clients, no credit card required.*

Ready to Add Compliance Services to Your MSP?

Free forever for 2 clients. All features included. No credit card required.

Get Started Free
BC

Brett Coffin

Founder, Nuronus

20+ years in IT infrastructure and security. Built Nuronus after watching MSPs leave compliance revenue on the table because the tooling made it impossible to deliver profitably.