Incident Response Runbooks for Common MSP Scenarios

An MSP that gets breached doesn't suffer alone. Every client whose network that MSP touches inherits the incident too, often before anyone at the client even knows something went wrong. That's the structural difference from an internal IT department: an internal team's blast radius stops at the company's own walls. An MSP's doesn't stop anywhere in particular, and that's the whole problem.

In 2025, 44% of MSPs reported that at least 10% of their clients had experienced a cyberattack, which tells you this is a baseline condition of running the business now. It's a baseline condition of running the business. The Acronis Cyberthreats Report counted 143 ransomware victims across MSPs, IT-service providers, and telecoms in 2025 alone, and that number says something specific: attackers are hunting this category on purpose, because compromising one provider buys access to dozens of networks at once.

Call it multi-tenant amplification. A single compromised RMM platform, identity service, or backup system doesn't produce one incident. It produces dozens, simultaneously, across client environments that may share nothing except the same vendor. A conventional IT team plans for an incident. An MSP has to plan for an incident that multiplies the moment it starts, and most of the runbooks built for standalone companies never account for that math. Anyone still running client-by-client incident response as though each engagement is isolated is solving the wrong problem.

Why a general IR plan is not enough

An incident response plan sets governance: who holds authority, what the escalation chain looks like, when legal and communications get looped in. That's necessary, and it's also useless to the technician staring at a ransomware alert on a client's file server at 2 a.m. Nobody opens the governance framework in that moment. They need a runbook: a scenario-specific, step-by-step sequence built for whoever is on shift, written so it can get executed without improvising.

A good runbook doesn't depend on the most experienced person in the room being awake and available. It works whether the incident commander has handled six ransomware cases or zero. Under pressure, people default to what's written down, not to what they might puzzle out given enough time to think. In an active incident, there is no time to think, and pretending otherwise is how the first hour gets lost.

Skipping this step costs money, not just risk. Companies without a formal incident response plan pay 58% more per breach than those with tested protocols, and companies without a dedicated incident response team see breach costs run $2.66 million higher. IBM's Cost of a Data Breach Report put average detection time at 181 days, with another 60 days to contain. A runbook doesn't erase every unknown in an incident, but it collapses both numbers by cutting the decision lag at each phase, detection, containment, eradication, recovery, where nobody's sure whose call it is to act. That lag is where the 181 days actually comes from, and it's the one variable a runbook is built specifically to remove.

Ransomware runbook: detection through recovery across a multi-tenant environment

Ransomware earns the first runbook because it checks every box that makes an incident expensive: the highest financial impact, the most common initial access vectors (phishing accounts for 52% of cases, unpatched vulnerabilities another 27%), and, for an MSP, the worst containment difficulty once several tenants get tangled into the same incident.

The trend line only moves one direction. Ransomware complaints rose 9% year over year, and 67 new variants surfaced in 2024 alone, according to the FBI Internet Crime Report 2024. The groups most active against MSPs right now, among them Akira, LockBit, RansomHub, FOG, and PLAY, run slightly different tooling but the same playbook: get in, move laterally, encrypt, extort.

Detection has to happen before encryption starts, not after the ransom note appears. That means correlating telemetry across endpoint, identity, email, Microsoft 365, DNS, proxy, and egress logs, rather than waiting for an endpoint alert to trip on its own. The signals worth hunting are exfiltration and identity abuse, not the encryption event itself, since most operators steal data well before they ever trigger encryption. Immutable backups solve the recovery half of that equation, and only that half: once data has left the network, no backup strategy pulls it back, and the breach-notification clock starts at the theft, not at the encryption that follows it.

Every runbook needs a hard activation trigger, the exact threshold where a suspicious alert becomes a declared incident with a named commander. Without that line, teams stall in a gray zone, arguing over the alert's legitimacy while the encryption timer keeps running underneath the argument.

Containment follows a strict order, and panic breaks it constantly. Isolate affected endpoints, but don't power them off: unplugging a machine wipes the volatile memory forensic analysis needs later. Disable compromised accounts and revoke the password along with active sessions and tokens, all of them, not just the one tied to the current login. Restrict the affected network segments without losing visibility into the rest of the environment, since going blind to an attacker's movement is its own containment failure. The three mistakes that cost the most, every single time, are pulling the plug and destroying the evidence on the machine, resetting the wrong account and tipping the attacker off without actually locking them out, and restoring from a backup that's already infected because nobody checked the timeline first.

RMM compromise runbook: the highest-severity incident an MSP can face

