Ransomware Response Playbook for MSPs

The need for polished ransomware response playbooks is apparent now more than ever, especially for MSPs. Ransomware was involved in 48% of breaches in Verizon’s 2026 Data Breach Investigations Report, increasing from 2025’s 44%. As frequency has climbed, so have ransom payments: Coalition's 2026 Cyber Claims Report found initial demands jumped 47% year over year to an average above $1 million. Interestingly, that same report shares that 86% of businesses refused to pay ransoms. The reduction in payments against the rising trajectory of ransomware attacks proves the need for response playbooks.

As an MSP, the responsibility of building effective response playbooks lands on you. You’re the one clients turn to when file shares go dark, and, often, your business is just as much a target. CISA, the NSA, and the MS-ISAC warned in January 2023 that threat actors can exploit trust relationships in MSP networks to reach many of the victim MSP's customers, which means an MSP responding to a client incident is sometimes investigating itself.

With threat of ransomware looming, there’s never been a better time to prepare yourself for the inevitability of an attack. What decides the damage is whether the first 90 minutes are written down, assigned to named people, and rehearsed. What follows is that playbook: the order of operations, the evidence you cannot destroy, the calls you make first, and how it turns into something you can sell.

Why ransomware incident response is now a recovery problem

Two figures should reset your playbook. First, 69% of ransomware victims in the DBIR data paid nothing, so recovery capability decides the outcome more often than negotiation. Second, 70% of Coalition's ransomware claims involved encryption and data theft together. Dual extortion is the default case.

That makes restore and move on the wrong default. If data left, notification duties attach whether or not you get the files back, and a clean restore does nothing to reduce them. Your plan needs a forensics track and a legal track beside the recovery track from hour one.

Public reporting will not size this for a client. The FBI's 2025 Internet Crime Report logged 3,611 ransomware complaints and $32.3 million in losses, a figure the Bureau notes excludes lost business time. Coalition's claims data puts the average ransomware loss at $269,000 against $116,000 for cyber claims overall. Those are the numbers the client's carrier is working from.

What to do in the first 90 minutes of a ransomware attack

Which ransomware attack response steps come first, and who owns them

Write the declaration threshold before you need it. Mass encryption behavior on two or more hosts, a client reporting inaccessible files with a ransom note, or a sudden fleet-wide backup failure should each trip the same switch, no one debating severity on the call.

When it trips, one person becomes incident commander, one takes notes with timestamps, and one owns communication to the client. The commander does not touch keyboards. That sounds like overhead for a twelve-person shop until you have watched three techs improvise in the same tenant with no record of what changed, then watched a forensics firm try to rebuild the intrusion from it. NIST's SP 800-61 Revision 3, published in April 2025, recast incident response as part of the CSF 2.0 risk management lifecycle rather than a standalone technical procedure. Settling who holds authority, in advance, is part of that shift.

How to contain ransomware without destroying the evidence

CISA's ransomware response checklist is blunt about sequence: determine which systems were affected, isolate them immediately, and only power devices down if you cannot disconnect them from the network. Memory contents disappear on shutdown, and memory is where the loader, the injected process, and the operator's staging paths live. Image disk and memory on a sample of affected devices before anything is reimaged.

Prefer console-driven isolation over someone pulling cables in a closet, because you need the endpoint agent alive to collect from it. Endpoint detection and response with one-click containment keeps a host quarantined and still reachable for collection, which is the point. Documented threat response procedures are what keep a tired tech from reimaging patient zero to get the client back to work.

Reimage the first host and you lose the only copy of the initial access artifact, so you cannot tell the client's insurer how the intruder got in. That gap gets paid out of your margin.

Call the carrier before you call the forensics firm

Most cyber policies require notice within a set window, and many require legal counsel and digital forensics come from the carrier's approved panel. Bring in your preferred IR shop before the carrier signs off and you put the client's cost recovery at risk. They pay the invoice, then ask you why.

Put the carrier's claims number, the policy number, and the panel requirements in the client's runbook alongside the network diagram. Same emergency, same folder. Treating insurance as part of the security program is also what makes coverage aligned to the stack a renewal argument.

How to scope the blast radius across your client tenants

Rebuild the timeline from logs you kept before the incident

Scoping is arithmetic on data you either retained or did not. If EDR telemetry rolls off at seven days and initial access was forty days ago, no amount of analyst hours recovers the answer. This is the unglamorous reason centralized log collection and retention earns its line item: it is the difference between a defensible timeline and an educated guess in front of a regulator.

