Recoverability Bulletin #3

You Can Restore Every Server and Still Not Run the Business

At the end of a recovery effort that went well by every IT measure, there might be a hundred machines restored, hypervisors are clean, and green lights across the console. Now try to send an invoice. The ERP is up, but the logistics integration it feeds is still down, the tax service it calls hasn’t been reconnected, and the identity provider that authenticates the billing team is still untrusted. The servers recovered. The business didn’t.

Fenix24’s 2026 State of Recoverability Report traces that gap back to how organizations define a successful recovery. Most count what came back. Very few count what the business can do.

Recoverability is not resilience, and the gap between them has a name

A server can be recoverable. So can a database, a backup job, or an image. None of that means the business is, because a business does not run on components. It runs on services, and a service is recovered only when everything it depends on is back, in order, and trusted. That standard is operational recoverability, the ability to restore the business function rather than just the systems beneath it, and it is the level at which resilience is decided.

Keeping the two words separate is important because each one, alone, flatters the organization that uses it. Recoverability without the operation attached is a server count. Resilience without recoverability is a policy. The capability is where the two meet, proven under real conditions, not assumed. A board that hears “we’re resilient” and a backup team that reports “everything’s recoverable” can both be telling the truth while the company remains unable to return to operations after an attack.

Recovery time is set by the slowest link

A business service is a chain of dependencies running through applications, databases, identity, network paths, backup infrastructure, cloud platforms, third-party integrations, and the people who operate them. The service returns when the chain returns, in order, and not a moment sooner. A payroll system is not recovered until the identity provider that authenticates it is trusted again.

That makes recovery time a worst-case calculation rather than an average. Restoring 95% of a service’s dependencies in record time buys nothing if the remaining 5% includes the link the service can’t run without. And the slowest link is frequently one nobody put in the plan because it isn’t software at all. Storage runs short in 82% of Fenix24’s engagements, leaving restored data nowhere to land without overwriting the forensic record. In 38%, the network can’t move data at recovery scale, because a backbone sized for a working day was never sized for petabytes of restoration arriving at once. Sometimes the link can’t be rebuilt at any speed, because it’s a legacy operating system or application version that can no longer be procured once the original is gone. Each of those is discoverable in an afternoon of honest measurement, and each one surfaces instead in the middle of an incident, priced at recovery time rates.

Zero out of 800

The chain is only manageable if someone has drawn it, which brings us to the bluntest number in the State of Recoverability Report. Across more than 800 client engagements at Fenix24, the number of organizations that arrived at a recovery holding a complete picture of their applications and dependencies was zero. The closest approximations either sat in a configuration database that went down with the attack, or were assembled mid-recovery, once the breach forced the business to decide what it needed back first, and were then revised as restoration progressed.

Zero is worth dwelling on, because these organizations weren’t negligent. Many had CMDBs, asset inventories, and architecture diagrams. The problem is that all of those answer the question “what do we own,” and recovery asks a different one. What does this business service need back, in what order, and what does each of those pieces need in turn? Deployment documentation doesn’t carry restore order. The dependency knowledge that does exist lives in the heads of the engineers who built the integrations, some of whom have left, and the rest of whom may be unavailable at the exact moment the knowledge is needed. And the environment drifts with every migration and new SaaS contract, so even an accurate map ages out in months. A dependency map isn’t a document. It should be a living model.

The chain now runs through companies you don’t control

More of those dependency links sit outside the walls every year. Third parties now figure in roughly 30% of breaches, double their share from 2021, by the Identity Theft Resource Center’s count. Allianz’s claims data shows contingent business interruption from supplier and vendor events jumping from 6% to 15% of large claim value in a single year, more than doubling as a share of what insurers pay. The executives furthest along have noticed. Among CEOs of highly resilient organizations in the World Economic Forum’s 2026 outlook, 78% name supply chain and third-party dependencies as their top remaining challenge.

Hardening your own environment relocates the risk; it doesn’t eliminate it. Accenture’s 2026 survey measures the blind spot directly. Sixty-one percent of leaders say sustaining critical operations depends on external partners. Only 38% report a clear view of their value chain and its most critical dependencies. A dependency map that stops at the firewall is a map of half the chain.

Built for the adversary, useful for the outage

Cyber events sit at the top of DRI International’s global ranking of operational threats, with general IT disruptions close behind. The dependency knowledge above pays out in both. A defective software update or a cloud region failure also stops revenue, and also demands an answer to what comes back first. But the two conditions are related, not interchangeable. An outage takes systems down. An attack takes systems down and corrupts the credentials, backups, and directory the restoration would run on. A recovery capability built for the adversarial case absorbs the ordinary outage along the way. One built only for outages meets an adversary unprepared.

This is why we built Argos99, our resiliency intelligence platform, around the business service rather than the asset. The platform continuously models which services the organization depends on, what each service depends on, what backup coverage exists across the chain, what recovery sequence the dependencies dictate, and if the stated recovery objectives can be achieved. This means the model moves when the environment does. Discovering assets is a solved problem. Knowing what has to come back, in what order, and proving it can is the problem recovery presents.

Demand the map for one service

Take your most revenue-critical business service and demand its complete dependency map, third parties included. If the map doesn’t exist, no recovery timeline attached to that service means anything, because the timeline was estimated against a chain nobody has seen end to end.

A passing answer must clear four bars:

• It’s complete, down through identity, network, backup infrastructure, and the external integrations the service calls.
• It’s current, reflecting the environment as of right now rather than the architecture review two years ago.
• It’s survivable, stored somewhere that doesn’t go down with the attack.
• It’s sequenced, stating not just what the service needs but what order it returns in and how long each link takes against measured storage and bandwidth, not assumed.

Most organizations will clear none of these on the first ask. That result isn’t an embarrassment. It’s the single most useful finding a resilience program can produce this quarter, because every gap in the map is a week of future downtime identified while it still costs nothing.

Get the full report

The State of Recoverability 2026 pairs claims data from Allianz, research from the World Economic Forum, Accenture, and thirteen other institutions with Fenix24’s field data from more than 500 hands-on ransomware recoveries, the deepest body of recovery experience in the world. If you want to see what decides how long a business stays down, this is the evidence.

Click here to download Fenix24’s 2026 State of Recoverability Report.