How to Define Your Minimum Viable Business in Disaster Recovery

That is the real value of Minimum Viable Business, or MVB, in disaster recovery. MVB forces leaders to stop asking only whether infrastructure can be restored and start asking a harder question: what is the smallest version of the business that must come back first?

Most disaster recovery plans are built around a reasonable assumption: if the systems are restored, the business is restored. That assumption is increasingly wrong.

Your data can be recovered. Your workloads can be online. Your applications can technically be running. But if users cannot authenticate, DNS is misconfigured, edge policies are missing, IAM permissions are broken, observability is gone, or security controls are not restored, the business is not back.

The answer is not a list of favorite tools. It is not a static tiering exercise. It is a dependency model.

In a real disruption, recovery does not fail only because a database is missing or a workload is offline. It fails because no one decides what the business actually needs first.

• Is it Akamai, because customers cannot reach the application?
• Is it Okta or Entra ID, because nobody can authenticate or operate safely?
• Is it Datadog, because teams cannot prove whether recovery is stable?
• Is it cloud configuration, because IAM, routing, security groups, load balancers, and SaaS permissions decide whether restored systems can actually run?
• Is it really the customer database that must be the first one to restore?

This is the real question behind Minimum Viable Business, or MVB: what is the smallest version of the business that must come back first?

And who decides? CIO? CISO? IT? All together? 

In my next blog I want to give to CIOs, CISOs, and business leaders a structured way to answer that question before the incident forces the answer for them. Gartner, Veeam, and Rubrik have all pushed the recovery conversation in this direction: away from backup as a passive safety net and toward recovery models that prioritize the minimum business capabilities required to survive a disruption. Let’s dive in a bit.

TL;DR

• Minimum Viable Business is the smallest version of the business that must come back first during a cyber or cloud disruption.
• Traditional disaster recovery plans often rank systems, applications, and backups. MVB ranks business capabilities: what must operate first, what can degrade, and what can wait.
• The business defines what is critical, the CIO decides how it can be restored, and the CISO validates whether it can be restored safely.
• If everything is labeled critical, nothing is prioritized. MVB Criticality Scoring helps teams decide recovery order based on business dependency, recovery dependency, access, traffic, security, time sensitivity, and safe degraded operation.
• Backup completion is not the finish line. The real question is whether customers can reach the service, users can authenticate, teams can validate recovery, security can detect compromise, and engineers can rebuild safely.
• ControlMonkey helps make the configuration layer of the Minimum Viable Business recoverable by continuously backing up, versioning, and restoring critical cloud, identity, network, SaaS, observability, security, and DevOps configurations across AWS, Azure, GCP, Okta, Microsoft Entra ID, Cloudflare, Datadog, GitHub, GitLab, and more.

To Start – MVB Is Not Full Recovery

Minimum Viable Business is the smallest operational version of the organization that must be restored first to continue serving customers, protecting revenue, meeting obligations, and maintaining control during a crisis.

Gartner frames this as part of a shift toward survival-mode recovery: restoring only the critical business functions required for operational viability, instead of waiting for full-environment recovery. That distinction matters. In a serious cyber or cloud disruption, the goal is not to bring everything back at once. The goal is to bring back the minimum business capability that keeps the organization alive while the rest of the environment may still be compromised, degraded, quarantined, or under investigation.

MVB is not “restore everything.” It is not a prettier name for business continuity planning. It is a recovery decision model for survival mode.

The hard question is not whether the backup completed. The hard question is whether the business can still operate from what was restored.

The Business May Need to Run Before the Environment Is Fully Restored

During ransomware, a destructive misconfiguration, a cloud outage, a failed deployment, or an over-permissioned AI agent making changes at scale, the organization may not have the luxury of waiting for full-environment recovery.

Customers still need access. Payments still need to be processed. Support still needs records. Security still needs visibility. Executives still need to know what is safe to expose.

