Ransomware Recovery Plans Fail in Practice

Only four out of more than 800 clients assessed by incident response firm Fenix24 came close to their own 24 to 48-hour ransomware recovery targets, and even then only for partial business operations. None of them reached full operational capacity until several weeks after the incident.

What the Report Examined

The finding comes from Fenix24's first State of Recoverability report, drawn from more than 500 ransomware recoveries and published on September 15. According to Infosecurity Magazine's coverage, the report examines why recovery plans that look sound on paper come apart once an attacker is inside.

Fenix24 said recovery plans failed the same way each time, looking sound on paper and coming apart once an attacker was inside.

Identity Systems Delay Recovery

Fenix24 found 99.2% of clients arrived with no documented identity recovery plan, and none of the plans that did exist survived contact with the threat actor.

"Recovery can depend on the same login system an attacker has compromised. These figures describe Fenix24's engagements, not every business, but they identify a failure organizations should test for."

— Jason Soroko, senior fellow at Sectigo

The directory itself was the problem in nearly all of them. Fenix24 said Active Directory was usually the first major system to fall, and that 94% of clients had tied their backup systems to the very directory the attacker seized.

Roughly 20% of the opening two days went on identity alone, spent getting a single authentication source clean enough to trust. Reaching minimum viable infrastructure took at least another 72 hours.

Meanwhile 95% had no meaningful multifactor controls on critical infrastructure consoles, against 15% at network ingress.

Backups That Survive Still Fail

In 38% of engagements where backups came through the attack intact or nearly so, Fenix24 said they still could not carry the recovery. Some sets predated anything usable, others had been corrupt or partial well before the intrusion, and some were simply the wrong format or took longer to restore than a rebuild would.

Others carried an immutable label on hardware that could not deliver it.

Not one client knew its full application and dependency picture. The nearest equivalents lived in configuration databases that fell with everything else, or got drawn up mid-recovery once the business was forced to choose what came back first.

Physical Constraints Often Overlooked

Two constraints were physical and routinely overlooked. Storage ran short in 82% of engagements, leaving restored data nowhere to land without overwriting the forensic record, and in 38% of cases the network could not move data at recovery scale.

What Fenix24 Recommends

To counter these shortfalls, Fenix24 said organizations should identify their most revenue-critical business service and demand a complete dependency map for it, third parties included, then run the full restore path end to end against current recovery targets.

It called simulations and untested plans the same answer.

Why It Matters

The gap between a documented plan and a workable recovery is the gap between an incident and a prolonged outage. The report suggests that many organizations may be relying on assumptions about their identity systems, backups, and infrastructure that do not hold up under attack. For businesses, this could mean that recovery time objectives need to be tested against real constraints—storage capacity, network throughput, and the integrity of the systems that authenticate access—rather than accepted as given. If those dependencies are not mapped and validated, the ability to recover quickly may remain out of reach, regardless of how thorough the plan looks on paper.