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

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.

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

1. 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.
2. 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.
3. 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.
4. 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.
5. Map data: which datasets the degraded service needs, where the clean copy lives and how old it may be.
6. 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.

• 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

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

1. 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.
2. Stand up tier 0: move responders to out-of-band channels and clean workstations. See the Out-of-Band Communications for Incident Response Guide.
3. Select restore points: work with investigators to date initial access, choose restore points from before it, and validate them in an isolated staging environment.
4. 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.
5. 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.
6. Communicate progress to staff, customers and regulators at fixed intervals (CSF RC.CO-03). See the Crisis Management Guide.
7. 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

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.

Standards and references

• NIST: SP 800-184 Guide for Cybersecurity Event Recovery
• CISA: #StopRansomware Guide
• Microsoft Learn: Active Directory Forest Recovery Guide
• Microsoft Learn: AD Forest Recovery, Perform initial recovery
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Inhibit System Recovery

Related NHI Mgmt Group resources: Cyber Resilience Guide · Identity Recovery Guide · Ransomware Response and Recovery Guide · Cyber Recovery Vault Guide · Cybersecurity Event Recovery Guide