Musings on the Minimum Viable Company
What is a Minimum Viable Company?
Most organisations still plan recovery as if the main question is, “How do we restore our servers?”
While destructive cyberattacks remain the greatest threat to IT operations, and for a destructive cyberattack, that is the wrong starting point to build your resilience upon. The better question is: what is the smallest, safest version of the company we must restore first to keep operating, meet obligations and rebuild with confidence? That will constitute your Minimum Viable Company (MVC). While the term Minimum Viable Company is commonly used, the MVC concept is equally applicable to government, non-profit and commercial organisations.
The Minimum Viable Company is the smallest combination of business services, people, technology, data, facilities, suppliers and decision-making capability needed for an organization to continue its most important operations after a major disruption, including a destructive cyberattack.
It is not the same as “the whole IT infrastructure, but running slower.”
It is not “what we can bring back first.”
It is not just a business continuity & disaster recovery environment.
Think of a Minimum Viable Company as the emergency lighting in a building. It is not designed to support normal day-to-day operation; it exists to provide just enough safe capability to keep the organisation functioning during a crisis and guide it back to a trusted state. In the same way, a Minimum Viable Company represents the organisation’s safe operating core: enough capability to continue serving customers, protect people, meet legal and regulatory obligations, preserve cash flow, maintain communications, identify and remediate threats and support recovery back to a secure state with full scale and functionality. That way of thinking aligns closely with recent operational resilience guidance that focuses on critical business services, impact tolerances and the need to withstand severe disruption rather than simply restore individual systems.
Why IS A MVC needed?
Today organisations are under pressure from three directions at once.
Regulators increasingly expect resilience to be demonstrated at the level of business services, not just infrastructure. In Europe, DORA is now in force for the financial sector and requires stronger Information and Communications Technology (ICT) risk management, incident response, resilience testing and third-party risk management. NIS2 similarly strengthens cyber risk management and incident reporting obligations for an ever expanding definition of Critical National Infrastructure. In the UK, the Prudential Regulation Authority’s operational resilience framework is built around important business services and impact tolerances, and has pushed financial services organisations to prove that they can remain within tolerable disruption thresholds during severe but plausible events.
More broadly, this direction of travel is not limited to the UK and Europe. Regulators in other jurisdictions, as well as governments shaping future cyber and operational resilience policy, are increasingly moving toward similar expectations: that organisations must be able to identify their most important services, understand the dependencies that support them and demonstrate that they can continue or restore those services safely under stress.Modern attacks do not stop at encrypting files. Attackers routinely target identity systems, management planes, communications, backup policies and the security tools defenders depend on. NIST’s latest incident response guidance explicitly emphasises integrating incident response across broader cyber risk management and improving preparation, detection, response, and recovery as one connected discipline. That matters because destructive incidents are no longer just “security events”; they are business continuity, legal, operational and reputational events all at once.
Most enterprises are now deeply dependent on SaaS platforms and third parties. That creates convenience and cost savings in normal times and fragility and friction in bad times. If core identity, email, collaboration, ticketing or security tooling is compromised, the organisation can lose not just production systems but also the means to coordinate incident response and recovery. DORA’s emphasis on ICT third-party risk and registers of contractual arrangements is a sign of how central this dependency has become.
recover to a trusted state, not just a running state
A recovered company that immediately reintroduces attacker access or vulnerabilities is not resilient, it is just fast at repeating its past mistakes.
That is why the goal of the Minimum Viable Company is to establish a trusted state, that means the organisation has enough confidence that:
the attacker no longer retains meaningful access,
critical services can operate safely,
decisions are being made from reliable information,
the rebuilt environment is not quietly carrying forward the same compromise.
This is consistent with established incident response and recovery frameworks such as the NIST SP800-61, ISO 27035, SANS Institute six-step incident response process, UK National Cyber Security Centre incident response process that all mandate preparation, identification, containment, remediation, only then recovery and lessons learnt.
What DO I NEED TO recover a Minimum Viable Company?
Below is the practical core. These are the building blocks an organisation needs from an incident response and recovery perspective.
A clear definition of the services that truly matter
Before an incident, lines-of-business and leadership must decide which services are genuinely critical to survival for the first 24 hours, first 72 hours, first week and first month.
For most organisations, that means a short list such as:
Investigating and remediating the incident that caused the disruption.
Taking and fulfilling orders.
Handling payments.
Communicating with staff, customers, regulators and suppliers.
Operating the minimum required customer support capability.
Complying with legal, safety and regulatory obligations.
Preserving core records and evidence.
This is the business equivalent of deciding which rooms in a house must stay heated in winter. If you try to heat every room after the boiler fails, you may heat none. Operational resilience guidance uses a similar logic by focusing organisations on critical business services and their impact tolerances.
Dependency mapping that goes beyond applications
Most recovery plans stop too early. They name an application but not the hidden plumbing underneath it or the resources needed to . A Minimum Viable Company needs dependency mapping for:
Business services
Applications
Identity and access
DNS, DHCP and networking
Encryption keys and certificates
Privileged access,
Data stores and integrations
Third-party platforms
Key staff and decision-makers
Manual workarounds
Regulatory and contractual obligations
Documentation
Playbooks
Licence keys
Physical access control
When organisations don’t take the time to map dependencies properly, they tend to focus on restoring only the systems they interact with most often. The problem is that this approach overlooks the underlying services those systems rely on—services that can be just as critical to business continuity.
I’ve seen this firsthand while working as a retained incident responder. On one occasion, my team arrived on-site during a crisis, only to discover that neither we nor the organisation’s executives could access the building—or even the designated crisis room. The reason? The door access control system had failed, and no one had previously identified it as a business-critical function.
In another case, I worked with an organisation handling highly contagious diseases and tightly controlled substances. Their access control system was configured to default all locks to “open” if the management server became unavailable. That’s a striking example of a foundational system that, while often overlooked, carries enormous operational and security implications.
These experiences highlight a crucial lesson: it’s not enough to prioritise obvious systems. True resilience depends on understanding and planning for the full ecosystem of dependencies, including those quietly underpinning everything else. Unless you’ve previously suffered a destructive cyberattack that eliminates not just the availability of foundational services and documentation, but also your trust in those that remain, sometimes it is difficult to threat model exactly what the impact of a destructive cyberattack will look like. This is very different than a normal Business Impact Analysis as it needs to not just look at availability, but also needs to model adversary behaviour.
NIST’s guidance stresses integrating incident response into wider risk management and regulatory resilience frameworks similarly focus on the delivery of services rather than isolated technology components.
A real incident response capability, not just an IT escalation path
In a destructive attack, the organisation needs structured response resources, processes and technology that can:
Identify what happened, including gaps in security controls, vulnerabilities exploited and any residual persistence mechanisms.
Empowered to make containment decisions and execute on them.
Preserve evidence.
Prioritise recovery and remediation of attack surface and threats or rebuild systems to a trusted state.
Coordinate legal, communications and executive actions.
Manage external parties such as insurers, law enforcement, regulators and retained responders.
This sounds obvious, but many firms still conflate “the security team” with “incident response.” In practice, incident response is a cross-functional operating model. That is why mature frameworks emphasise preparation, shared-responsibility models, coordination, drills and lessons learned, not just technical troubleshooting.
A predefined crisis governance model
When the environment is unstable, decision latency becomes a business risk. The Minimum Viable Company requires a documented governance model that answers:
Who can declare a cyber crisis.
Who approves containment actions with business impact.
Who decides what gets recovered first.
Who owns external notifications.
Who can authorize emergency spending.
Who has authority if normal leaders are unavailable.
Who can authorise the repatriation of systems back into production.
This is less glamorous than security tooling, but it is often the difference between order and chaos. Regulators increasingly care about whether firms can govern disruption as much as whether they can technically recover from it. Creating a shared responsibility model for response and recovery, complete with clearly defined roles, responsibilities, handoffs, and decision points, is fundamental to restoring a Minimum Viable Company both efficiently and effectively.
Independent, trusted communications
A company cannot recover if it cannot talk. A Minimum Viable Company should assume the primary email tenant, collaboration suite, identity platform or mobile device management system could be unavailable or untrusted. That means establishing out-of-band communications for crisis coordination, executive direction, legal review and third-party engagement.
In practical terms, that may mean a separate communications capability, pre-positioned contact lists, alternate authentication paths and documented emergency procedures. The reason is simple: in destructive events, the systems used to coordinate response and recovery are often among the systems least safe to trust. This is especially relevant in an environment where so much operational tooling is SaaS-delivered and identity-dependent.
A clean investigation and recovery environment
Trying to investigate, rebuild and restore directly into an untrusted production environment is like trying to repair a ship while still taking on water. The organisation needs an intermediate clean environment for investigation and recovery: somewhere isolated enough to analyse, validate and rebuild without immediately reintroducing compromise. Different organisations call this a clean room, isolated recovery environment or recovery enclave. The name matters less than the properties:
Isolated from the compromised estate.
Controlled administrative access that doesn’t need the recovery of compromised identity platform.
Trusted tooling that hasn’t been evaded by the attacker.
Logging and evidence preservation.
The ability to conduct forensics, threat hunt and malware scan systems.
The ability to test systems and validate remediation before they are put back into service.
This requirement sits squarely between containment, eradication, and recovery in established response practice, even if many non-specialists know it by different names.
Trusted identity first
Identity is usually the skeleton key of the enterprise. If it is untrusted, everything else is suspect. That means Minimum Viable Company recovery must include a plan for:
Privileged access recovery,
Emergency or break-glass accounts.
Restoration of directory services or cloud identity in a controlled sequence.
Validation of administrative roles, federation and service accounts.
Review of policies, trust relationships and authentication paths.
Many recovery plans are application-first. In destructive cyber recovery, they should usually be identity-first or identity-near-first, because compromised identity can rapidly poison everything that comes after it. NIST’s guidance on incident response as part of broader risk management strongly supports treating these foundations as part of recovery planning, not as an afterthought.
Immutable, isolated, and usable backup data
Backups matter, but not all backups are equal. For a Minimum Viable Company, backup needs more than retention. It needs:
Immutability
Separation-of-duties for administrative tasks
Isolation from the primary administrative blast radius
Protection of backup policies and configurations
Validated recovery points
The ability to identify which copies predate encryption or deletion
Ability to support security tasks like filesystem forensics, cold log access, Indicator of Compromise hunting, malware scanning, sandbox detonation of suspect files and global search of files across the enterprise
This is where many organisations discover they have “backup” but not “recoverability.” A backup set that cannot be trusted, cannot be found quickly or cannot be restored into a clean environment is a comfort blanket, not a resilience capability. DORA’s focus on digital operational resilience, testing and third-party dependencies reinforces the need for controls that continue to work under stress, not just during routine IT operations.
A digital jump bag
Incident responders used to carry physical jump bags. The modern equivalent is digital. In my role at Cohesity we developed the Digital Jump Bag, a pre-staged collection of the assets needed to respond when normal systems are degraded or unavailable. The Digital Jump Bag is kept in an immutable vaulted environment and provide access to these resources within minutes, For a Minimum Viable Company, that should include things like:
Incident response playbooks
Call trees and contact lists
Architecture diagrams
Asset inventories
Privileged access procedures
Key software and license materials
Recovery runbooks
Legal and notification templates
Insurance and third-party retainer details,
Critical configuration baselines
It is the corporate equivalent of keeping passports, medicines and house keys in one grab bag near the door. You hope not to need it, but if the building is on fire that is not the moment to start assembling it.
Evidence preservation and forensic visibility
Investigation, remediation and recovery must work together as a closed-loop process. If recovery destroys the evidence needed to understand the attack, the organisation risks restoring the attacker’s foothold along with the business. That is why Minimum Viable Company planning needs a deliberate approach to:
Preserving logs and forensic images.
Retaining key communications and decisions.
Recording containment and remediation actions.
Maintaining a clear chain of events.
Separating urgent recovery steps from evidence destruction.
Established incident response practice consistently treats evidence preservation as part of effective response, not an optional extra. An immutable, Write Once Read Many, file store provides a suitable store with a strong chain-of-custody. Retained incident response companies have actually chosen my employer, Cohesity’s, platform for exactly this purpose for the incidents they’re brought into.
A defined restoration sequence
Not everything should come back at once, and not everything should come back in the same order every time. The Minimum Viable Company needs a recovery sequence that is well-defined and intentional. A common pattern to restore trust layer-by-layer is:
Crisis governance and trusted communications.
Identity and privileged access foundations,
Core networking and DNS.
Restore security tooling to a non-evaded trusted state.
The few highest-priority business services,
The data and integrations those services need,
This sequence mirrors the logic of preparation, investigation, containment, eradication and recovery in mainstream incident response thinking, but translates it into something executives and operations teams can actually use.
Verification before repatriation
This is one of the most overlooked disciplines in cyber recovery. Before a rebuilt service is returned to production use, someone should be able to answer:
Were all vulnerabilities found in operating systems, applications and configurations patched?
Were all malicious accounts, changes to configurations, registry keys, policy objects and other persistence mechanisms removed?
How was this validated?
What evidence supports trust?
What residual risk remains?
Who approved the return?
Without that decision gate, recovery becomes hope with a change window. Recovery to a trusted state depends on a repeatable verification step between eradication and wider restoration. That is implicit in established incident handling models and essential in practice.
BUILD Metrics that measure recovery, not just detection
Many organisations can quote headline metrics such as mean time to detect and mean time to recover. Far fewer build the more granular measures that actually drive continual improvement. Those are the metrics that matter when a destructive cyberattack occurs: not just whether the organisation can deliver its Minimum Viable Company, but whether it can do so in a controlled, efficient and effective way. Metrics my team help organisations build include:
Time to establish trusted communications.
Time to regain trusted administrative access.
Time to identify a viable clean recovery point.
Time to remediate attack surface.
Time to complete full eradication of the original attack path.
Time to restore the first important business service.
Time to verify a service before reintroduction.
The Forum of Incident Response and Security Teams has published timing metrics intended to help organisations identify delays and bottlenecks in incident response. That idea is important because what gets measured gets improved. If the Minimum Viable Company is the target, the recovery metrics must reflect that target.
Lessons learned that drive funded change
A post-incident review has no value simply because it was completed. Its value lies in whether it drives meaningful change across the organisation. Continually exercising realistic scenarios, and learning where people, process and technology need to improve, is at the heart of an effective cyber resiliency programme. It is what enables continual improvement, strengthens understanding of the shared-responsibility model, and builds the muscle memory needed to deliver a Minimum Viable Company when a crisis hits. A Minimum Viable Company approach should feed directly into the following activities:
Architectural changes.
Backup policy changes.
Training and mentorship.
Supplier decisions.
Runbook updates.
Board reporting,
Resilience testing.
Investment decisions.
This stage closes the loop with established incident response and recovery frameworks, which treat lessons learned as a formal phase rather than a courtesy meeting at the end.
What the Minimum Viable Company means for non-security leaders
For boards, executives, operations leaders and service owners, the message is straightforward:
An organisation does not need every system to survive the first phase of a destructive cyberattack. Instead it needs the right systems, the right people and the right controls, restored in the right order with enough trust reestablished to operate safely. That is the Minimum Viable Company.
It turns cyber resilience from an abstract promise into a set of practical design questions:
Which business services must survive?
What do they depend on?
How do we recover them safely if identity, communications, tooling and production are all suspect?
Who decides?
What evidence tells us we are ready to move forward?
Those are not just security or recovery questions, they are operating model questions.
Final thought
Today resilience is no longer judged by whether an organisation has a backup solution or a crisis plan on paper. It is judged by whether the organisation can continue the services that matter, within tolerable disruption, through severe events involving compromised technology and third parties. That is the direction of travel in regulation, best practice and the real-world attack patterns I see in my role every day. The Minimum Viable Company isn’t something you can buy, it is a practical way to answer the hardest recovery question of all: What is the smallest version of us that can survive, recover, and be trusted?