Work outward from the encryption event to the first anomalous authentication. Look for the account that created other accounts, the host that scanned the subnet, the scheduled task that survived a reboot. Write it down as you go; you will produce that timeline for three audiences.

Assume exfiltration until you can disprove it

With dual extortion in 70% of claims, assume data moved, then prove the negative with evidence: assertion: egress volume against baseline, archive utilities appearing where they do not belong, cloud storage destinations in proxy logs, bulk downloads from SharePoint or a file server. Absence of a leak-site posting proves nothing; operators hold data for weeks before publishing.

Tell the client on day one that you are treating exfiltration as likely. That sentence lets counsel start the notification analysis on time instead of scrambling in week three.

Check every client tenant, not only the one that called

This is the part only MSPs need. Shared administrative accounts, a common RMM agent, PSA integrations with API keys, delegated admin into customer Microsoft tenants, and one backup appliance serving many clients all turn a single compromise into a portfolio event. Start with whatever they share.

Hardening your own estate is the prerequisite for being able to answer that question quickly, and the practical defenses that keep an MSP from becoming the vector are the same ones that turn that mapping into a twenty-minute exercise.

What order to run ransomware remediation and recovery in

Rebuild identity before you rebuild servers

Restoring a domain controller into a compromised identity plane reinfects the environment, sometimes within hours. Rotate service account credentials, reset privileged accounts, revoke sessions and refresh tokens, re-enroll multifactor authentication for anyone with elevated rights, and reset the Kerberos ticket-granting account twice with a replication interval between resets. Remove the persistence you found, then look again for what you missed.

Restore into a clean network, in business continuity order

Stand up a clean segment with its own addressing and no route back to the affected subnets, validate backups there before they touch production, and restore in the order the client's business needs rather than the order your backup console lists. That ordering is a business continuity decision, so it should already exist on paper, signed. Deciding at 3 a.m. which system comes up first is how MSPs lose accounts they saved.

Watch for re-entry before you declare it closed

Give yourself weeks of post-recovery monitoring, hunt for the same techniques rather than the same indicators, and confirm the original access path is closed instead of assumed closed. Sustained post-incident monitoring is where a managed detection and response capability shows up as resilience rather than as an alert feed. Part 2 of the joint #StopRansomware Guide covers the post-incident activity most plans skip, including hardening work that should be scheduled before the incident is formally closed.

Who decides whether to pay the ransom, and when to decide

Ransom payment authority belongs to the client, in writing, decided before an incident. Name the individual who can authorize it and the individual who cannot. The MSP is never that person, and your master services agreement should say so in a sentence a court could read.

Sanctions exposure is the reason this matters beyond liability. The Treasury Department's Office of Foreign Assets Control has advised since 2020, with an update in September 2021, that facilitating a ransom payment to a sanctioned person or a party acting on their behalf can violate US sanctions regulations on malicious cyber-enabled activity on a strict liability basis. OFAC treats timely reporting to and cooperation with law enforcement as a significant mitigating factor, and says a self-initiated report made as soon as possible after discovery counts as a voluntary self-disclosure. An MSP that negotiates or transmits payment on a client's behalf has taken on a legal exposure it cannot price.

Settle the destructive-action delegation the same way. Who authorizes wiping and rebuilding a production server at 2 a.m.? If that answer lives in a text thread with a sleeping business owner, containment stalls at the moment speed matters most. Put the authority, after-hours contacts, and escalation ladder in the agreement.

How long you have to report a ransomware breach

The clocks start at discovery, not at recovery. Under the HIPAA Breach Notification Rule, a covered entity has no more than 60 days from discovery to notify affected individuals, and a business associate has no more than 60 days to notify the covered entity. If you hold protected health information for a client, you are likely that business associate, and your delay becomes their violation and then your contractual problem.

Federal incident reporting is close behind. CISA now expects to finalize the Cyber Incident Reporting for Critical Infrastructure Act rule in September 2026, with 72 hours to report a covered incident and 24 hours to report a ransom payment. Coverage turns on sector and size criteria, so work out now which of your clients are in scope. Telling a manufacturing or healthcare client in a quarterly review that a 72-hour federal clock is coming is a better conversation than discovering it during an incident.

