No Minimum Viable Company, No Cyber Recovery Strategy

It's Friday, 06:00. Your COO can't log in. Neither can anyone else. By 09:00, customers are calling a help desk that doesn't answer, shipments aren't moving, invoices aren't going out, and a journalist has left a voicemail. The board chair wants a call by midday.

Now answer this: Which five business processes do you save first?

If your CEO needs more than a minute, or hands the question to IT, you don't have a cyber recovery strategy. You have a backup policy with ambition.

This is the test for whether a Minimum Viable Company (MVC) has been defined. Without one, every cyber recovery plan I have seen collapses in the first 48 hours of a real incident.

The economics don't favour improvisation

The cost of skipping this work is no longer theoretical. Recent industry data is brutal on the point:

• The average ransomware victim loses 24 days of operations, according to Sophos's State of Ransomware 2025. For a mid-market business, that is nearly a month of customers calling a help desk that doesn't answer, orders that don't ship, and revenue that never books.
• The average recovery cost, excluding any ransom paid, is around €1.4 million ($1.53M as reported by Sophos's State of Ransomware 2025). IBM's broader Cost of a Data Breach 2025 puts the average ransomware or extortion incident at around €4.7 million ($5.08M) once legal, regulatory, and customer-loss costs are included.
• Gartner estimates the total cost of recovery runs roughly 10x the ransom demand itself (Gartner IT Resilience Survey, 2026). The payment to the attacker is rarely the biggest number on the bill.
• Median ransomware dwell time is now 6 days (Mandiant M-Trends 2025). By the time the encryption hits, your backups have almost certainly already been touched.

Twenty-four days is not a technology problem. It is a decision-making problem. You cannot decide what to restore first if nobody ever decided what mattered most.

The default is "restore everything." That is the problem.

When ransomware hits, the natural instinct is to bring everything back. ERP, email, file shares, the warehouse system, the analytics stack, the marketing tools. All of it. Immediately.

That instinct kills recovery timelines for three reasons:

• Restoring everything in parallel overwhelms the recovery team and the infrastructure they have left.
• Restoring without sequencing means systems come back depending on other systems that aren't ready yet. You will do the work twice.
• Restoring without validation means you bring the attacker back with you. Every system you bring online is a question: is this one clean, or is it the foothold the attacker left behind?

Recovery from a cyber attack is not recovery from a power outage. The adversary is still in the building. Every backup you trust could be the door they walk back through.

MVC is a board-level call that happens to drive technical priorities

The Minimum Viable Company is the smallest, functioning version of your organisation. The version that can still:

• Meet regulatory and contractual obligations
• Generate enough revenue to survive the incident
• Keep people and assets safe
• Maintain the bare minimum of customer trust
  Everything else can wait. That sentence is the whole point, and it is what makes MVC hard.

Defining an MVC forces leadership to say, out loud and in writing, which parts of the business will deliberately stay broken while critical functions come back online. The CIO's job is to translate that into a recovery sequence. The CEO's job is to make the trade-off in the first place.

Most organisations skip this conversation because it is uncomfortable. Every function head believes their work is essential. Without a pre-agreed MVC, the loudest stakeholder wins the recovery queue, and the rest of the business waits in chaos.

What "five processes" actually looks like

Abstract test, concrete answer. For a mid-market industrial manufacturer, a defensible MVC top five might be:

1. Order intake (the front door for revenue)
2. Production scheduling and shop-floor execution (without it, machines sit idle)
3. Outbound logistics and shipping (finished goods turn into cash only after they leave the dock)
4. Payroll and time tracking (legally required, and the fastest way to lose staff)
5. Customer support and incident communications (because silence multiplies the damage)

Notice what is not on that list: HR reporting, marketing automation, the BI stack, the corporate intranet, ... Important, but not survival-critical for the first two weeks. They go in tiers 2, 3, and 4.

A bank, hospital, or SaaS provider would obviously have a different top five. The discipline is having one at all — written down, agreed in advance, and short enough that your CEO, can recite it from memory.

What a working MVC document defines

A working MVC document is short. Four things:

1. The critical services that must remain available to meet regulatory, contractual, and safety obligations.
2. The data and systems those services depend on, mapped explicitly.
3. Which systems must be proven clean before you trust the next layer to come back online.
4. The recovery sequence, prioritised by business impact, not by who shouts loudest at 03:00.

No tooling required. No vendor needed. Just a few hard conversations, written down, agreed by the people who will be accountable when it goes wrong.

The hidden layer: Tier 0 supporting services

Before any Tier 1 process can be recovered, you need the Tier 0 foundation in place. These are not business processes — they are the recovery enablers most plans quietly omit. They surface during the MVC analysis phase, when you trace each critical process back to what it actually depends on. The literature from Gartner, NIST, IDC, PwC, CISA and ENISA points to the same four categories:

1. Identity & Access Management
The first thing the recovery team needs is to authenticate themselves. That requires a recoverable identity provider (Active Directory, Entra ID), Privileged Access Management with break-glass and just-in-time accounts, and recovery-team credentials that do not depend on the compromised production environment.

2. Clean Recovery Infrastructure
A validated, isolated place to recover into. Gartner calls this an Isolated Recovery Environment (IRE) or Secure IRE, paired with an Immutable Data Vault holding known-good backups. Add validated golden images for OS and platform services, and network segmentation to keep the recovery zone uncontaminated.

3. Recovery Validation & Detection
Continuous pre-scanning of backups for malware, encryption signatures, and anomalies. SOC monitoring inside the recovery environment so the attacker doesn't follow you in. Forensic and threat-hunting capability before workloads are promoted back to production. Documented "clean state" criteria so the team knows when a workload is safe to release. This is the most-skipped category, and the one that turns a 5-day recovery into a 38-day one.

4. Recovery Workspace & Communications
Pre-staged laptops and workstations for the recovery team, ideally kept offline. An out-of-band collaboration platform for email, chat, and video. Both NIS2 (24-hour incident notification to the authorities) and DORA Article 11 (a crisis management function with internal and external communications during ICT disruption) require these channels to remain functional during an incident, which they cannot if email, chat, and video run on the same network the attacker has just compromised. Out-of-band documentation (playbooks, contact lists, network diagrams) accessible without production. Out-of-band logging for evidence preservation.

Tier 0 is rarely owned by a single function. IAM sits with security, infrastructure sits with platform, endpoints sit with end-user computing, comms sit with collaboration. The MVC analysis is where these threads come together, or where you discover, too late, that nobody has thought about them at all.

A note on what is not in Tier 0: incident command authority, escalation matrices, insurance carrier notification timelines, board-level decision rights. These are critical, and the absence of any one of them can sink a recovery. They belong to the governance layer of an incident response plan, not the technical supporting-services layer. They warrant a separate article all together.

The essence, in one view

The shift in mindset:

• Traditional disaster recovery assumes clean infrastructure and trusted backups. A cyber adversary breaks both, deliberately.
• MVC starts from the business outcome, not the asset inventory.
• The trade-offs happen before the incident, not during it.
• Sequencing matters more than raw speed. Restoring the wrong thing first costs days.
• DORA (financial services) and NIS2 (essential and important entities) are turning MVC from best practice into documented evidence regulators expect to see (ISACA, 2025).

The table below contrasts the two recovery mindsets at a conceptual level. The diagram that follows shows how those mindsets translate into a prioritised recovery stack.

Traditional DR vs. MVC-based cyber recovery:

MVC recovery stack, visualised:

Conclusion

A cyber recovery strategy is not a runbook. It is a decision. The decision is what stays running when most of the business cannot.

If leadership hasn't already made and documented that decision, every minute of the real incident is wasted arguing priorities while the clock runs against you.

'The CEO test' is the simplest way to check. Five processes. By name. Without hesitation. If the answer isn't there, the work hasn't been done.

What's next

A cyber recovery strategy without an MVC is a wishlist with backup tapes.

But look at the diagram again. The Tier 0 layer at the base is where most recovery plans quietly fail. Identity, clean infrastructure, validation and detection, recovery workspace and out-of-band comms — these are the services that turn an MVC document into an actual recovery effort. They are not glamorous. They are the difference between a 5-day recovery and a 38-day one.

In the next post, I'll go deeper into the first of those four categories: why identity and access management is the single supporting service that, when it goes, takes everything else with it — and why nine out of ten ransomware incidents start there for a reason.

Sources

• Sophos, The State of Ransomware 2025
• IBM, Cost of a Data Breach Report 2025
• Gartner, IT Resilience Survey for 2026: Ransomware Recovery and Readiness
• Gartner, Innovation Insight for Leveraging Isolated Recovery Environments and Immutable Data Vaults
• Mandiant (Google Cloud), M-Trends 2025
• NIST, SP 800-184: Guide for Cybersecurity Event Recovery
• IDC, MarketScape: Worldwide Cyber-Recovery 2025 Vendor Assessment
• PwC, Ransomware Readiness and Recovery (UK)
• CISA, #StopRansomware Guide
• ENISA, NIS2 Technical Implementation Guidance
• European Union, DORA Regulation (EU) 2022/2554 — Article 11: Response and Recovery
• ISACA, Resilience and Security in Critical Sectors: Navigating NIS2 and DORA Requirements (2025)