Minimum Viable Company and Recovery Order Guide

After a destructive attack that takes out identity, servers and endpoints at once, the question is not how to restore everything but what the smallest working company looks like and in what order to rebuild it. Traditional disaster recovery assumes a trusted control plane survives: directory, backups, admin accounts and network. Ransomware and wiper incidents remove that assumption, and teams that have not decided the order in advance lose days arguing about it while every dependency they missed blocks the next step. This guide explains how to define a minimum viable company (MVC), map the dependencies under each critical service, and set a recovery order with exit criteria for each stage, from a clean recovery environment through identity, network and core platforms to business applications and endpoints. It is for resilience leads, infrastructure architects and incident commanders; it builds on the concepts in the Cyber Resilience Guide.

Key takeaways

Define the MVC in business terms first. List the few services the organisation must run to survive (take orders, pay staff, dispense medicine, ship goods), then derive the people, data and technology beneath each one.
Identity and the recovery tooling come before applications. NIST SP 800-184 notes that identity and authentication systems usually come first because files, messaging and other services depend on them; before that you need a clean place to work from.
Every stage needs exit criteria. A tier is "done" only when it is restored, verified clean and tested, so the next tier is not built on a compromised foundation.
Plan the degraded state, not just the restored one. Approved manual workarounds keep the MVC running while systems come back, and SP 800-184 treats partial restoration as a legitimate interim goal.
Rehearse the order. The first time the sequence is tested should not be the real incident; exercise it, time it, and fix the dependencies the exercise exposes.

What a minimum viable company is

A minimum viable company is the smallest set of business services, people, data and technology that lets the organisation operate at a level its leadership, customers and regulators can tolerate after a severe incident. The term is industry usage rather than a standard, but it maps directly onto established concepts: critical asset identification (NIST SP 800-53 CP-2(8)), criticality analysis (RA-9), important business services and impact tolerances in UK financial regulation, and CSF 2.0 outcome ID.AM-05, assets prioritised by criticality and impact on the mission.

Concept	Classic disaster recovery	MVC recovery after compromise
Assumption	Site or system lost; control plane trusted	Control plane (directory, admin accounts, backups, management tools) may be compromised
Unit of planning	Systems with RTO and RPO	Business services with a tolerable outage and a degraded mode
Recovery source	Replica or latest backup	Known-good backup, golden image or rebuild from code, checked for persistence
Order	Usually by system priority	By dependency, starting with a clean recovery environment and identity
Success	System back online	Service running on verified clean infrastructure, with attacker access removed

See the Business Continuity and Disaster Recovery Guide for the classic model and the UK Financial Operational Resilience Guide for impact tolerances.

Defining the MVC: from services to dependencies

Pick the services: run a business impact analysis to identify the services whose loss becomes intolerable fastest (cash, safety, legal obligations, customer harm). Most organisations end up with three to eight. Use the Business Impact Analysis Template.
Set the degraded target: for each, define the minimum level (for example, "accept phone orders for top 200 products" rather than "full e-commerce") and the maximum tolerable outage.
Map people and process: who performs the service, which manual steps exist, which suppliers are involved. SP 800-184 asks for inventories of people, process and technology, including external partners.
Map technology dependencies: applications, databases, integrations, identity, network, DNS, certificates, licensing servers, SaaS and the admin tools needed to rebuild them. Include less obvious dependencies; SP 800-184 gives the example of mail degrading when directory services degrade, and warns about manual processes that move data between systems.
Map data: which datasets the degraded service needs, where the clean copy lives and how old it may be.
Record it as a dependency graph, not a spreadsheet of systems, so you can compute order. Keep a printed or offline copy.

The recovery stack and recovery order

Dependencies differ by organisation, but the layers below repeat in almost every estate. Recover bottom up; inside each tier, restore only what the MVC needs first.

