Table of Contents
Having backups is no longer enough to demonstrate that a business is prepared for a cyberattack. Regulations such as DORA and NIS2, combined with increasingly disruptive cyber incidents, are shifting the conversation from “Do we have a backup?” to “Can we restore the services our business needs to survive?”
The Minimum Viable Company (MVC) approach addresses this challenge by starting with a different question: what is the smallest part of the business that must be operational first?
Instead of trying to restore everything at once, an organization identifies its most critical services, the people and technology they depend on, and the recovery priorities that will allow essential operations to continue.
Key takeaways
- Operational resilience is about maintaining critical business services, not simply restoring data or infrastructure.
- Recovery statistics reveal a significant gap between documented recovery objectives and what organizations can actually achieve after a major incident.
- A Minimum Viable Company is the smallest combination of services, people, technology, data, facilities, suppliers and decision-making capabilities needed to sustain critical operations.
- Backup is a prerequisite, not a recovery plan. Storage capacity, network bandwidth, identity systems and application dependencies can determine whether recovery succeeds.
- Tiered recovery objectives are more realistic and cost-effective than attempting to restore the entire environment within a few hours.
- Regular recovery tests help validate assumptions and identify weaknesses before an incident occurs.
What operational resilience really means
Operational resilience is an organization’s ability to continue delivering essential products and services during a disruption and to recover its operations within an acceptable timeframe.
It goes beyond backup and disaster recovery. It involves people, processes, technology, infrastructure, suppliers and decision-making procedures working together when normal operations are disrupted.
An organization may have redundant infrastructure and complete backup copies but still be unable to serve customers if its identity systems, communication channels or critical suppliers are unavailable.
In the European Union, operational resilience is also an important regulatory concern. DORA establishes digital operational resilience requirements for financial entities, while NIS2 requires relevant essential and important entities to implement business continuity measures, including backup management, disaster recovery and crisis management.
The practical challenge is turning these requirements into recovery capabilities that can be demonstrated and tested.
The recovery gap: what the data shows
Recovering from a major cyberattack or infrastructure outage is often more difficult than organizations expect.
An Omdia survey of 700 IT decision-makers in the United States and Europe, commissioned by Object First, found that 64% of organizations had experienced an outage exceeding their Recovery Time Objective (RTO). In addition, 76% reported that their largest data-loss event exceeded their Recovery Point Objective (RPO).
Fenix24’s The State of Recoverability 2026 report offers another perspective, based on the company’s field experience from more than 500 ransomware recoveries and over 800 client engagements.
Its findings highlight several recurring problems:
| Finding from Fenix24 (2026) | Implication for recovery planning |
|---|---|
| Only 4 of more than 800 clients came close to their own 24–48-hour recovery targets, and only for part of their operations | Documented recovery objectives may not reflect actual recovery capabilities |
| In 38% of engagements where backups survived largely intact, they still could not support recovery | A surviving backup copy is not necessarily a usable recovery point |
| Storage capacity was insufficient in 82% of engagements; network bandwidth was insufficient in 38% | Recovery infrastructure must be sized and tested, not assumed |
| Approximately one-fifth of the first 48 hours was spent on the identity environment alone | Identity recovery needs to be part of the recovery strategy |
| 94% of clients operated backup infrastructure joined to the production directory that attackers compromised first | Backup administration and production identity require careful separation |
| No client arrived with a complete picture of application dependencies | Dependency mapping is essential when defining recovery priorities |
These findings come from Fenix24’s own engagements, rather than a representative survey of all organizations. They should therefore be treated as evidence of recurring recovery challenges, not universal industry-wide failure rates.
The underlying lesson is nevertheless important: having backup copies does not automatically mean a company can restore its business.
What is a Minimum Viable Company (MVC)?
A Minimum Viable Company is the smallest combination of business services, people, technology, data, facilities, suppliers and decision-making capabilities required to keep an organization operating after a major incident.
The idea is straightforward: when a destructive cyberattack affects the entire IT environment, restoring every system at once may be impossible, unnecessarily expensive or simply the wrong priority.
Instead, the organization identifies the minimum set of capabilities needed to continue essential operations.
This usually includes:
- processes that generate revenue;
- services essential to customers;
- systems required to meet critical business obligations;
- the people authorized to make decisions and coordinate recovery;
- the infrastructure and data on which those capabilities depend.
The key question changes from “How do we restore the entire environment?” to “What must work first for the business to keep operating?”
Ready to protect your data?
Why traditional disaster recovery plans can fail during a cyberattack
Traditional disaster recovery plans often focus on scenarios such as hardware failure, fire, flooding or loss of a data centre. They typically describe how to restore infrastructure and systems in a predefined order.
A destructive cyberattack can create a very different situation.
Servers may be compromised or wiped. Authentication systems may no longer be trustworthy. Backup administration may be affected by compromised credentials. Communication channels may be unavailable, and external dependencies may no longer work.
In such circumstances, restoring the entire environment according to a conventional infrastructure recovery sequence may not be practical.
An MVC approach introduces business priorities into the recovery process. It helps the organization decide what must be restored first, what can wait and which dependencies must be available before critical services can operate safely.
MVC priorities differ by industry
There is no universal MVC blueprint. The minimum operational environment depends on the organization’s business model.
| Business | Inside the MVC | Can wait |
|---|---|---|
| E-commerce platform | Website, order processing, payment acceptance and logistics | Customer-service chatbot and non-essential analytics |
| Brewery | Production control and systems supporting manufacturing operations | Corporate website and non-critical internal applications |
| Healthcare provider | Patient records, clinical systems, essential communication and critical infrastructure | Non-essential reporting and administrative applications |
| Financial services provider | Critical transaction processing, identity, payment systems and regulatory reporting capabilities | Development environments and non-essential analytics |
The examples are illustrative. Each organization should define its own priorities through a business impact analysis and dependency assessment.
Five building blocks of a Minimum Viable Company
Restoring a minimum operational version of the business requires planning across five interconnected areas.
| Building block | What it includes |
|---|---|
| 1. Infrastructure foundation | Identity management (Active Directory / Entra ID), DNS, DHCP, network connectivity and essential security tooling |
| 2. Critical applications | Systems essential to operations and revenue, such as ordering, ERP, invoicing, payment gateways, production and logistics applications |
| 3. Data and dependencies | Critical databases and datasets, together with a map of dependencies between systems, applications and external services |
| 4. People and communication | Clear decision-making responsibilities, recovery teams and alternative communication channels for situations where corporate email and messaging are unavailable |
| 5. Interim processes | Emergency procedures, including manual or paper-based workflows that allow the organization to continue serving customers while IT systems are rebuilt |
These building blocks should be considered together. A critical application cannot operate without its data, identity services, network connectivity and the people responsible for managing it.
Common mistakes when defining an MVC
1. Defining a minimum that is too narrow
An incomplete dependency map can leave critical services unavailable even after their primary applications have been restored. A system may depend on an external service, database or authentication component that was never included in the recovery plan.
2. Turning the minimum into a maximum
Every department may consider its own systems essential. Without clear priorities and agreement at management level, recovery teams can face conflicting demands and decision-making delays during an incident.
3. Creating a plan that exists only on paper
Documentation alone does not demonstrate recoverability. Recovery assumptions need to be tested against real infrastructure, available capacity and operational constraints.
4. Ignoring people and decision-making
Technical recovery cannot progress efficiently if nobody knows who can authorize actions, communicate with customers or make decisions when normal management channels are unavailable.
Backup is a prerequisite, not the plan
Having backups is necessary, but it does not guarantee that a business can recover.
An organization may possess complete copies of its data and still be unable to restore essential services within the required timeframe.
Fenix24’s findings illustrate why. In its 2026 engagements, storage capacity fell short in 82% of cases, while network bandwidth was insufficient in 38%.
Other common obstacles include:
- insufficient compute resources to run restored workloads;
- missing application components or undocumented dependencies;
- unavailable identity and authentication services;
- incorrect permissions or access configurations;
- recovery infrastructure that has not been tested under realistic conditions.
There is also a security consideration. After a ransomware incident, organizations must establish that the recovery environment is trustworthy before bringing systems back online. Restoring compromised systems without addressing the initial access path or persistence mechanisms can expose the business to another incident.
A recovery strategy must therefore cover more than backup creation. It needs to address the infrastructure, security controls and operational procedures required to restore business services safely.
For more on this topic, see Ransomware Recovery.
What an MVC needs from its data protection platform
A Minimum Viable Company cannot be implemented through business planning alone. The organization also needs a data protection platform that supports its recovery priorities.
Several capabilities are particularly important.
Get your free 60-day trial
Immutability and isolation of backup copies
Backup copies should be protected against unauthorized modification and deletion. This is especially important when an attacker gains access to production systems or administrative credentials.
Storware Backup and Recovery supports immutable backup configurations using XFS-based repositories. With the appropriate configuration, backup data is protected against modification and deletion during the defined retention period.
Storware also provides isoLayer, an isolation mechanism in which a secondary storage share is mounted for the duration of backup and restore operations. This reduces the period during which the repository is accessible to the surrounding environment.
These mechanisms can strengthen protection against ransomware, but their effectiveness depends on the complete security configuration, including repository hardening, access controls and network architecture.
Learn more in the Immutable and Air-Gapped Backup guide.
Separating backup administration from production identity
If backup administration relies entirely on the same identity infrastructure that an attacker compromises, recovery operations may be disrupted before they even begin.
A recovery architecture should therefore consider how administrative access is maintained when production identity services are unavailable or untrusted.
Storware Backup and Recovery runs on Linux and provides role-based access control (RBAC) for administrators. Its authentication and administrative configuration should be designed with appropriate separation from production identity, including carefully controlled credentials and access to the backup infrastructure.
The exact authentication model depends on the deployment and configuration. Organizations should validate their recovery access arrangements rather than assume that a separate backup application automatically provides complete identity isolation.
Repeatable recovery with Recovery Plans
Recovering a complex environment should not depend entirely on manual actions and individual knowledge.
Organizations need documented procedures that can be repeated, reviewed and tested. These procedures should identify the systems to restore, their dependencies, the target environment and the people responsible for each stage.
Storware’s Recovery Plans allow multiple restore operations to be executed using preconfigured settings. Plans can be run on demand or scheduled, making them useful for repeatable recovery activities and regular testing of systems included in an MVC.
The business recovery sequence itself should be defined and validated by the organization. For example, identity and network services may need to be available before databases and business applications can operate reliably.
Regular testing helps identify whether the chosen recovery procedures, available resources and infrastructure can support the organization’s objectives.
Tiered recovery targets instead of “everything in two hours”
Trying to restore every system within the same short timeframe is often unrealistic and expensive.
An MVC approach prioritizes resources according to their importance to business continuity. Critical services receive more aggressive recovery objectives, while supporting systems can be restored later.
An illustrative model could look like this:
| Tier | Example systems | Illustrative recovery targets |
|---|---|---|
| Tier 0: MVC core | Identity, DNS, network, payment and order processing | RTO under 6 hours, RPO under 1 hour |
| Tier 1: Business-critical | ERP reporting, CRM and internal collaboration | RTO 1–3 days |
| Tier 2: Supporting | Archives, test environments, intranet and chatbot | RTO several days to two weeks |
These figures are examples, not universal recommendations or Storware service guarantees. Each organization should derive its recovery objectives from a business impact analysis, workload requirements, available infrastructure and realistic recovery tests.
For a deeper explanation, see our guide to Disaster Recovery and RPO/RTO planning.
From “zero downtime” to protecting what matters
The Minimum Viable Company approach replaces the unrealistic expectation of restoring every system immediately with a more practical objective: restoring the capabilities that matter most to the business.
A company’s survival after a major incident does not depend solely on how quickly it can recover every server. It depends on how effectively it can bring essential services back online, serve customers and meet its most important obligations.
The MVC concept also creates a common language for business leaders, IT teams and recovery specialists. Everyone can work from an agreed set of priorities rather than trying to decide what matters most in the middle of a crisis.
Ultimately, the question is not simply whether an organization has backups. It is whether it knows what to recover first, has the resources to do it and has tested the process before an incident occurs.
Frequently asked questions
What is a Minimum Viable Company?
A Minimum Viable Company is the smallest operational version of an organization that can continue delivering essential services after a major incident. It includes the business processes, people, technology, data, facilities, suppliers and decision-making capabilities required to keep critical operations running.
How is an MVC different from a traditional disaster recovery plan?
A traditional disaster recovery plan often focuses on restoring infrastructure and systems after a physical failure or outage. An MVC approach prioritizes the business services that must remain operational after a major disruption, including a destructive cyberattack. It identifies the minimum set of dependencies and capabilities required to restart those services.
How do you define the scope of your MVC?
Start with a business impact analysis. Identify revenue-generating processes, essential customer services and critical obligations. Then map the applications, infrastructure, datasets, suppliers and people on which those processes depend. The resulting priorities should be agreed by business leadership before an incident occurs.
What RTO and RPO should MVC systems have?
There is no universal answer. The most critical MVC systems should generally have more aggressive recovery objectives than supporting systems. An organization might use an RTO under six hours and an RPO under one hour for selected critical services, but these targets must be based on business requirements and validated against actual recovery capabilities.
How do DORA and NIS2 relate to operational resilience?
DORA establishes digital operational resilience requirements for financial entities, including ICT risk management, business continuity, backup and recovery arrangements. NIS2 requires relevant essential and important entities to implement risk-management measures that include business continuity, backup management, disaster recovery and crisis management. An MVC approach can help organizations structure and test their recovery priorities, but it does not by itself establish regulatory compliance.
How often should an MVC recovery be tested?
Recovery testing should be performed regularly and after significant changes to infrastructure, applications or business dependencies. The frequency and scope should reflect business criticality and applicable requirements. Tests should produce documented results, identify gaps and lead to updates in recovery procedures.
Ready to test what your business can actually recover?
A backup strategy should be measured not only by the number of copies it creates, but by whether those copies can help restore the services the business depends on.
Storware Backup and Recovery supports disaster recovery across a range of virtualization and private cloud environments, with immutable backup configurations, isoLayer isolation and Recovery Plans for repeatable restore operations.
Explore Storware Backup and Recovery and see how it can support your recovery strategy across multi-vendor infrastructure.
