Cyber Resiliency Board Briefing 5: Minimum Viable Company: Why Recovery Priorities Must Be Decided Before the Crisis
Executive Summary
In a previous post about the Minimum Viable Company I highlighted the reality that following a major destructive cyberattack, every organisation faces the same reality: everything cannot be recovered at once.
Recovery is constrained by finite infrastructure, limited technical specialists, vendor support, clean recovery environments, recovery tooling and executive decision-making. Success therefore depends not on how quickly systems can be restored, but on knowing which business services must be restored first.
Many organisations believe they have already answered this question through their Business Impact Analysis (BIA). In reality, most BIAs identify critical applications, servers or business processes rather than the complete collection of people, technology, data and dependencies required to deliver an operational business service.
The concept of the Minimum Viable Company (MVC) changes the question from “Which systems are critical?” to “What is the minimum set of business services we must restore to continue meeting our obligations?”
Those obligations extend far beyond generating revenue. They include protecting life and safety, meeting regulatory requirements, fulfilling contractual commitments, maintaining customer confidence and preserving the organisation’s ability to operate.
This distinction often determines whether recovery is orderly or chaotic.
The Technology Trap
Traditional disaster recovery planning has largely been technology-centric. Recovery plans often prioritise:
Critical applications
Critical servers
Tier 1 infrastructure
Recovery Time Objectives (RTOs)
Recovery Point Objectives (RPOs)
These are all important, but none of them actually describes how the organisation delivers value.
Customers do not buy applications. Regulators do not regulate servers. Contracts are not fulfilled by databases. Patients are not treated by virtual machines. Citizens are not served by storage arrays.
The organisation delivers business services, and those services are enabled by hundreds of interconnected technical and operational components.
Recovering technology is not the objective, restoring trusted business capability is.
Services, Not Systems
Consider something as simple as processing a customer order.
The business service may appear straightforward, but behind the scenes it could depend upon:
Identity services
Active Directory
DNS
Certificate services
Networking
Firewalls
ERP
CRM
Payment gateways
Licensing servers
Email
Internet connectivity
Third-party suppliers
Cloud identity providers
None of these components delivers value independently. Only when they function together does the business service exist.
Recovering an ERP platform before identity services, or restoring a customer portal before payment processing, achieves very little.
Technology should therefore be recovered in support of business services, not because an application appears at the top of a priority list.
Hidden Dependencies and Tacit Knowledge Become Recovery Bottlenecks
One of the most consistent observations I have made while helping organisations recover from ransomware is that the greatest delays are often caused by dependencies that nobody realised existed.
Examples include:
A forgotten licensing server that prevents dozens of applications from starting.
A legacy DNS server supporting only one critical business service.
A certificate authority that expires during the incident.
A single database supporting multiple unrelated business services.
An undocumented scheduled task required for overnight processing.
A third-party API that cannot be reconnected until vendor approval.
Equally common are human dependencies.
Many organisations unknowingly rely upon a single administrator, engineer or application owner whose understanding of a critical system exists almost entirely in their own head.
Recovery plans often assume that individual will always be available. Reality is less accommodating.
They may be on annual leave, unwell, unreachable or no longer employed by the organisation. Even when they are available, they frequently become the recovery bottleneck because every recovery team depends upon their knowledge simultaneously.
During major ransomware incidents I have seen these individuals work around the clock for days, supporting hundreds or even thousands of recovery decisions. Fatigue increases, stress levels rise and mistakes become more likely. In several incidents, key individuals resign during recovery taking years of undocumented operational knowledge with them.
These are not technology failures, they are resilience failures caused by undiscovered dependencies.
The Minimum Viable Company
The Minimum Viable Company (MVC) identifies the minimum collection of business services required for an organisation to continue operating safely, legally and commercially following a major cyber incident.
It asks fundamental business questions:
Which services protect life and safety?
Which services are required to meet regulatory obligations?
Which services fulfil contractual commitments?
Which services preserve customer confidence?
Which services are essential to maintaining financial viability?
Once those services have been identified, they are decomposed into everything required to deliver them, including:
Applications
Infrastructure
Identity
Networks
Data
Third-party providers
Supporting processes
Critical documentation
Specialist personnel
Vendor relationships
Operational knowledge
Only once these dependencies are understood can realistic recovery priorities be established.
The MVC transforms recovery planning from restoring systems into restoring the organisation itself.
Deciding During the Crisis Is Too Late
During a major cyber incident, every business unit believes its systems should be restored first.
Without predefined service priorities:
Recovery order changes repeatedly.
Infrastructure teams receive conflicting instructions.
Executives spend valuable time negotiating priorities.
Technical teams repeatedly pause and restart recovery activities.
Recovery resources are allocated inefficiently.
Critical dependencies are discovered only after recovery has already begun.
Meanwhile, the organisation remains unable to deliver the services that matter most.
Recovery priorities should never be established in the middle of an incident. They should already have been agreed by the business.
What Good Looks Like
Organisations with mature cyber resilience capabilities define recovery around business services, not individual technologies.
Rather than asking which applications are Tier 1 or Tier 2, they identify the minimum set of services required to continue operating and then map every dependency required to deliver those services.
This includes not only applications and infrastructure, but also identity platforms, networks, third-party providers, operational procedures, data flows, privileged accounts, supporting documentation and the individuals whose knowledge is essential to recovery.
Recovery priorities are agreed by the business, not IT, long before an incident occurs and are validated through realistic cyber recovery exercises.
Every executive understands not only what will be recovered first, but why those services take precedence over every other request.
When an incident occurs, there is no debate over priorities because those decisions have already been made.
Practical Analogy
Imagine attempting to reopen a hospital after a fire.
You would not begin by restoring every room in alphabetical order, nor would you prioritise whichever department shouted the loudest.
Instead, you would first restore the services required to treat patients safely: emergency care, operating theatres, pharmacy, medical gases, communications, clinical systems and the staff needed to operate them.
Everything else follows. Cyber recovery is no different.
Organisations do not recover by restoring servers. They recover by restoring the services that allow them to protect people, meet legal obligations, honour contractual commitments and continue operating.
Technology is simply one of the many components required to deliver those services.
Questions to Ask Your Executive Team
Have we defined our Minimum Viable Company, or have we only identified critical applications?
Which business services are essential to protect life, meet regulatory obligations, fulfil contractual commitments, preserve customer confidence and continue operating?
Have we mapped every technology, identity, data, third-party dependency and operational process required to deliver those services?
Have we identified individuals whose tacit knowledge could become a recovery bottleneck?
If one of those individuals were unavailable during an incident, could recovery still proceed?
Have our recovery priorities been validated through realistic cyber recovery exercises involving executive decision-making?
Key Takeaways for the Board
Cyber recovery should prioritise business services rather than individual technologies.
A traditional Business Impact Analysis is necessary, but it is rarely sufficient to define cyber recovery priorities.
Hidden technical dependencies and tacit knowledge frequently become the greatest source of recovery delay.
Recovery priorities should support the organisation’s obligations to customers, regulators, employees and society—not simply its technology estate.
Recovery priorities must be agreed before a crisis, not negotiated during one.
The Board’s Role
The Board should ensure that recovery priorities reflect business outcomes rather than technology ownership.
This means challenging management to demonstrate not only that critical systems can be restored, but that the organisation understands how essential business services are delivered and what dependencies could prevent their recovery.
The Board should expect evidence that recovery priorities have been agreed across the executive team, validated through exercises and supported by realistic recovery plans that account for technology, people and third-party dependencies.
The Board’s responsibility is not to decide which servers are restored first. It is to ensure the organisation has already decided which business services must survive, and that management can demonstrate those services can be recovered in a trusted state.
Closing Thought
During every major cyberattack, the question is never “What can we recover?”, the real question is “What must we recover first to continue meeting our obligations?”
The organisations that answer that question before the crisis begins recover faster, make better decisions and avoid turning technical disruption into prolonged operational failure.
Applications don’t deliver business value. Business services do.
