Define a Minimum Viable Business for disaster recovery — before the next incident

COMMENTARY: Most disaster recovery plans are built around the reasonable assumption that if the systems are restored, the business gets restored. But that assumption has become increasingly wrong.

We can recover data and put workloads online with applications running. But if users cannot authenticate, DNS is wrong, edge policies are missing, IAM permissions are broken, and security teams can't see what’s happening, the business has not been restored.

That’s why CIOs and CISOs need to define their Minimum Viable Business (MVB) before their next incident.

[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]

The MVB represents the smallest operational version of the organization that the team must restore to continue serving customers, protect revenue, meet obligations, and maintain control during a crisis. Gartner has framed this shift as survival-mode recovery, restoring the critical functions required for operational viability instead of waiting for full-environment recovery.

Veeam has described MVB/MVC (minimum viable company) as a way to define the minimum operations, systems, processes, and data that we must restore after an attack. Rubrik has connected the same idea to the Minimum Viable Recovery Environment, where core business functions can run while the broader production environment remains in crisis.

It’s a clear direction: we’re talking about whether the business can actually operate, not  just about whether the backup has been completed.

Who decides what belongs in the MVB?

We can’t define the MVB via IT alone. That’s the first mistake.

After many conversations with CIOs, CISOs, infrastructure leaders, cloud teams, and business executives, one pattern has become clear. Organizations do not usually fail at recovery because they lack tools. They fail because they haven’t assigned clear ownership of the recovery decision.

Teams often start by asking what systems they can restore. It’s better to ask what part of the business must operate first:

The business must decide what’s critical, the CIO decides how to restore the data, and the CISO decides how to restore the data safely, or if that's possible in the first place.

If we’re missing one of those voices, the plan becomes fragile. IT may recover the wrong items first. MVB may stay theoretical. Or worse, the organization may restore compromise faster than it restores operations.

We can’t have a strategy that says: “Everything is critical.”

The company has to make the hard decisions around what’s actually critical.

In a recent conversation with a Fortune 500 infrastructure leadership team, we were discussing recovery priorities across cloud, identity, security, SaaS, and application delivery. The answer came back quickly: “Everything is critical.”

I understood the instinct. No leader wants to downgrade a system that may matter during a crisis. But if we rate everything critical, nothing gets prioritized. And if we don’t prioritize anything, recovery order becomes a negotiation during the worst possible moment.

That’s why organizations need a structured criticality discussion before the incident.

I call it MVB Criticality Scoring. We’re not looking for false precision. We want to separate what’s truly critical from what’s simply important.

Score each dependency from 1 to 5. A score of 1 means low relevance. A score of 5 means essential or immediate.

We've found that the real recovery risk becomes visible during the discussion behind the score, not the score itself.

Criticality comes from dependency

We don’t rate systems critical because they are expensive, visible, or politically important. It's critical because of what depends on it.

A customer-facing application may be Tier 1. But if DNS, edge routing, WAF policies, identity, certificates, or load balancers are missing, customers may still never reach it. A data platform may get restored. But if access policies, roles, groups, or SaaS settings are broken, teams typically can’t use them.

Here's where the traditional becomes too narrow. It asks whether we can restore the environment, while MVB asks whether the business capability can operate.

The practical questions are simple:

The questions matter because modern businesses do not recover through one system. They recover through a chain of dependencies.

That’s the recoverability gap inside many cyber recovery plans. The plan says the systems are protected, but the business process still cannot run.

We don’t want to ask whether the backup was completed. We ask what’s the smallest version of the business we must bring back? Who decides that? And, what dependencies could stop us from doing it?

An MVB turns disaster recovery from a technical recovery plan into a business survival strategy. That’s the conversation every CIO and CISO should have before the next incident.

Aharon Twizer, co-founder and CEO, ControlMonkey

SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.