Layer state deadlines on top of that. Washington, for example, requires notice to affected residents within 30 days of discovery, and notice to the attorney general on the same clock once a breach passes 500 residents of the state. Then file with the FBI. That filing does double duty: it counts as a mitigating factor for sanctions purposes, and CISA notes that researchers have broken the encryption on some variants, so federal agents may know of a decryptor you do not.

Where a ransomware response playbook becomes a service line

One playbook supports three sellable things: a retainer, a rehearsal, and a detection floor. Most MSPs give away the first two, then wonder why the third is priced as a commodity.

Price the retainer on a named response window rather than on hours. A defined severity-one acknowledgment target, a block of included incident hours, a documented escalation path, and quarterly runbook updates are what the client buys, and what an insurer wants to see. The economics of building versus buying security operations decide whether you staff that window yourself or partner for the after-hours coverage, and getting that math wrong is the most common way an MSP ends up promising a window it cannot hold.

Sell the rehearsal as an annual deliverable with a written after-action report. A tabletop exercise built around a plausible scenario surfaces the gaps that matter, usually authority and contact data before tooling, and the report doubles as compliance and underwriting evidence. Attaching it to framework controls inside a governance, risk, and compliance workflow turns a one-time engagement into a recurring assessment.

The detection floor is what makes the response window credible. Twenty-four-hour monitoring, containment actions your analysts can trigger from one console, and automated response playbooks that fire before a human reads the alert compress the window where encryption spreads. Speed at that stage is the entire game: in one Todyl partner incident, a ransomware attempt was identified and remediated within five minutes of the response team being brought in, the difference between a cleanup and a claim.

The part of a ransomware recovery plan you cannot write down

Most of a recovery plan is a document and a rehearsal. The declaration threshold, the call order, the delegated authority, the restoration sequence: you can write all of it this quarter and test it next. Two pieces resist that. Someone has to be awake when the threshold trips, and the telemetry that makes scoping possible has to have been collecting for months before anyone knew to look.

Those are the two an MSP cannot improvise at 4 a.m., and the two that rarely clear a build-versus-buy review. Todyl MXDR puts a 24/7 analyst team on the first, with containment your techs trigger from the console they are already scoping in. The SIEM underneath it handles the second, retaining across every client environment from one multi-tenant console. That shortens the incident. It also turns the response window into something you can put on an invoice, because someone is awake to honor it. See the platform, or book a demo.

Frequently asked questions about ransomware response playbooks

What are the first steps in responding to a ransomware attack?

Declare the incident against a written threshold, name a single incident commander, and isolate affected systems from the network without powering them off. Capture disk and memory images from a sample of those hosts before any reimaging. Then notify the client's carrier, since panel requirements often govern who you can hire next.

Should we ever power down an encrypted machine?

Only when you cannot disconnect it from the network any other way, which is CISA's explicit guidance. Shutting a host down destroys volatile memory that holds the loader, injected processes, and operator artifacts, and that evidence is what lets you scope the intrusion and answer the insurer's questions.

How long does ransomware recovery take for a small business?

Plan in weeks, not days, and set that expectation before an incident. Identity rebuild, clean-room restoration, application validation, and the post-recovery monitoring window run in sequence, and the forensics and notification work continues after users are back at their desks. Recovery speed comes down to whether the backups were immutable and tested.

Do we need a ransomware playbook if we already have an incident response plan?

Yes, because ransomware forces decisions a general IR plan does not cover: payment authority, sanctions screening, dual-extortion notification analysis, and a restoration order tied to business priorities. Treat it as an annex to the IR plan rather than a replacement, so the governance structure stays consistent.

Can an MSP negotiate or pay a ransom on a client's behalf?

It should not. OFAC can impose civil penalties for sanctions violations on a strict liability basis, meaning liability can attach even where the payer did not know the counterparty was sanctioned. Route payment decisions to the client, the client's counsel, and the carrier's negotiation vendor, and put that limitation in your master services agreement.

How do we prove client data was not stolen?

You prove it with retained telemetry: egress volume against baseline, proxy and firewall records of cloud storage destinations, archive utility execution, and bulk downloads from file shares. Without retention predating the intrusion you cannot support the claim, and counsel will advise notifying as though it left.

Where does business continuity fit into a ransomware playbook?

Business continuity supplies the restoration order. The playbook should reference a signed document ranking the client's systems by tolerable downtime, naming manual workarounds for the first 48 hours, and identifying who communicates with customers and staff. Without it, sequencing becomes an argument at the worst moment.