Ransomware Response: A Step-by-Step Playbook for IT Ops Teams
Key Takeaways
- Security and IT ops play different roles in ransomware response. Security investigates and decides containment scope; IT ops does the hands-on work of isolating devices, keeping tools running, and rebuilding endpoints.
- Exploited vulnerabilities, not stolen credentials, are now the leading way attackers get in, at 31% of breaches, according to the 2026 Verizon DBIR.
- Regulators now care as much about how fast you report and whether you can recover as they do about what data was exposed. NIS2, DORA, and the SEC's four-business-day rule all stage reporting in hours, not weeks.
- Backup-based recovery hit 66% of encrypted-data cases in 2026, but the average recovery cost still climbed to $1.7 million, because backup restores data, not a trusted, managed endpoint.
When the cost is the downtime, not the ransom
In April 2025, Marks & Spencer disclosed a ransomware attack that forced it to suspend online operations for 46 days. By the company's own estimate, the incident cost roughly £300 million (about $400 million), covered in the SecurityWeek report on the breach. M&S never confirmed paying the ransom. The cost was the downtime itself: lost sales, recovery labor, and weeks of disrupted operations. That's the pattern worth planning around. Jaguar Land Rover's 2025 attack shut down global production for weeks and needed a UK government-backed £1.5 billion loan just to keep suppliers paid.
Asahi's September 2025 ransomware attack, confirmed as the work of the Qilin group, knocked out ordering and shipment systems at 30 Japanese factories and led the company to estimate JPY 5 billion (about $31.4 million) in lost revenue. More recently, Indian hosting provider HostDZire confirmed a ransomware attack in August 2026 that encrypted virtual disks beyond recovery and forced a rebuild from scratch. None of these started with the ransom note. They started with the response, and how that response goes determines most of the final bill.
Who does what: security vs. IT ops
Most ransomware response content, including earlier versions of this piece, blurs the line between what security teams do and what IT ops teams do. In practice, they're different jobs that hand off to each other mid-incident:
What you're actually up against
The attack patterns have shifted enough in the past year that it's worth resetting expectations. According to the 2026 Verizon Data Breach Investigations Report, exploiting vulnerabilities is now the single most common way attackers get in, at 31% of breaches, up sharply from 20% the year before. Stolen or abused credentials, long the top entry point, fell to 13%. A lot of that initial access is simply bought: VPN credentials alone make up 44% of what access brokers sell. Among ransomware victims specifically, 73% had an infostealer infection or a credential leak in the year before the attack, and half of those were hit within 95 days of the leak, a real window where defenders could have caught it first.
It's worth noting that Sophos's 2026 State of Ransomware report puts the share of attacks starting with an identity-based approach at 79%, while the DBIR puts exploited vulnerabilities first. The two reports measure differently, one surveys victims directly, the other analyzes confirmed incident data, so it's more accurate to say both access routes matter than to pick one as the dominant story.
Once an attacker is in, the pattern before encryption usually includes moving laterally across the network, escalating privileges, and disabling the security tools and backups that would otherwise catch or undo the attack. Recent reporting puts the dwell time before encryption at around 5 days on average, which doesn't leave much room for a slow response. After encryption, or sometimes instead of it, extortion has gotten more layered too: double extortion (encrypt and threaten to leak stolen data) and triple extortion (also targeting the victim's customers or partners directly) are both common enough now that a response plan built only around decrypting files is already out of date.
Confirming it's ransomware and declaring an incident
Security typically makes the call on whether an event is ransomware and when to formally declare an incident, but IT ops needs a plan for what happens the moment that call is made, especially if email and Teams are among the systems affected. Decide in advance on an out-of-band channel, a phone tree, a separate messaging app, a pre-agreed physical meeting point, so the response doesn't stall out while people try to figure out how to talk to each other.
Containing it
This is where IT ops' work usually starts in earnest: freezing or quarantining at-risk endpoints to stop the spread, at the scale the incident actually requires. Containing one device is straightforward. Containing hundreds of them at once, while the rest of the business still needs IT support, is the part manual processes struggle with.
Scoping: which devices, which data, were the tools even running
Security leads the investigation into which devices and data were touched, but IT ops is often the only team that can answer a question that matters just as much: were the security and management tools on each device actually running at the time of the attack, or had they been disabled first? Attackers routinely try to kill endpoint protection and backup agents before encrypting anything, which means the tools you're counting on for both detection and recovery may not have been there when you needed them.
Reporting: regulators want speed and proof of recovery
The compliance conversation has moved on from "what data was on the device." That still matters, but the newer wave of rules cares much more about how fast you report and whether you can keep the business running. In the EU, NIS2 requires a 24-hour early warning and a 72-hour notification for significant incidents, with a full report inside a month. DORA is stricter still for financial entities: a major ICT incident can require notification within four hours of being classified as major. In the UK, the Cyber Security and Resilience Bill proposes a similarly staged 24-hour and 72-hour notification regime, though as of this writing it hasn't received Royal Assent; it cleared the House of Lords on November 2, 2026, and is back in the Commons for consideration of amendments, with Royal Assent expected sometime between late 2026 and spring 2027. In the US, public companies already operate under the SEC's four-business-day disclosure rule for material incidents, in effect since December 2023, and CISA's CIRCIA rule for critical infrastructure reporting is in its final stretch, sent to the White House for review on October 1, 2026, after missing several earlier target dates. The common thread: regulators now want two things fast, a clear account of what happened, and proof you can recover. Both are squarely IT ops' job to help prove.
This is also where lost and stolen devices deserve a mention. The 2026 DBIR found that incidents involving lost or stolen devices rose sharply, but only 17% of them were confirmed as breaches, possibly because the organization couldn't actually determine whether the data on the device had been accessed. That uncertainty is itself a compliance risk under reporting rules that expect a clear answer fast. Knowing in advance what was on a given device, and whether it was encrypted, turns that guesswork into an answer.
Getting endpoints back to a trusted, managed state
This is the step a lot of response guides wave past, and it's the one IT ops owns almost entirely. Restoring data from backup is necessary, but backup restores data, not an operational endpoint with its security tools, management agents, and configuration intact. Backup-based recovery reached 66% of encrypted-data cases in 2026, up 12 percentage points year over year, yet the average recovery cost still climbed to $1.7 million per incident, up 11% year over year, according to the Sophos State of Ransomware 2026 report. Worth noting: that $1.7 million figure is an average, not a median, the median is considerably lower, and the survey sample skews toward organizations with 100 to 5,000 employees, so it won't map cleanly onto every organization's situation.
The question that section never quite answers is what happens when the attacker disabled your recovery tools along with everything else. That's what Absolute Persistence is built to solve. It's patented technology embedded in the firmware of over 600 million devices at the factory, giving Absolute an always-on connection to the endpoint that survives a reimage, a wiped hard drive, or an attacker actively trying to remove it, because the connection doesn't live in the operating system at all. Absolute Rehydrate, part of the Resilience editions for Windows, uses that firmware-level connection to restore an endpoint to a trusted, compliant state in minutes rather than days or weeks, and because it runs below the OS, it works even when Windows won't boot, and on unattended or off-network devices through pre-built playbooks. Absolute Application Resilience, also part of the Resilience editions, keeps that same firmware-level connection monitoring and self-healing the security applications on a device, so the tools you're depending on for both detection and recovery are more likely to still be there the next time you need them.
Separately, Absolute Ransomware Response is a services offering, a readiness check, a cyber hygiene baseline across your Absolute-registered endpoints, and recovery assistance when an incident hits, that works alongside Persistence, Rehydrate, and Application Resilience rather than replacing them.
It's also worth sizing the underlying problem: Absolute's own 2026 Resilience Risk Index found that endpoint security software fails to protect devices nearly 21% of the time, and that protected-state integrity across enterprise devices dropped from 64% in 2025 to 55% in 2026, leaving the average enterprise PC exposed for up to 76 days a year. That's the gap a firmware-level connection is built to close.
For a closer look at where backup alone falls short, see Ransomware Recovery vs. Backup: Why Backup Alone Isn't Enough.
Comms: users, execs, regulators, and customers
Recent incidents, M&S and Co-op both included, show how much damage an unprepared communications response can add on top of the technical one. IT ops isn't usually the author of exec, investor, or customer messaging, but it's often the team that can tell the comms function, in plain terms, what's actually happening, what's been contained, and when systems are realistically coming back. That input is what keeps public statements accurate instead of either falsely reassuring or needlessly alarming, and it's a role worth planning for explicitly rather than improvising mid-incident.
Reviewing what went wrong
Once systems are back up, a short, honest review of what failed, and why, is what turns one incident into fewer future ones. Prevention deserves more space than this piece has room for; see What Is Ransomware Recovery? for the preparedness side of this conversation.
A quick checklist for IT ops
Absolute Ransomware Response yields the following benefits:
- Agree on an out-of-band communication channel before an incident, not during one, in case email and Teams are both down.
- Know whether your backup strategy restores a fully functioning, manageable endpoint, not just the files on it.
- Confirm you can freeze or quarantine a compromised device remotely, and communicate with its user, without needing physical access.
- Check in advance whether your security and management tools can be disabled by an attacker, and what restores them if they are.
- Know what data lives on which devices ahead of time, so a compliance determination doesn't start from zero after an incident.
- Revisit the plan at least annually. Attack patterns, like the recent shift toward exploited vulnerabilities over stolen credentials, change faster than most response plans get updated.
Closing thoughts
Ransomware response works best as a rehearsed handoff, security decides, IT ops executes, rather than a single team trying to do both under pressure. The organizations that come back fastest treat that handoff, and the recovery work on the other side of it, as something to test before they need it, not something to figure out live. Want to see how Absolute shortens that recovery for your fleet? Request a demo to see our solutions in action, or explore our resource library for more.
