You Can't Recover What You Can't Describe

The testing wave is right. Here is the part underneath it.

A new class of tools has started to say something I agree with. Recovery should be continuously tested, not rehearsed once a year in a drill that everyone already knows will fail. They scan your cloud, watch for the configuration drift that quietly breaks a failover path, and tell you when a secret expired or a route changed. That is real progress. For twenty years recovery was a binder, and a binder is out of date the day it ships.

Joe Ruck wrote the buyer's version of this from the field, four point solutions, each solving a real problem, none answering the question a board asks every quarter. You can read it here. I want to go under that argument, into engineering, because the reason the question stays unanswered is mechanical, and it is worth seeing.

My favorite question to ask a CISO was always the same. Something happens tonight. Walk me through what you actually do. The answer is almost always "we have backups." Fine. Describe it to me step by step. And almost no one can answer it cleanly, including some of the sharpest security leaders I have met. That is not a knock on the team. It is that nobody ever wrote down how the business actually comes back, so there is nothing to walk through.

Recovery is a three-layer problem

Here is the mechanism. Recovery has three layers. Infrastructure, data, and application. Infrastructure is the compute, the network, the routing, the security groups. Data is your backups and replicas. Application is the thing your customers care about, the ordering system, the payment flow, the patient portal. All three have to come back, in the right order, configured correctly, and talking to each other. Miss one and the other two are just decoration.

Most of the new testing tools live at the first layer. They verify that the failover environment exists and that traffic can reach it. That is necessary. It is also where it gets hard, and the part nobody has solved is the part that matters most.

Take a real shape of enterprise. A Fortune 500 that grew through a decade of acquisitions. One business application, say the thing that takes an order and gets paid, might touch a hundred resources across three clouds and two regions. Some of it is in Terraform. Most of it is not. Some of it was written by an Accenture team that rotated off the contract two years ago. A major piece of it was generated by an AI coding assistant last quarter, and the person who prompted it could not tell you today what it provisions. You can pass every infrastructure check on every one of those hundred resources and still cannot say whether the application comes back, because the application is the choreography across all of them, and the choreography is what nobody has written down.

You can't recover what you can't describe

That is the line I keep coming back to. You can't recover what you can't describe.

Restoring a single S3 bucket or a single VM is, in operational terms, useless. The resource is healthy and the business is still on the floor. Infrastructure testing tells you each dancer can stand up. It does not tell you they remember the routine.

What changes the equation is the ability to reason across a heterogeneous environment and build the map first. We go in agentless and metadata-only, no software on your production hosts, no access to your data, and we build what I think of as an X-ray of the organization. A real-time model of how the business is actually wired, correlated across all three layers, updating in real time as the environment drifts. The output is not a list of resources. It is your business applications, scored, with the recovery dependencies made explicit. So the conversation moves from "this security group is misconfigured" to "this revenue-generating system has a recovery gap, here is the chain, here is the owner."

Why this was not possible until now

Here is the frontier. Full recovery simulation, provisioning a business application from zero in a clean environment and proving it stands, is genuinely hard, and nobody does it today. There is a good reason why. It was computationally intractable until very recently. The leaders at Rubrik, Cohesity, Veeam, and Commvault are not missing this. They shipped backups because backups were the tractable common denominator across every customer, and every organization looks different. One-size-fits-all reasoning is exactly what made the application layer impossible to automate before modern AI. The map is the prerequisite to everything past it, and the map is what we built first.

This is also why I do not think a foundation model subsumes this. A model does a specific job well. It does not hold a real-time, correlated context layer for how your specific business is built and how it changes by the hour. That context layer is the work, and it is the thing that makes simulation, validation, and proof reachable instead of theoretical.

Start with the map

So the framing I would push back on, gently, is "recovery is an infrastructure problem." It is the layer most visible to the engineer, and it is real, and it deserves the attention these new tools are bringing to it. It is also the floor. The application layer is where the business lives, and you reach it by describing the estate, not by testing one layer of it harder.

Describe it, and recovery stops being an assumption and becomes a state you can measure. That is the order of operations. Map first. Everything else, validation, simulation, proof, compliance evidence under DORA, follows from the map.

If you want to know which of your business applications can actually recover, and which only look like they can, that is what a Resilience Assessment shows you. Fifteen minutes, read-only, full report in five days, in your environment, not a slideshow. Resilience you can prove, across cloud, IaC, backups, and on-prem hypervisors.

‍