This is why MVB is becoming part of the cyber resilience conversation. Gartner describes ransomware recovery as moving toward survival mode, centered on the Minimum Viable Business concept. Veeam frames MVB and Minimum Viable Company as a way to define the minimum operations, systems, processes, and data that must be restored after a cyberattack. Rubrik connects the same idea to the Minimum Viable Recovery Environment, where core business functions can run while the broader production environment remains in crisis.

The market language is still evolving. The direction is not.

Backup completion is no longer the measure that matters most. The business question is operational viability.

MVB is not about restoring everything faster. It is about restoring the right things first.

Your DR Tiers May Not Match the Business

Most DR plans already have priorities: Tier 1 applications, Tier 2 systems, critical databases, important SaaS platforms, RTOs, and RPOs. It looks mature on paper.

But many of those priorities are still system-centric. They rank assets. They do not always explain whether the business can actually operate after recovery.

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 be restored, but if access policies, roles, groups, or SaaS settings are broken, teams may not be able to use it.

That is where traditional DR becomes too narrow. It asks whether the environment can be restored. MVB asks whether the business capability can operate.

That is a higher standard. It forces CIOs, CISOs, infrastructure leaders, and business owners into the same decision: what must keep running, what can degrade, what can wait, and what creates immediate customer, revenue, regulatory, or security impact?

By forcing leaders to move past the idea that every system is equally urgent, the MVB model provides a necessary, if sometimes uncomfortable, path toward true resilience.

Who Decides What Belongs in the Minimum Viable Business?

The Minimum Viable Business should not be defined by IT alone. That is the first mistake.

After many conversations with CIOs, CISOs, infrastructure leaders, cloud teams, and business executives, one pattern becomes clear: most organizations do not fail at recovery because they lack tools. They fail because ownership of the recovery decision is unclear.

Teams often start by asking what systems can be restored. The better question is what part of the business must operate first.

If the business does not define the MVB, IT may recover the wrong things first. If the CIO does not operationalize it, MVB stays theoretical. If the CISO does not validate trust, the organization may restore compromise faster than it restores operations

The MVB Ownership Model

Role	Responsibility
CEO / COO / business executives	Define which business services must operate first
CIO	Own recovery architecture, IT execution, and operational readiness
CISO	Own safe recovery, trust validation, identity/security controls, and cyber risk
CFO / Legal / Compliance	Define financial, contractual, regulatory, and reporting impact
I&O / Cloud / Platform / SRE	Map dependencies, recovery order, automation, testing, and readiness
Application owners	Validate whether recovered services support the actual business process
Communications / Customer Success	Define customer, partner, regulator, and board communication during survival mode

The simple rule is this: the business decides what is critical, the CIO decides how it can be restored, and the CISO decides whether it can be restored safely.

Minimum Viable Business only works when all three decisions are made together.

The C-Level Question: What Is Actually Critical?

The real MVB question is not “What tools do we use?”

It is: which business capability fails, or becomes unsafe, if this system or configuration is not recovered?

Akamai, Datadog, Okta, Entra ID, Cloudflare, AWS, Azure, GitLab, ServiceNow, Salesforce, and many other platforms may all be important. But they are not equally critical in every incident. They do not fail the business in the same way. They do not always belong in the same recovery wave.

Criticality Comes From Dependency, Not Visibility

A system is not critical because it is expensive, visible, or politically important. It is critical because of what depends on it.

Identity may not look like a revenue system. But if authentication, privileged access, service principals, groups, roles, or application registrations are broken, recovery can stall before applications are useful.

Observability may not serve customers directly. But without it, teams may be operating blind during the most dangerous phase of recovery.

Edge and DNS configuration may sit outside the application stack. But without them, customers may never reach the restored service.

This is the blind spot.

MVB is not a list of important tools. It is a decision model for what the business cannot operate without.

Introducing MVB Criticality Scoring

This is where Minimum Viable Business needs to become practical.

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 everything is critical, nothing is prioritized. And if nothing is prioritized, recovery order becomes a negotiation during the worst possible moment.

That is where I created MVB Criticality Scoring.

I use it with infrastructure, security, cloud, and business teams to separate what is truly critical from what is simply important. The model helps identify which business services, platforms, and configurations must recover first for the business to keep operating.