Every other runbook here deals with one client's exposure. This one deals with every client at once, and that difference is why it belongs at the top of the severity list. A compromised RMM tool hands an attacker administrative reach into every environment the MSP manages, all at once, using access the MSP built and the client explicitly trusted. That trust is what makes this the worst-case scenario on the list, worse than ransomware hitting a single tenant, because the blast radius is the entire client roster by design.

In 2025, an actor using DragonForce ransomware compromised an MSP and pushed malware straight to client organizations through SimpleHelp, a legitimate remote monitoring and management tool. The actor chained three vulnerabilities, CVE-2024-57727, CVE-2024-57728, and CVE-2024-57726, released in January 2025, to compromise the SimpleHelp server itself. CISA followed with advisory AA25-163A in June 2025, documenting ransomware actors exploiting unpatched SimpleHelp instances to compromise customers of a utility billing software provider, one instance in a broader pattern of attacks against unpatched SimpleHelp deployments running since January 2025.

None of this is new in kind, only in tooling. SolarWinds and Kaseya both showed years earlier how an attack on a trusted service provider ripples outward through thousands of downstream organizations that never interacted with the attacker directly. The lesson didn't take, evidently, since SimpleHelp customers walked into the same trap. A runbook for RMM compromise has to be built around that blast radius from the first line, not stretched from a single-tenant plan after the fact, because that stretching fails when the incident actually hits.

Phishing and business email compromise runbook: stopping financial and data loss before wire transfer clears

The dollar figures here are concrete enough to sit with. Confirmed BEC incidents can carry substantial per-case financial losses. IBM's 2025 report named phishing the most common initial access vector industry-wide, and phishing-initiated breaches carry significant costs relative to other initial access vectors. One email getting through is what produces that number.

What separates BEC from most of the incidents on this list is who catches it. Automated tooling rarely does. People do. A supplier calls asking about a bank detail change nobody at the client actually sent. A staff member gets a reply to a message they never wrote. Someone notices inbox rules quietly moving or deleting mail. Finance receives an urgent, confidential payment request tied to a thread that reads as completely legitimate. A message genuinely sent from a colleague's account, not spoofed, appears in the phishing report queue because the account itself is the thing that's compromised.

Dwell time is the quiet danger here. The global median sat at 14 days in 2025. An attacker can spend two weeks reading correspondence, learning who trusts whom, and timing the eventual payment request, before anything ever trips an alert.

Containment follows a strict order, and it should never skip a step to save time. Reset the compromised account's password first, then revoke every active session and token, not only the one tied to the current login, because a password reset alone leaves existing sessions running untouched. Audit and strip any MFA methods the attacker added during the compromise. Hunt for inbox rules created during that window, since attackers routinely set rules to hide their tracks or intercept replies before the real user sees them. Check delegates and OAuth grants for any application handed mail access without authorization. Only once all of that is done should the compromise window get pinned down from sign-in logs, and only then should the client hear a scope of impact. Guessing wrong on scope early costs credibility later, and credibility is the only thing an MSP has left to sell after an incident like this.

Credential compromise runbook: containing identity-based access before lateral movement completes

A stolen password to a cloud admin panel, a VPN, or an identity provider is not the same problem as a compromised mailbox, even though both start with someone getting a password they shouldn't have. The blast radius differs, and so does the containment sequence. That's reason enough to give it its own runbook instead of folding it into the BEC one.

The entry paths repeat with almost boring consistency: phishing, which accounts for 52% of initial access broadly, infostealer malware (Akira and RansomHub both lean on phishing and credential theft, often fed by infostealer logs traded well before the actual intrusion), and unpatched vulnerabilities that give an attacker a direct path into the environment without needing stolen credentials.

Build alerts around a login from a geography or device never before associated with a privileged account, an MFA prompt the legitimate user never triggered (the clearest sign an MFA fatigue attack is underway), a new administrative account that bypassed change management, privilege escalation showing up in a cloud console or identity provider log, and an infostealer log appearing in threat intelligence tied to a known employee's credentials.

Containment starts with disabling the credential immediately, and that has to include revoking active sessions, since a password reset by itself does nothing to a session token an attacker is already riding. From there, rotate every shared secret, API key, and service account credential tied to that identity, because credential compromise rarely stays contained to the one account it started in. Enumerate every system and tenant the identity touched during the exposure window, including the ones where nothing suspicious has surfaced yet. Then check for what the attacker left behind: new accounts, new OAuth grants, new firewall rules, anything built to let them back in after the original credential gets locked down. Identity compromise that gets contained at the login but never audited for persistence tends to come back. Just through a different door.