Business leaders should define which services must operate first, CIO and infrastructure teams should define how they can be restored, and security leaders should validate whether the restored state is safe. If one function owns the decision alone, recovery priorities usually skew toward technical convenience instead of operational reality.
Who should decide what belongs in the minimum viable business?
The minimum viable business should not be defined by a single function. It is a joint decision: business leadership sets the services that must come back first, infrastructure and platform teams define what can actually be restored, and security validates whether the recovered environment is safe enough to operate. That split keeps recovery aligned to real operations, not just technical convenience.
Why the decision has to be shared
The phrase “minimum viable business” sounds simple, but it is really a boundary-setting exercise. It defines which business capabilities are essential for continuity, which systems support those capabilities, and which dependencies can be deferred without causing unacceptable harm. If one team controls the whole decision, the result is usually biased toward its own constraints, such as uptime optics, technical elegance, or speed of restoration.
Business leaders are the only group positioned to say which customer-facing, revenue-bearing, regulatory, or safety-critical services are truly first-order priorities. They understand what failure means in operational terms. Infrastructure and application owners, by contrast, know which systems are prerequisites, which recovery steps are sequential, and where the real restoration bottlenecks sit.
What each function contributes to the recovery decision
Business leadership should define the outcome, not the implementation. That means identifying the smallest set of services that allows the organisation to meet core obligations, serve critical customers, and resume essential operations. A service may be technically important without being business-critical in the first recovery wave, so this step is about materiality, not system age or complexity.
CIO and infrastructure teams should translate that business priority into a recoverable sequence. They can tell you which platform layers, integrations, data stores, secrets, identity dependencies, and network paths must be restored before an application can do useful work. NIST Cybersecurity Framework 2.0 is useful here because recovery has to be planned as a lifecycle function, not treated as an afterthought.
Security leaders should challenge the proposed recovered state. A system is not “back” if it is back in an unsafe configuration, with excessive access, stale secrets, missing monitoring, or unresolved compromise indicators. A service that is operational but still exposed can create a second incident during recovery. NIST AI Risk Management Framework is not the centre of this question, but its governance logic fits the same principle: recovery must be assessed against acceptable risk, not just technical availability.
How to avoid a biased minimum viable business definition
The strongest way to avoid skew is to separate three questions. First: what must the business be able to do? Second: what must be restored for that to happen? Third: what security conditions must be true before the service is trusted again? Those answers usually come from different owners, and forcing them into one role creates blind spots.
In practice, the best decisions use a short, explicit approval path: business signs off on critical services, technology signs off on feasibility and order of restoration, and security signs off on trustworthiness of the recovered state. That keeps the minimum viable business tied to operating reality while still respecting recovery constraints and control requirements.
Risk and Threat Considerations
If the minimum viable business is defined too narrowly, the organisation can restore the wrong things first and leave the real operating core unavailable. If it is defined too broadly, recovery teams may spend precious time rebuilding low-value systems while critical services remain down. The same problem can also create a security gap if restoration proceeds before compromised accounts, weak access paths, or unsafe configurations are contained.
Failure mechanism: One function, usually IT or infrastructure, treats recoverability as the same thing as business criticality, and the restored environment is accepted without business or security validation.
Impact: Recovery priorities drift toward technical convenience, critical processes stay offline longer than necessary, and the organisation may resume operations on an environment that is still unsafe or incomplete.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Planning | Recovery prioritisation depends on defining which services must return first. |
| GV.OC-01 — Organisational Context | Minimum viable business is set by core business functions and obligations. | |
| GV.RM-01 — Risk Management Strategy | Security must validate whether the restored state is safe enough to operate. | |
| Recommendation — Map critical services into recovery order and keep the plan tied to business priorities. Align recovery scope to the organisation’s mission, services, and critical dependencies. Define the risk threshold for resuming services and require it before go-live. | ||
Practitioner Guidance
What to prioritise: define the minimum viable business as a three-part decision, business criticality, restoration feasibility, and safety of the recovered state. If any one of those is missing, the recovery order is usually wrong.
What to verify: ask whether the proposed “restored” service can actually support the business process end to end, including dependent platforms, data, access, and monitoring. A technically live system that cannot complete the business transaction is not viable.
Decision rule: if the proposed recovery path is driven mainly by what is easiest to rebuild, treat it as a technical recovery plan, not a business prioritisation model. The minimum viable business should be anchored in operating necessity, then translated into restoration order.
Practitioner takeaway: the right owner for the decision is the business, but the right decision only happens when technology and security are allowed to constrain it with restoration reality and trustworthiness checks.