TL;DR: Minimum viable business, or MVB, shifts disaster recovery from restoring systems to restoring the smallest set of business capabilities needed to operate safely, with identity, DNS, routing, observability and cloud configuration often deciding whether recovery actually works, according to ControlMonkey. The real risk is not failed backup, but restoring an environment that still cannot authenticate, route traffic, or prove it is safe to use.
NHIMG editorial — based on content published by ControlMonkey: Minimum viable business recovery and the configuration layer
By the numbers:
- 57% of organisations lack a complete inventory of their machine identities.
- 69% of organisations now have more machine identities than human ones.
Questions worth separating out
Q: How should security teams decide what to restore first after a disruption?
A: They should start with the business capability, not the individual system.
Q: Why do identity systems become recovery dependencies in cloud environments?
A: Because authentication, privileged access, and service-to-service trust determine whether restored systems can be used at all.
Q: What breaks when recovery plans ignore configuration dependencies?
A: The environment may come back online but still fail operationally.
Practitioner guidance
- Define the minimum viable business for each critical service Map the smallest operational capability that must return first, then identify the identity, routing, SaaS, observability, and security dependencies that make it usable.
- Put IAM and NHI dependencies into recovery runbooks Include authentication services, privileged roles, service accounts, application registrations, and recovery access paths in the documented sequence for survival-mode restoration.
- Version the control plane, not just the data Track cloud policies, DNS, edge settings, firewall rules, security groups, and SaaS permissions as recoverable configuration states with known-good baselines.
What's in the full article
ControlMonkey's full article covers the operational detail this post intentionally leaves for the source:
- A worked MVB Criticality Scoring model with seven scoring dimensions and a tiering method for recovery prioritisation
- Specific examples of how identity, DNS, cloud, SaaS, and observability dependencies map to survival-mode recovery
- A role-by-role ownership model for CIO, CISO, business leaders, and platform teams during an incident
- The configuration-layer recovery approach across AWS, Azure, GCP, Okta, Entra ID, Cloudflare, Datadog, GitHub, and GitLab
👉 Read ControlMonkey's analysis of minimum viable business recovery →
Minimum viable business recovery: what should teams restore first?
Explore further
Minimum viable business is really minimum viable trust. The article is framed around recovery, but the deeper issue is whether the restored environment can be trusted to run. If identity, access, and configuration are not recovered in the right order, organisations may bring systems back while still being unable to operate them safely. That is a governance problem as much as an availability problem, and practitioners should treat trust restoration as part of recovery design.
A question worth separating out:
Q: Who should own the minimum viable business decision in a crisis?
A: Business leadership should define the capability that must return first, IT should own the recovery architecture, and security should approve whether the restored state is safe. If those decisions are not assigned in advance, recovery becomes a debate under pressure and teams often restore the wrong things first.
👉 Read our full editorial: Minimum viable business recovery depends on identity and config