The first post in this series laid out the confidence-capability gap and how a cyber resilience control plane is designed to close it; the second unpacked how correlated signals close the gap between detection and action. This blog takes up what happens after the response — where recovery, as typically practiced, answers the wrong question.
Most recovery is built around availability: what can be restored, and in what order. But it asks what’s possible to restore, when what the business needs is what matters most to restore — and that gap is where recovery falls short.
Why availability-based recovery fails the business
Consider a regional logistics company recovering from a ransomware event. The billing system comes back online in four hours, so finance can issue invoices. But dispatch and routing — which coordinates drivers, schedules pickups and tracks deliveries — takes twelve. For eight of those hours the business is paralyzed despite billing being available: drivers can’t be dispatched, customers can’t get answers, contracts are in jeopardy.
The recovery plan worked, but the business was still down in every way that mattered. Restoring billing first felt like progress, yet it never restored the minimally viable business — the functions the company needs to operate. Dispatch and routing was that function, and it came back last: a predictable outcome when recovery is sequenced by what’s technically convenient rather than operationally critical.
How does data map to business function in recovery?
The storage and data layer is where this problem can be addressed, because data isn’t just a component of recovery — it’s a representation of business activity. But a business function rarely maps to a single system with a single recovery point.
Dispatch and routing might depend on a database protected by frequent snapshots, an application tier backed up nightly and reference data in an immutable vault — each with a different age and level of trust. During an incident, the hard part is rarely a missing recovery point; it’s deciding which combination of them brings the service back safely.
That decision is difficult because recovery assets are organized by platform, while the business operates through services. Most organizations have the knowledge to bridge that divide, but it’s scattered across storage, backup and application teams rather than connected to the recovery infrastructure — so sequencing happens under pressure, based on whoever is in the room at 2 a.m.
The direction this points toward is associating data with business function at the platform level — correlating signals across Dell storage so a protected data set connects to the function it supports. That mapping defines the minimally viable business before an incident. It’s the logical extension of what the cyber resilience control plane is building toward: a data layer that doesn’t just protect and restore, but understands what it’s protecting and why it matters.
Why recovery readiness must be continuous, not reactive
The best time to answer “what matters most?” is before a recovery is needed. Much of the time lost isn’t the restore itself — it’s the forensic work that comes first: determining what was compromised and what’s safe to restore.
Defining the minimally viable business in advance removes much of that guesswork from the critical path. The question then shifts from “how quickly can we recover?” to “how prepared are we to recover the minimally viable business right now?”
How should you measure cyber resilience for the board?
Recovery time and recovery point objectives still matter, but only when measured at the level of a business service rather than an individual system. A four-hour RTO for billing is a technical SLA — it says nothing about whether the logistics operation can function within that window.
In its joint cyber resilience work with Dell, Deloitte argues that organizations should identify the services necessary for survival and map them to define their minimally viable business — protecting and recovering those rather than treating every bit and byte as equally critical.¹
This is also where mean time to recover (MTTR) matters more than any objective on paper. An RTO is only a target until you’ve rehearsed against it — organizations should run recovery dry runs to confirm their actual MTTR meets or beats their RTO for each critical service, before an incident tests it for them.
Regulators are moving the same way. The question is shifting from “is your data stored securely, immutable and isolated?” to “can you prove you can recover your business services — and how quickly?”
An organization that can answer that — here’s the minimally viable business we can restore, in this order, within this time — is having a fundamentally different conversation than one reciting “we have backups.”
How the cyber resilience control plane restores the minimally viable business
This is where the control plane closes the loop. Once it has mapped protected data to the business functions it supports, it can do what platform-by-platform recovery cannot: orchestrate restoration around the service itself. Rather than coordinating separate restores across primary storage, backup and vault — each evaluated and sequenced by hand under pressure — the control plane identifies the most trustworthy recovery points for a given service, restores its dependencies in the right order and brings the minimally viable business back as a single, coordinated action. That is the difference between having the pieces of a recovery and being able to execute one. And that is what this series has been building toward: detection, response and recovery operating not as three separate problems owned by three separate teams, but as a single, continuous discipline — one that doesn’t just protect your data, but restores your business.
To see how we got here, start with the first post in this series on the confidence-capability gap, then the second on coordinating detection and response across the storage layer.
Frequently Asked Questions
What is a cyber resilience control plane? A cyber resilience control plane is a coordination layer that unifies signal intelligence across the storage and data layer and triggers coordinated action. It correlates signals that individual platforms generate in isolation, establishes the confidence needed to act earlier and is designed to extend that same intelligence into recovery. Dell is building toward these capabilities across its storage ecosystem; they are not all generally available today.
What is a minimally viable business in cyber recovery? A minimally viable business is the minimum set of functions an organization needs to actually operate after a cyber attack. Recovering it means restoring those essential functions first, in a sequence decided in advance, rather than improvising priorities during an active incident.
How is business-priority recovery different from availability-based recovery? Availability-based recovery answers what is possible to restore and in what order systems can be brought back online. Business-priority recovery answers what matters most to restore so the organization can resume operating. The gap between those two questions is where recovery routinely falls short of what the business needs.
Why don’t backups alone guarantee business recovery after ransomware? A recovery plan can succeed technically while the business remains operationally stranded, because restoring systems in order of convenience is not the same as restoring the functions the business depends on. Knowing you have backups, or that a system has a four-hour recovery time objective, says nothing about whether the business can actually operate within that window.
How does Dell’s cyber resilience control plane prioritize recovery? The direction Dell is building toward is associating data with business function at the platform level, correlating signals across Dell storage so a protected data set can be connected to the business function it supports. That mapping lets an organization define its minimally viable business before an incident, so the recovery sequence reflects operational priority from the outset. This is the logical extension of the cyber resilience control plane, not a capability that exists fully today.
Dell reported this
Source: www.dell.com
Source link