Tier	Contents	Exit criteria before the next tier
0. Command and recovery environment	Out-of-band communications, clean admin workstations, isolated recovery network, offline copies of plans, credentials vault and dependency map, forensic capability	Responders can talk, authenticate and work without touching the compromised estate
1. Recovery tooling and data	Backup platform and catalogue, immutable or vaulted copies, golden images, infrastructure as code and pipelines	Backup system trusted; restore points chosen from before the intrusion and scanned for persistence
2. Identity	Directory (for example one writable domain controller per domain, forest root first), cloud identity provider tenant, privileged accounts, PKI, MFA	Attacker-controlled accounts, keys and tokens removed; privileged credentials reset; identity verified clean
3. Core network services	DNS, DHCP, time, firewalls, VPN or ZTNA, remote access for administrators	Segmented recovery network with egress control; logging flowing to a clean collector
4. Security tooling	EDR, logging and SIEM, vulnerability scanning	Every restored host monitored from first boot
5. Data platforms and integration	Databases, file stores, message queues, integration middleware	Data integrity checked against business reconciliation, not just technical checks
6. MVC business applications	ERP, order handling, payroll, clinical or trading systems needed for the degraded service	Business owners confirm the service works end to end
7. Endpoints and users	Reimaged or new devices for MVC staff first, then everyone else	Devices enrolled, compliant and monitored before they join
8. Everything else	Remaining applications by business priority	Recovery end declared on agreed criteria (CSF RC.RP-06)

Not strictly linear: SP 800-184 notes recovery may need a step backward, for example taking a restored system offline again to recover another. Plan parallel workstreams once identity and network are trusted.
SaaS and cloud: many MVC services run in SaaS. Their dependency is usually your identity provider and administrator accounts, so regaining control of the tenant moves into tier 2. See the Cloud Recovery and Clean Room Guide.
Machine identities: service accounts, API keys, certificates and integration secrets used by MVC applications must be rotated or reissued when their tier is restored, otherwise the attacker keeps a path back in. See the Service Account Security Guide.

Identity first: what the identity tier involves

Identity is the tier that most often stalls recovery. Microsoft's Active Directory forest recovery guidance gives the core pattern: recover the forest root domain first and parent domains before children; restore one writeable domain controller per domain from a backup not influenced by the failure; keep it isolated until verified; reset the krbtgt password twice, because its password history holds two passwords; reset the domain controller computer account and, after a breach, trust and administrative passwords before adding more domain controllers; then reconnect in stages and check replication with repadmin /replsum and dcdiag /v.

Decide restore or rebuild: restore when you have a backup from before the intrusion and confidence in the persistence sweep; rebuild a new forest or tenant only when no trusted point exists, accepting a far longer recovery.
Cloud identity: regain break-glass access to the identity provider, remove unknown administrators, federation trusts, app registrations and credentials, and revoke sessions and refresh tokens.
Isolate backup identity: a backup platform that authenticates against the compromised directory cannot be trusted in tier 1. See the Backup Identity Isolation Guide.

The detailed procedures are in the Identity Recovery Guide.

Restore, rebuild or run degraded

Option	Use when	Risk	Typical speed
Restore from backup	Clean restore point exists before initial access; data needed as it was	Restoring dormant persistence or droppers; CISA advises checking backups for malware before restoring	Fastest for data-heavy systems
Rebuild from golden image or code	Stateless servers, cloud resources, endpoints; CISA recommends pre-configured standard images and infrastructure as code templates kept offline	Images and pipelines must themselves be trusted	Fast if images and code are current
Rebuild from scratch	No trusted image, backup or code	Configuration drift and missed settings	Slowest
Run degraded (manual workaround)	Systems will not be back within the tolerable outage	Errors, fraud and data reconciliation later	Immediate if pre-planned
Fail over to a standby or alternate provider	Independent standby with separate identity and admin plane	Standby compromised through shared credentials or replication	Fast if genuinely independent

Decision guidance:

Small organisations often recover faster by moving the MVC onto SaaS with a fresh identity tenant and new devices than by restoring on-premises servers. Pre-agree that option and its cost.
Large organisations need parallel recovery teams per tier, a central recovery cell that owns the order, and pre-staged hardware or cloud capacity for clean rebuilds.
Regulated sectors should align MVC services with the services regulators already expect you to protect, and agree in advance what "recovered" means for reporting.

Running the recovery

Activate: two or more named managers can invoke the recovery plan, as SP 800-184 recommends. The incident commander confirms that containment is sufficient to start rebuilding.
Stand up tier 0: move responders to out-of-band channels and clean workstations. See the Out-of-Band Communications for Incident Response Guide.
Select restore points: work with investigators to date initial access, choose restore points from before it, and validate them in an isolated staging environment.
Work the tiers in order, recording exit criteria evidence for each. Only clean systems join the recovery network; CISA warns against re-infecting clean systems during recovery.
Bring up the MVC services with business owners testing end to end, and switch from manual workarounds to systems gradually, reconciling data entered during the outage.
Communicate progress to staff, customers and regulators at fixed intervals (CSF RC.CO-03). See the Crisis Management Guide.
Declare the end of recovery against agreed criteria, then move to the strategic phase: SP 800-184 describes a tactical phase driven by the playbook and a strategic phase focused on improvement.

