Only four out of more than 800 clients (0.5%) assessed by Fenix24 came close to their own 24 to 48‑hour ransomware recovery targets, and even those managed only partial business operations — none reached full operational capacity until several weeks after the incident.
Ransomware recovery performance: timelines and scale
Those figures are drawn from the incident response firm Fenix24’s first State of Recoverability report, published on September 15 and based on more than 500 ransomware recoveries. The headline is simple and stark: advertised recovery targets rarely survive an actual incident. Even where organizations set 24–48 hour goals, near-term partial recovery was achieved in only 0.5% of more than 800 assessed clients, and full operations were not restored for weeks.
Identity systems: the proximate choke point — Active Directory
Fenix24 found an overwhelming identity failure mode at the heart of most recoveries. Ninety‑nine point two percent (99.2%) of clients arrived with no documented identity recovery plan, and none of the identity plans that did exist survived contact with the threat actor. The directory itself was typically the first major system to fall: Active Directory was usually the initial failure, and 94% of clients had tied their backup systems to the very directory the attacker seized.
As Jason Soroko, senior fellow at Sectigo, summarized, "Recovery can depend on the same login system an attacker has compromised." In practice, that dependency consumed time: roughly 20% of the opening two days of an engagement were spent on identity alone, trying to get a single authentication source clean enough to trust. Only after that did teams reach a minimum viable infrastructure, which took at least another 72 hours.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleBackups and immutability: surviving copies that still fail
Intact backups did not guarantee recovery. In 38% of engagements where backups came through the attack intact or nearly so, Fenix24 said those backups still could not carry the recovery. Failures fell into a handful of recurring categories: backup sets that predated anything usable; sets that were corrupt or partial well before the intrusion; backups in the wrong format or ones that took longer to restore than a rebuild; and hardware labeled immutable that in practice could not deliver immutability under the conditions encountered.
Compounding the problem, not a single client within the dataset knew its full application and dependency picture. The closest existing artifacts were configuration databases that either fell with everything else or were created mid‑recovery as organizations were forced to choose what came back first.
Storage and network constraints: physical limits that become strategic failures
More than paperwork and processes, physical constraints repeatedly stopped recoveries. Storage ran short in 82% of engagements, leaving restored data without a safe landing zone and tempting teams to overwrite forensic records. In 38% of cases the network could not move data at recovery scale. These are not hypothetical bottlenecks: they are immediate, measurable barriers that convert a working backup into a non‑starter.
Fenix24’s prescription: dependency maps, end‑to‑end restores, and simulations
Fenix24’s recommendations are narrowly focused and operational. It advised organizations to identify their most revenue‑critical business service and demand a complete dependency map for that service, including third parties. Critically, it urged running the full restore path end‑to‑end against current recovery targets; in Fenix24’s words, simulations and untested plans are the same answer. In short: know what must come back, understand every dependency, and actually practice the restoration path under realistic conditions.
What this means for technologists, procurement leaders, and end users
- Technologists and security teams: the report provides concrete failure modes to test for — identity recovery plans, separation of backups from compromised directories, meaningful multifactor controls on critical infrastructure consoles, and end‑to‑end restore rehearsals against current targets.
- Procurement and third‑party risk leaders: because many dependency maps must include vendors, the findings underline the need to require and verify a supplier’s ability to provide complete dependency information and demonstrated restore paths as part of contracting.
- End users and business owners: the lived consequence in the dataset was prolonged operational disruption — even organizations that believed they had backups or plans discovered gaps that extended full recovery by weeks.
Fenix24’s data offers a narrow, uncomfortable conclusion: recovery plans that look sound on paper routinely come apart when a threat actor is inside the environment. The fixes it prescribes are concrete — map dependencies, separate authentication and backup trust boundaries, pressure suppliers for verifiable restore capability, and run the restores in full. If those steps are not already on an organization’s calendar, the report leaves little doubt about where to begin.