The purpose is not false precision. It is to force a structured discussion before the incident does it for you. It gives executives and technical leaders a common way to compare very different dependencies: identity, network, SaaS, cloud infrastructure, observability, security controls, DevOps workflows, and customer-facing services.

The Seven Questions That Expose Real Recovery Risk

A useful MVB score should answer seven questions.

Dimension	Executive Question	Score
Business dependency	Which critical business service fails without this?	1–5
Recovery dependency	Is this needed to recover other systems?	1–5
Access, traffic, or security control	Does it control login, routing, protection, or trust?	1–5
Time sensitivity	How quickly does the impact become material?	1–5
Safe degraded operation	Can the business operate safely without it?	1–5
Compliance and evidence impact	Is it needed for audit, forensics, reporting, or obligations?	1–5
Recovery confidence	Can its configuration be restored from a known-good point?	1–5

A score of 1 means low relevance to that dimension. A score of 5 means the dependency is essential or immediate.

The score is not the answer. The discussion behind the score is where the real DR risk becomes visible.

Turning Scores Into Recovery Tiers

From there, leaders can translate the score into a recovery priority.

Score	MVB Priority	Meaning
30–35	Tier 0: Recover first	Must be available first or the business cannot operate safely.
24–29	Tier 1: Required for MVB	Required for Minimum Viable Business operations.
17–23	Tier 2: Required for stable operations	Important for stable recovery, but may not block the first survival wave.
10–16	Tier 3: Important, but can wait	Needed for full recovery, but not immediate MVB.
Under 10	Outside immediate MVB scope	Not part of first-wave recovery.

This model exposes assumptions. It reveals ownership gaps. It shows where teams depend on manual reconstruction. It highlights systems that everyone assumes are protected, but nobody has actually tested.

It also moves recovery prioritization away from politics and toward business impact.

“Everything is critical” is not a strategy.

It is a refusal to decide.

Akamai vs. Datadog Is the Wrong Question

A common executive question sounds like this: which platform is more critical, Akamai or Datadog? That is the wrong question.

Akamai and Datadog serve different functions. Both may be critical, but for different reasons and at different moments in the recovery sequence.

When Akamai Becomes Tier 0

Akamai may become Tier 0 when it supports customer-facing DNS, CDN delivery, WAF policies, bot protection, edge routing, traffic failover, or application availability at the edge.

If that configuration is deleted, corrupted, or rolled back incorrectly, customer-facing systems may remain unreachable even if applications and data are restored.

The application is up. The business is still down.

When Datadog Becomes Tier 0 or Tier 1

Datadog may become Tier 0 or Tier 1 when it supports recovery validation, service health monitoring, incident response visibility, security detection, SLA reporting, and confidence that restored systems are stable.

If Datadog configuration is unavailable, the business may technically run for a short period. But recovery teams may be operating blind while attackers, misconfigurations, or degraded services are still active.

The business is moving. Nobody knows whether it is safe.

The Right Questions to find your Minimum Viable Business

Akamai may decide whether customers can reach the business. Datadog may decide whether the business can recover without operating blind.

That is why the question is not which tool is more important. The better question is which business capability fails, or becomes unsafe, if the configuration is not recovered.

Ask your team:

• Can customers still reach the application if DNS, CDN, WAF, or edge routing is not restored?
• Can employees, admins, and service accounts authenticate if identity configuration is damaged?
• Can recovery teams validate system health if observability dashboards, monitors, and alerts are gone?
• Can security teams detect compromise if logging, alerting, or access policies are missing?
• Can engineers deploy, roll back, or rebuild if Git, CI/CD, or permissions are broken?
• Can the business operate safely if this platform is unavailable for the first few hours?

That is the MVB mindset. Not “which tool matters most,” but “which dependency decides whether the business can operate.”

The Hidden MVB Dependency: Configuration

Most DR plans focus on applications, workloads, and data. That makes sense. Those things matter.

But in cloud and SaaS environments, the business also runs on configuration.

