Start by identifying the smallest set of services, data, processes, and approvals needed to continue operating after disruption. That definition should be owned jointly by business, IT, security, and recovery teams, because it determines what gets restored first, what can wait, and where automation matters most.
What minimum viable business actually means in recovery planning
Minimum viable business is not a slogan for “keep the lights on.” It is the smallest operating state that still lets the organisation serve its most critical customers, meet unavoidable obligations, and make approved decisions after a disruption. For recovery planning, that means defining the minimum set of services, data, people, and approvals required to restart in a controlled way.
The definition should be narrow enough to be executable, but broad enough to reflect how work really gets done. A process without its approval path is not recoverable. A restored application without the data it depends on is not useful. A business function that cannot be authorised by the right owner is not yet viable.
How to scope the minimum viable business
Start from outcomes, not systems. Ask which customer commitments, revenue-bearing activities, safety obligations, regulatory deadlines, and internal decisions must continue first. Then map the smallest supporting chain behind each one: the records it needs, the systems that hold those records, the staff or teams that operate them, and the decision rights that allow action.
This is where many recovery plans fail. Teams often list infrastructure services, but they skip the business dependency chain that makes those services useful. The right unit of analysis is the business capability, not the server, the app, or the department. Once the capability is defined, you can decide what gets recovered in hours, what can wait until day two, and what can be operated manually for a short period.
That scoping also needs ownership. Business leaders define what is indispensable, IT defines what can be technically restored, security defines what can be restored safely, and recovery teams reconcile those views into a sequence that is realistic under time pressure. For a useful recovery plan, these owners must agree on the same minimum operating picture before an incident, not during one.
What belongs in the minimum set, and what does not
The minimum set usually includes a small number of core services, essential datasets, the people who can perform critical tasks, and the approval or exception paths needed to operate them. It does not usually mean full feature parity, all integrations, or every reporting workflow. If a capability can continue with reduced automation, a manual workaround may be acceptable for a defined period.
Security teams should be deliberate about where control can be simplified and where it cannot. Recovery often creates pressure to widen access, relax checks, or bypass normal workflows. That may be necessary for speed, but it should be explicitly bounded. If a restored process needs emergency access, then the access should be time-limited, monitored, and revoked when the business returns to normal operations.
The practical test is whether the restored business state can be operated repeatedly, not just started once. If a team can bring a service back but cannot process exceptions, approve transactions, or verify changes, the organisation has restored technology without restoring business capability.
How minimum viable business changes restoration priorities
Once the minimum viable business is defined, it becomes the basis for recovery order. The first systems to restore are the ones that unlock multiple critical processes, not the ones that are merely most visible. The same definition also helps decide what can remain degraded, what data must be made available immediately, and where temporary manual control is safer than rushing a partial automation rebuild.
It also clarifies trade-offs. Faster recovery may require a smaller functional scope, reduced integrations, or a temporary shift to manual approvals. More complete recovery may take longer, but it may reduce operational confusion and reconciliation work later. Security teams should document those trade-offs in advance so leaders are choosing knowingly instead of improvising under stress.
For teams that want a broader recovery frame, the NIST Cybersecurity Framework 2.0 is useful because it treats recovery as part of a larger resilience lifecycle, while FIRST is helpful for incident-response coordination discipline when recovery and response overlap.
Risk and Threat Considerations
Defining minimum viable business too loosely creates a recovery plan that is easy to write but hard to execute. The main risk is restoring systems that look operational while the business still cannot approve, reconcile, or safely complete work. In a disruptive event, that gap can extend downtime, increase error rates, and push teams into uncontrolled workarounds.
Failure mechanism: Recovery teams restore technology before they restore the decision rights, data dependencies, and control points that make the business process safe to run.
Impact: The organisation can resume activity in a fragile state, with higher fraud, error, compliance, and rework exposure, and with a greater chance that emergency access or manual bypasses persist longer than intended.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP — Recovery Planning | Recovery planning defines the minimum operating state and restore order after disruption. |
| GV.RM-01 — Risk Management Strategy | Minimum viable business is a risk-based prioritisation decision across services and processes. | |
| RC.IM-01 — Recovery Improvements | Recovery exercises should refine the minimum viable business definition as conditions change. | |
| Recommendation — Map critical capabilities to RC.RP and sequence restoration around the dependencies that re-enable business operations. Use GV.RM-01 to set recovery priorities by business impact, dependency and acceptable downtime. Use RC.IM-01 to update the minimum viable business definition after tests, incidents and lessons learned. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | Contingency planning is the control home for restore order, responsibilities and essential functions. |
| CP-4 — Contingency Plan Testing | Testing validates whether the minimum set of services, data and approvals is actually recoverable. | |
| AC-2 — Account Management | Recovery often depends on whose access and approvals are needed to operate critical processes. | |
| Recommendation — Align minimum viable business with CP-2 so contingency plans restore essential functions in the right order. Use CP-4 exercises to prove the minimum viable business can operate under degraded conditions. Use AC-2 to ensure critical recovery roles and emergency access are defined before disruption. | ||
| ISO/IEC 27001:2022 | A.5.29 — Information security during disruption | This control addresses maintaining security while operating through disruptive events. |
| A.5.30 — ICT readiness for business continuity | ICT recovery readiness directly supports defining the minimum viable technology set for business continuity. | |
| Recommendation — Apply A.5.29 to keep essential business functions operating without dropping security safeguards. Use A.5.30 to align ICT recovery capabilities with the business's minimum operating requirements. | ||
| CIS Controls v8 | CIS-11 — Data Recovery | Data recovery is central to restoring the records and datasets that minimum business processes require. |
| Recommendation — Use CIS-11 to ensure the minimum viable business has recoverable data and tested restore points. | ||
Practitioner Guidance
What to prioritise: Define the minimum viable business as a business capability map, then rank capabilities by dependency depth. The best early signal is not “most critical application,” but “which capability unlocks the most other recovery work.”
What to verify: For each minimum capability, verify that you have the required data, the named decision owner, the fallback approval path, and the recovery sequence for dependent services. If any one of those is missing, the capability is not yet recoverable in practice.
Common mistake: Teams often equate “minimum viable” with “barely restored infrastructure.” In reality, the minimum must include the operating controls that keep the restored business trustworthy enough to use.
Practitioner takeaway: The recovery plan should restore the ability to make safe business decisions first, because technology alone does not equal operational viability.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- How do security teams know whether minimum viable recovery is actually working?
- How should organisations define minimum viable business for resilience planning?
- What do teams get wrong about minimum viable recovery planning?