Minimum Viable Company (MVC): Recover faster by restoring what matters most

Most organizations don’t fail to recover from cyber incidents because their backups break. One of the most common and least examined failure modes is trying to recover everything at once.

In the aftermath of a major incident, the instinct is to bring every system back online as quickly as possible. It feels like the fastest path to normal. In practice, it often does the opposite: slows recovery, reintroduces risk, and undermines trust at the exact moment organizations need to rebuild it.

The problem is often not capability alone. It is the absence of clear prioritization under pressure. In real incidents, entire workforces can be locked out overnight: devices wiped, identity systems unavailable or untrusted, and operations frozen. Backups alone are rarely the constraint. The real challenge is knowing what to restore, in what order, and what can be trusted.

The organizations that recover fastest operate from a fundamentally different premise. They assume that large parts of the enterprise will be unavailable or untrusted, and they plan accordingly.

This is the idea behind the Minimum Viable Company (MVC)—sometimes referred to as the Minimum Viable Organization: a definition of what must exist for the organization to survive.

Destructive cyberattacks change the equation

Recovery planning can no longer assume systems are merely compromised. Increasingly, organizations must contend with destructive attacks, including wiper attacks, in which systems and data may become unavailable, inaccessible, or untrusted. Planning for partial failure is no longer sufficient. Organizations must plan for systemic disruption.

In that context, the question is no longer: How do we restore everything? 
It is: What do we actually need to operate?

What is a Minimum Viable Company?

The Minimum Viable Company (MVC), or Minimum Viable Organization, is the smallest version of an organization that can continue to operate, serve customers, and meet its obligations under extreme conditions.

MVC goes beyond technology. It is a business definition of survival grounded in how the organization creates value. At Cohesity, we define MVC as the minimum combination of people, processes, technology, documentation, facilities, and third-party dependencies required to keep the business functioning under degraded conditions.

If you cannot map systems to business value, you cannot define your MVC. And if you cannot define your MVC, you cannot recover with intent. Cyber resilience goes beyond bringing systems back. It restores the ability to operate safely and credibly, in a trusted state.

Think of a Minimum Viable Company like emergency lighting in a building. It is not designed for normal operations. It provides just enough capability to keep the organization functioning safely during a crisis and guide recovery.

In practice, this means defining what must function in the first 24 hours, the first 72 hours, and the first week of a disruption.

The layer most organizations miss: trust and control

Even organizations that define MVC correctly often overlook the layer that enables recovery. They focus on business applications—customer portals, payment systems, clinical platforms—but in a cyber incident, those systems are only as strong and as trusted as the foundations beneath them.

We refer to this as Tier 0—the control plane for recovery. It includes the capabilities required to establish trust, coordination, and control:

• Identity and access management
• Networking and DNS
• Privileged access controls
• Core security tooling
• Physical access systems
• Secure communication channels

It also includes critical non-technical dependencies:

• Incident response playbooks
• Contact lists and escalation paths
• Insurance policies
• Contracts with external responders
• Software license keys, configurations, network diagrams, and asset registers

At the center of this foundation is identity—the effective skeleton key of the enterprise. If you cannot establish a trusted identity, you cannot safely restore anything else.

This risk is routinely underestimated. Identity systems such as Active Directory can contain far more than user accounts: Group Policy Objects that can redeploy malware, configurations that re-enable vulnerable services, and federated access paths that allow adversaries to re-enter even after credentials are reset.

If the identity layer is untrusted, recovery plans quickly become unworkable.

In many incidents, the first failure is not applications. It is coordination. A company cannot recover if it cannot communicate. Without secure communication channels established outside the compromised production environment, response efforts fragment immediately.

Organizations often attempt to restore critical systems only to discover they cannot authenticate users, validate configurations, or coordinate effectively. They are trying to rebuild without a trusted foundation. In many cases, it is overlooked dependencies, not primary systems, that fail first, from access control to supporting infrastructure that was never identified as critical.

Why cyber recovery is different

A persistent mistake is treating cyber recovery like traditional disaster recovery.

In the event of natural disasters or hardware failures, restoring the last known-good snapshot is often sufficient. In a cyber incident, it can be actively dangerous.

In a cyber incident, you are not restoring from failure. You are recovering from a compromise.

