What Is a Minimum Viable Company — And Why Every CTO Needs to Define Theirs Before the Next Outage

The MVC framework, popularized by PwC's Global Centre for Crisis and Resilience, gives organizations a way to stop improvising and start planning — by ruthlessly prioritizing what matters most when everything else is on fire. The idea is deceptively simple: if a major disruption hit your organization tomorrow — a ransomware attack, a cloud provider outage, a critical vendor failure — which services, processes, and systems absolutely must keep running for the business to survive?

Not thrive. Not operate normally. Survive.

Defining your Minimum Viable Company means identifying the essential services, processes, and functions that must remain operational to keep the organisation financially, operationally, and strategically viable in a crisis.

As PwC UK put it in their recent paper on the subject, that framing should make every technical leader uncomfortable — because most organizations cannot answer the question today.

Why the MVC Conversation Is Happening Now

The timing isn't accidental. Several forces are converging that make the Minimum Viable Company concept urgently relevant.

Cyber attacks on UK businesses have increased for the third consecutive year. The UK government has written directly to FTSE350 board chairs asking them to make cyber resilience a top priority. And the Uptime Institute's 2024 Global Data Center Survey found that 53% of operators experienced an outage in the past three years, with 54% of significant outages costing more than $100,000.

Meanwhile, Cockroach Labs' State of Resilience 2025 report found that only 33% of organizations have an organized response approach to outages. Two-thirds are essentially improvising when disruption hits.

The MVC framework gives organizations a way to stop improvising and start planning — by ruthlessly prioritizing what matters most when everything else is on fire.

MVC vs. Operational Resilience: What's the Difference?

One of the most common questions executives ask is whether MVC is just another name for operational resilience. It isn't — but the two are deeply connected.

In a recent episode of PwC's Emerge Stronger Through Disruption podcast, Dave Stainback (PwC's Global Crisis & Resilience Co-Leader) put it clearly: the MVC answers the question of what is the smallest version of the company that must continue operating for the firm to survive and retain its strategic value.

Think of it as two layers within a resilience framework. The MVC is the survival core — the minimal set of capabilities, services, and infrastructure needed to keep the organization alive and viable. Operational resilience sits above that floor, encompassing the broader range of services that are still critical but not necessarily existential.

The key distinction is timeframe. An MVC is designed for a specific, relatively short crisis period. It's the emergency capability you activate when a major disruption strikes, not a permanent operating model. Operational resilience is the longer-term goal of being able to deliver all critical services in any scenario.

For organizations that haven't yet begun their operational resilience journey, defining the MVC is actually a strong starting point. It forces the most important conversations first: what must survive, and what are we willing to temporarily lose?

The Three Components of a Minimum Viable Company

Based on PwC's framework, an MVC typically has three layers.

Essential external-facing services. These are the customer-facing capabilities that generate revenue, maintain market position, and fulfill regulatory obligations. For a bank, that might be transaction processing and account access. For a healthcare provider, patient-facing systems and appointment scheduling. For a SaaS company, the core application and authentication.

Critical internal processes. These are the internal operations that support external services and maintain financial liquidity — payroll processing, regulatory reporting, internal communications, and key decision-making workflows.

Core infrastructure (Tier Zero). The foundational technology layer that everything else depends on: identity and access management, DNS, core networking, database systems, and cloud infrastructure. Without Tier Zero, nothing else functions.

The crucial insight is that these three layers are deeply interdependent. An external service depends on internal processes, which depend on infrastructure. A failure at the infrastructure layer cascades upward through everything above it.

The Dependency Problem: Where Most Organizations Get Stuck

This is where theory meets reality — and where most organizations struggle.

Every organisation relies on a complex web of technology, people, suppliers, data, and physical assets, and these interdependencies can either be a source of strength or a point of failure. Mapping these connections provides a holistic view of where your business is robust and where it's vulnerable.

In practice, very few organizations have actually done this mapping. Dependencies live in the heads of senior engineers, scattered across Confluence pages, architecture diagrams that were last updated eighteen months ago, and tribal knowledge that walks out the door when people leave.

When a disruption hits, the first question is always: "what else depends on this?" And the answer is usually a frantic series of Slack messages and war room conversations trying to reconstruct the dependency chain in real time.

This is exactly the problem we built Faultline to solve.

From Framework to Execution: How Faultline Operationalizes the MVC

The MVC concept is powerful as a strategic framework. But it requires tooling to move from a boardroom conversation to a living, testable operational capability. PwC outlines four phases — Define, Design, Deploy, and Run — and each one involves understanding dependencies, simulating failures, and validating recovery sequences.

Faultline maps directly to this workflow:

Define your MVC. Faultline's guided setup wizard lets you map your critical services and their dependencies in minutes. Start by selecting your industry — Healthcare, Financial Services, SaaS, Retail — and the platform provides pre-built templates with relevant critical activities. Each service gets a criticality rating (1–5), and the platform automatically identifies which services form your survival boundary based on their criticality and dependency chains.

Design your recovery. Once your services are mapped, the cascade simulator lets you answer the "what if" questions that PwC emphasizes. What happens if your cloud infrastructure goes down? Which services fail, in what order, and what's the revenue impact? Faultline's simulation engine propagates failures through your dependency graph using breadth-first search, respecting backup services and manual workarounds, and produces concrete results: number of services failed, estimated revenue impact in dollars, maximum recovery time, and whether your critical operations boundary remains intact.

Deploy and test. After running simulations, Faultline generates AI-powered recovery playbooks — step-by-step incident response plans organized into phases. These are editable, trackable, and printable. They're built from your actual dependency data and simulation results, not generic templates. This maps directly to PwC's emphasis on testing and exercising solutions before you need them.

Run and monitor. The platform provides a resilience score that updates as your service map changes, a board-ready report you can export in one click, and AI-powered suggestions for missing dependencies and backup gaps. PwC's podcast specifically mentions the importance of Key Resilience Indicators (KRIs) — Faultline provides these through its resilience scoring, SPOF detection, and backup coverage metrics.

Why Engineering Leaders Should Own This Conversation

There's a temptation to treat the MVC as a compliance or risk management exercise. PwC explicitly pushes back on this — and we agree.

Defining an MVC isn't just a technology or a risk exercise. It requires business and technology co-leadership, clear decision rights, and a collaborative approach to enable rapid recovery.

The UK government has similarly made clear that CEOs and business leaders — not just CISOs — must lead the resilience response within their organizations.

But the reality is that engineering leaders are the ones who understand the dependency graph. They know which services are single points of failure. They know which infrastructure is Tier Zero. They know where the manual workarounds exist and where they don't.

The MVC conversation needs business leadership to set priorities and make trade-offs. But it needs engineering leadership to provide the ground truth about what's actually connected to what, and what actually breaks when something goes down.

The Cost of Not Knowing

PwC's framing is direct: when the MVC isn't understood and agreed in advance, crisis response becomes fragmented and recovery slows, risking long-term viability. Organizations that plan, test, and embed their MVC respond faster, adapt better, and gain competitive advantage.

The data backs this up. EMA Research found that unplanned downtime averages $14,056 per minute. The Uptime Institute reports that 54% of significant outages cost organizations more than $100,000. And two-thirds of organizations lack an organized response approach when outages occur.

The Minimum Viable Company framework gives organizations a way to prepare. Faultline gives them a way to operationalize that preparation — mapping dependencies, simulating failures, quantifying impact, and generating recovery plans — before the next disruption forces them to figure it out in real time.

Getting Started

If you're an engineering leader or CTO reading this, here are three immediate steps:

The fault lines in your infrastructure are already there. The question is whether you find them before your next outage does.