Configuration decides who can log in, where traffic goes, what is exposed, what is blocked, what gets monitored, who can deploy, which services can communicate, and which controls remain active during recovery.

A restored database does not mean a restored business.

Gartner’s Dependency Point Matters

Gartner’s MVB guidance points leaders toward mapping business functions to application dependencies, data requirements, identity services, and network configurations. That is the right framing: the business does not recover through one system. It recovers through a chain of dependencies.

Identity is the clearest example. If Okta, Entra ID, IAM roles, privileged access, or application registrations are broken, application and data recovery may still fail. The workloads may exist, but the business may still be unable to access, operate, or secure them.

The same is true for network and edge configuration. If DNS, routing, WAF, CDN, firewall, or load balancer configuration is missing, customer-facing services may remain unreachable or unsafe to expose.

This is where MVB becomes concrete. The minimum business is not only an application and its data. It is the configuration fabric around it.

The Business Outcome Depends on Configuration

Business Outcome	Configuration Dependency
Customers can reach the application	DNS, CDN, edge routing, load balancers, WAF, firewall rules
Employees can log in	Okta, Entra ID, IAM roles, groups, policies, MFA settings
Cloud services can communicate	VPCs, subnets, route tables, security groups, network ACLs
Security controls remain active	IAM, WAF, firewall, access policies, segmentation
Teams can validate recovery	Datadog monitors, alerts, dashboards, observability policies
Engineers can recover safely	Git repositories, CI/CD settings, permissions, deployment workflows
SaaS workflows continue	Users, groups, permissions, application settings, integrations

This is why MVB cannot stop at application and data recovery. The minimum business depends on the configuration fabric around those systems.

Configuration Changes Faster Than DR Plans

In cloud-native environments, that fabric changes constantly.

Some of it is managed through Infrastructure as Code. Some of it is not. Some of it was changed in a console. Some of it was changed by a deployment pipeline. Some of it was changed by an administrator under pressure. Increasingly, some of it may be changed by AI-driven workflows with broad permissions.

Gartner’s CAIRS framing reinforces this point: cloud-native applications are made up of far more than VMs and storage. They include networking, certificates, APIs, policies, load balancers, namespaces, security controls, and other dynamic dependencies. If IaC is incomplete or outdated, reconstruction during DR can become manual, slow, and risky.

When an incident happens, the organization may discover that it does not know what the last known-good configuration was. Or which version should be trusted. Or which dependencies must be restored first. Or who changed what. Or which resources were never covered by IaC in the first place.

You cannot recover the Minimum Viable Business if you cannot recover the configuration it depends on.

Backup Alone Does Not Answer the Minimum Viable Business Question

Backup is necessary. It is not enough.

Traditional backup asks: do we have a copy? MVB asks: can the business run from what we restored? 

That is a different standard.

Gartner has pointed out that modern application recovery requires more than data recovery. It requires the ability to recover the entire application, including configuration state.

That is where many DR plans remain exposed. Workloads may be restored, but IAM policies may be broken. Applications may be online, but WAF or routing policies may be missing. SaaS data may exist, but permissions and workflows may be wrong. Observability may be gone, leaving teams unable to prove recovery is stable.

The recoverability gap is simple: the plan says the system is protected, but the business process still cannot run.

Where ControlMonkey Fits

ControlMonkey helps make the cloud and SaaS configuration layer of the Minimum Viable Business recoverable.

It does not replace the full DR strategy. It closes one of its most overlooked gaps: the configuration required for the business to operate.

Make the Configuration Layer Recoverable

ControlMonkey discovers cloud resources across AWS, Azure, and GCP, along with SaaS and third-party configuration across identity, networking, security, observability, and DevOps systems. It identifies what is managed by Infrastructure as Code and what exists outside it.

It captures configuration as versioned recovery points, so teams know what existed, what changed, and what the last known-good state looked like.

During an incident, teams should not rebuild DNS, IAM, routing, SaaS permissions, WAF rules, monitors, or cloud infrastructure from memory. They should know which critical configurations are protected, which are exposed, and which must come back first.

Traditional backup restores data. ControlMonkey restores the configuration required to operate.