Rushing recovery without eliminating adversary persistence mechanisms or addressing the vulnerabilities that enabled the intrusion is likely to result in further impact. A recovered environment that reintroduces attacker access is not resilient. It simply repeats the same failure quickly.

This is where many traditional backup and disaster recovery approaches fall short: they were not designed to recover into a clean, trusted state under active compromise.

Leading organizations have moved toward a different model:

• Rebuild systems from known-good configurations in isolated environments
• Recover data separately from clean snapshots
• Investigate in parallel, not sequentially

This approach reduces recovery time, but only when executed in a trusted, isolated environment.

The role of the Digital Jump Bag™

To enable this, organizations need a way to rapidly re-establish control. We call this a Digital Jump Bag™. A Digital Jump Bag is a secure, isolated repository containing everything required to initiate a cyber response and establish a trusted recovery starting point.

Operationalizing this in practice requires not just documentation, but a platform capable of securely isolating, protecting, and orchestrating these assets.

A well-designed Digital Jump Bag includes:

• Hardened system images and known-good configurations
• Privileged credentials and access mechanisms
• Identity recovery artifacts
• Network configurations and architecture diagrams
• Incident response playbooks and recovery runbooks
• Key contacts and escalation paths
• Vendor contracts and external response agreements
• Essential software license keys

Crucially, it exists outside the compromised production environment—remaining accessible even when primary systems are unavailable or untrusted. With it, organizations can initiate their cyber response immediately with confidence in what they are rebuilding.

What operationalizing MVC actually requires

Defining an MVC is only one critical step. Resilience is proven under real conditions.

Operationalizing MVC requires five capabilities:

1. Clarity on critical services: A precise understanding of the systems and dependencies that directly support revenue and mission-critical operations.
2. A trusted foundation (Tier 0): The ability to establish identity, access, and control independently of compromised systems.
3. Isolation of recovery assets: Backups, configurations, and recovery tooling must be protected from the same blast radius as production.
4. Clean-room recovery capability: An isolated environment to rebuild systems without reintroducing compromise.
5. Validated ability to operate: Proving, not assuming, that the organization can function from its MVC.

In practice, recovery must follow a deliberate sequence—typically starting with governance and communication, then re-establishing identity and control systems, before restoring business services and supporting data.

These capabilities align with widely adopted industry incident response and recovery frameworks and closely map to Cohesity’s five-step cyber resilience framework: identifying critical assets, protecting and isolating them, defending the control plane, recovering in a clean environment, and continuously validating readiness through testing.

An untested plan remains theoretical. As one financial services leader put it, you have to “practice failure.” Rehearsal answers the question every board asks: How long will it take to restore our critical services to a trusted state?

From concept to capability

The gap between strategy and execution is where most resilience efforts fail. In practice, this means working through realistic failure conditions:

• How do you authenticate users if identity systems are unavailable or untrusted?
• How do you communicate if collaboration platforms are down or untrusted?
• How do you access critical documentation if systems are unavailable or dependent on third parties that have not yet recovered?

Through threat modeling, structured workshops, baseline assessments, and realistic attack simulations, organizations can surface these gaps and build a pragmatic, testable approach to delivering their MVC.

This work requires alignment across IT, security, and the business, but the alternative is prolonged disruption, regulatory exposure, and material financial loss. Organizations that do this well leave with:

• Clear visibility into Tier 0 dependencies
• A validated shared-responsibility model across IT, security, and business teams
• A repeatable approach to recovering critical services to a trusted state

An MVC is not static. As the business evolves, so must its definition.

Recovery as a capability—not a process

The real risk is not failed backups, but failing to define what must come back first, and how to bring it back in a state that can be trusted. That is the difference between recovery as a process and recovery as a capability.

Do not restore everything at once. Restore enough to operate without recreating the conditions that caused the failure.

For organizations that have not yet defined their MVC, the first step is a structured assessment, alignment across business and technology stakeholders, and a realistic simulation of how recovery will actually unfold under pressure.

Cohesity works with organizations to define, validate, and operationalize their MVC through workshops, simulations, and platform-driven recovery capabilities, so that when a major incident occurs, recovery is executed with clarity, speed, and trust.