Every ransomware preparedness conversation eventually arrives at the same shopping list: endpoint detection and response, immutable backups, network segmentation, deception technology, maybe a retainer with an incident response firm. These are not bad investments. The problem is that organizations treat the list as the destination rather than the foundation, and then discover during an actual incident that the foundation is sitting on operational quicksand.
The tools work. The operations around the tools often don’t. That distinction matters a great deal when the clock is running.
Where Recovery Actually Fails
Post-incident analyses from ransomware events consistently point to the same operational failures. Backups exist but restoration procedures haven’t been tested at scale. Recovery time estimates were produced by the vendor during procurement and never validated against an actual restore of a full environment. Critical systems are restored in the wrong order because no one documented the dependency chain while the systems were running normally.
Ownership gaps are pervasive. During an incident, someone has to make decisions: who authorizes the decision to take production systems offline, who signs off on paying a ransom if that option is on the table, who has authority to stand up alternative infrastructure, who is the single point of contact with the incident response retainer. In large organizations, these questions frequently don’t have clear answers in the moment because the accountability was implicit during normal operations and explicit only on paper in a policy document no one has rehearsed.
This is not a failure of tools. No EDR product answers the question of who owns the decision to take down Active Directory during an active incident. No immutable backup solution resolves the organizational ambiguity about whether IT or security or business continuity leads the recovery.
Tabletop Theater vs. Real Recovery Practice
Tabletop exercises have value. They surface communication gaps, surface unclear ownership, and help leadership teams understand the general shape of an incident before they’re living one. What they don’t do is test the actual restoration procedures, validate that backups are uncorrupted, confirm that network segmentation actually holds under realistic adversary behavior, or reveal that the restore process requires a vendor’s MFA that is also encrypted.
Real recovery practice is harder. It requires taking systems offline, restoring from backup in an isolated environment, validating that the restored system actually functions, and measuring how long it took. Most organizations do this once during a disaster recovery audit cycle and then don’t revisit it for a year or more. By that time, the environment has changed — new systems, new dependencies, new SaaS integrations — and the recovery procedure reflects the environment as it was, not as it is.
The question worth asking before an incident is: if the primary Active Directory domain were encrypted right now, could the team restore it to a functional state within the recovery time objective documented in the business continuity plan? Not theoretically. Actually. With the people who are on call right now, using the tools that are available, following a runbook that has been tested.
That question is uncomfortable because the honest answer in most organizations is “probably not within the documented RTO, and we haven’t tested it recently enough to know.”
The Vendor Dependency Problem
Here is an operational risk that doesn’t appear in most ransomware preparedness frameworks: your incident response depends on vendors who may also be under attack, or who serve customers who are, and whose capacity and availability during a widespread ransomware campaign may be significantly constrained.
Managed detection and response retainers are allocated across a portfolio of clients. When a ransomware campaign hits multiple organizations in the same sector simultaneously — which happens regularly with opportunistic groups — the IR firm’s capacity is distributed across those simultaneous engagements. Response times lengthen. The senior responders are already deployed elsewhere. This is not a criticism of IR firms; it’s a capacity reality that organizations don’t typically factor into their preparedness plans.
The same dynamic applies to backup and recovery infrastructure that runs in cloud environments. If the ransomware event is severe enough to affect your cloud control plane access — through credential compromise or by targeting cloud-resident resources directly — the recovery path that depends entirely on cloud-hosted backups and cloud-managed identity may not be available in the way it was designed to be.
Operational preparedness means knowing your dependencies, knowing what happens if those dependencies are degraded, and having an answer that isn’t “we call the vendor.”
What Operational Readiness Actually Requires
The tool stack implies a level of readiness that the operations may not support. A few things that operational readiness actually requires:
Tested runbooks, not documented procedures. There is a significant difference between a document that describes the recovery process and a runbook that has been executed end-to-end recently enough that the people executing it know what the friction points are. Runbooks go stale fast. The team that wrote them may have changed. The systems they describe may have changed.
Explicit decision rights during declared incidents. Who has authority to authorize out-of-band communication, engage outside counsel, make ransom payment decisions, authorize infrastructure purchases on an emergency basis, and communicate externally? These need to be documented and rehearsed, not inferred from org charts.
Segmentation that has been tested, not designed. Network segmentation looks reasonable on a diagram. The question is whether an adversary who has established a foothold in one segment is actually blocked from reaching another, given the real-world configuration of firewall rules, service accounts, and administrative access paths that have accumulated over years of operational change.
Recovery priorities derived from business impact, not IT convenience. Systems are often recovered in the order that is technically easiest, not the order that minimizes business harm. The business impact analysis should drive the recovery sequence, and the technical team should know that sequence and have practiced it.
Bottom Line
Ransomware preparedness is an operational discipline that happens to require good tools, not a tool procurement exercise that produces operational readiness as a side effect. The organizations that recover fastest from ransomware events are not necessarily the ones with the most sophisticated EDR stack. They are the ones where the people involved know what they are supposed to do, have practiced doing it, and have resolved the ownership questions before the clock started.