Rollback within recovery: if a restored tier shows signs of compromise, isolate it, return to the previous verified tier and choose an earlier restore point; do not patch over it while later tiers depend on it.

Testing and measurement

Exercise the order with a tabletop first, then a technical rehearsal that restores the identity tier and one MVC service into an isolated environment. See the Tabletop Exercise Guide and the Restore Testing and Recovery Assurance Guide.

MVC time to operate: measured time from invocation to each MVC service running in degraded mode, compared with its tolerable outage.
Identity tier recovery time: time to a verified clean directory and identity provider in a rehearsal.
Dependency map accuracy: number of undocumented dependencies found per exercise (should fall each time).
Restore success rate: percentage of timely restorations from backup, a metric SP 800-184 lists.
Clean source coverage: share of MVC systems with a current golden image, code template or vaulted backup.
Workaround readiness: share of MVC services with a tested manual procedure and trained staff.

SP 800-184 also cautions that metrics collection should not slow recovery and that comparing resilience metrics across organisations can mislead.

Common failure patterns

Applications first: pressure to restore the customer-facing system before identity is clean leads to rebuilding on a directory the attacker still controls.
Recovery tools depend on the estate: backup consoles, hypervisor management and password vaults that authenticate against the compromised directory or sit on the encrypted network.
Plans only exist online: the dependency map, runbooks and contact lists are on the file server or wiki that is down.
Hidden dependencies: licensing servers, certificate authorities, time sources, DNS records and integration accounts that nobody listed, each found one at a time during the outage.
Restoring the attacker: restore points chosen after initial access, or unrotated service account and API credentials, letting the intrusion resume. Attackers often target recovery too (ATT&CK T1490 Inhibit System Recovery); see the T1490 Inhibit System Recovery Defensive Guide.
No degraded mode: without approved workarounds, the business has nothing to do but wait.

Lessons from incidents

Online channels can stay down for weeks: in the Marks and Spencer cyberattack, online and app orders were paused on 25 April 2025 and restarted in June, with stores running manual workarounds in the meantime. Decide in advance which channel is in the MVC and which can wait.
Disconnecting to contain stops dependants too: in the Change Healthcare breach, systems were disconnected after ransomware was deployed in February 2024 and claims, eligibility checks and pharmacy payments were disrupted nationwide for weeks. Map the external parties who depend on your services (CSF GV.OC-04) and include them in the degraded plan.

Framework mapping

Framework	Reference	Relevance
NIST SP 800-184	Recovery planning, playbooks, tactical and strategic phases, metrics	The primary recovery planning guide
NIST SP 800-53 Rev. 5	CP-2 Contingency Plan; CP-2(8) Identify Critical Assets; RA-9 Criticality Analysis	Defining the MVC
NIST SP 800-53 Rev. 5	CP-9 System Backup; CP-10 System Recovery and Reconstitution; CP-4 Contingency Plan Testing; IR-4 Incident Handling	Recovery sources, order and rehearsal
NIST CSF 2.0	ID.AM-05; GV.OC-04; RC.RP-01 to RC.RP-06; RC.CO-03; ID.IM-04	Prioritisation, recovery execution, verification, end criteria and communication
CIS Controls v8.1	Control 11 Data Recovery; Control 17 Incident Response Management	Recovery process and incident roles
ISO/IEC 27001:2022	A.5.29 Information security during disruption; A.5.30 ICT readiness for business continuity; A.8.13 Information backup	Continuity and backup controls
MITRE ATT&CK	T1486 Data Encrypted for Impact; T1485 Data Destruction; T1490 Inhibit System Recovery	The impact techniques the MVC plan must survive

Practitioner checklist

Agree with leadership the three to eight services in the MVC and the degraded level and tolerable outage for each.
Map people, suppliers, data and technology dependencies for each MVC service as a graph, and keep an offline copy.
Set the tiered recovery order with written exit criteria, starting with a clean recovery environment and identity.
Make sure backup, hypervisor and vault administration do not depend on the production directory.
Keep current golden images, infrastructure as code and vaulted backups for every MVC system.
Document and train manual workarounds for each MVC service.
Include service accounts, API keys and certificates in each tier's rotation step.
Rehearse the identity tier and one MVC service in an isolated environment at least annually and time it.
Name who can invoke recovery and who owns the order, and pre-agree communication intervals.

Minimum Viable Company and Critical Service Recovery Order Guide: Deciding What to Rebuild First