Which Parts of Your Business Actually Need to Survive a Disaster?

Imagine your primary systems go down at 9 AM on a Tuesday. Your IT team tells you recovery will take somewhere between 4 and 12 hours — but they can only bring systems back one at a time, and they need you to tell them which ones matter most. Right now. Which do you choose?

If you've never thought about this question before a crisis, you'll improvise under pressure, and you'll almost certainly make the wrong choices. If you've thought about it in advance, using a framework designed for exactly this decision, you'll have a clear answer in seconds and an operational team that already knows the playbook.

This is what the Minimum Viable Business (MVB) framework is for. Borrowed from the startup world's concept of the Minimum Viable Product, MVB is the stripped-down version of your organization that must survive a disruption — the essential processes, people, data, and tools needed to serve your most critical customers and meet your most binding obligations. This post is a practical guide to building your own MVB, aimed specifically at business unit leaders who own the decisions that IT cannot make for them.

The myth of "restore everything"

Most disaster recovery plans are written as if the goal is to bring the entire organization back online simultaneously. In reality, no real recovery works that way. Recovery is always sequenced — some things come back first, others wait — and the sequence reflects priorities, whether or not anyone ever wrote those priorities down.

When priorities are documented, recovery is fast and aligned with business value. When priorities are not documented, the sequence defaults to whatever IT finds technically convenient: the easiest systems first, the loudest complainers first, or (most commonly) the systems that generate the most support tickets first. None of these are correlated with what actually matters to the business.

Consider the analogy of evacuating a building during a fire. You don't take your entire bookshelf, your full wardrobe, and every appliance. You grab your passport, your medication, your phone, and your wallet — the minimum set that lets you survive and rebuild. A Minimum Viable Business is the same concept applied to organizational operations: the smallest set of essentials that allows you to keep serving your most critical customers and meeting your most binding commitments while everything else waits.

The core question: if you had to run your business unit at 20% of capacity for 72 hours, which 20% would you keep? This is not a hypothetical exercise. It is the exact decision that gets forced on you during every real disaster, and the leaders who have answered it in advance are the only ones who handle the crisis well.

What MVB is, and what it isn't

A Minimum Viable Business is the smallest set of business processes, people, data, and tools that allows an organization to continue serving its most critical customers and meeting its most binding obligations during a disruption. It is not a technical architecture, a backup strategy, or an IT artifact. It is a business priority decision owned by business unit leaders and handed to IT as input.

Two distinctions matter. First, MVB is different from disaster recovery. DR is about restoring systems. MVB is about sustaining business functions. A recovered system that nobody knows how to use isn't continuity. A manual workaround that keeps customers served isn't DR but it is absolutely MVB. The two disciplines overlap but have different owners: DR belongs to IT, MVB belongs to business leaders.

Second, MVB is different from a business continuity plan. A BCP is the documented strategy — the whole plan, often hundreds of pages. MVB is a specific section within that plan: the prioritization layer that determines which parts of the business get restored first and which can safely wait. The BCP answers "what do we do?" MVB answers "what matters most?"

The MVB Canvas

The framework for identifying your Minimum Viable Business is a simple canvas with four quadrants. You work through each quadrant as a team, typically in a 90-minute session with your direct reports, and the output becomes the priority document you hand to IT when the next disaster hits.

Quadrant 1: Critical Customers

Not every customer is equal. Some customers generate most of your revenue. Some have contractual commitments with hard SLAs and penalty clauses. Some are flagship references whose defection would damage new business for years. Some are in the middle of critical escalations that cannot pause. These are your critical customers, and any MVB plan starts with identifying them.

Ask: which customer accounts, if left unserved for 72 hours, would create unrecoverable business damage? Not "customers who would be annoyed" — customers who would churn, sue, or publicly complain in ways you cannot undo. For most B2B organizations this is a small number: the top 10 to 50 accounts by revenue, plus any accounts currently in active escalation or contract renegotiation. For consumer businesses it's typically the segments with the highest lifetime value or the most binding regulatory obligations (for example, users who depend on your service for healthcare, financial access, or safety).

Quadrant 2: Critical Processes

For each critical customer, what processes must remain operational to keep serving them? This is where business leaders often discover that their critical-customer list and their critical-process list don't match. You might have identified the top 20 enterprise accounts as critical, but the processes that actually serve those accounts turn out to include the CRM, the billing system, the product delivery pipeline, the customer support platform, and the executive escalation communication channel. Five processes, each of which depends on different systems and people.

List the processes, not the tools. "Send renewal notices to Tier 1 accounts" is a process. "Salesforce" is a tool that supports several processes. The process-level list is what matters because the same tool might support both critical and non-critical processes, and you only need to protect it during a crisis if one of its processes is critical.

Quadrant 3: Critical Data

What information absolutely must be accessible to keep the critical processes running? This is usually a surprisingly short list: a customer contact database, current contract terms, outstanding obligations, in-flight orders or cases, and the minimum financial information needed for day-to-day decisions. Everything else — historical reports, analytics dashboards, archived communications — can wait days or weeks without material harm.

The exercise of identifying critical data often reveals unexpected dependencies. A customer success team might discover that their critical data isn't in the CRM — it's in a shared spreadsheet that tracks custom escalation details outside the official system. A finance team might discover that their critical data includes an Excel model that only one person knows how to update. These hidden dependencies are exactly what MVB planning is designed to surface.

Quadrant 4: Critical People

Who must be available and empowered to act during a crisis? This is often the most overlooked quadrant, and the most important. A recovered system is useless if the only person who knows how to operate it is unreachable. A documented escalation path is useless if the named contacts have left the company.

For each critical process, identify the two or three people who can run it manually, know the workarounds, have the authority to make decisions, and are reachable outside normal business hours. Then check: are those people documented in the continuity plan? Do they know they're on the list? Is there a backup if someone is on leave or unreachable? The answer is often "no" to all three, and fixing it costs nothing except a conversation.

The three-tier classification

Once the canvas is filled out, classify every process in your function into one of three tiers. This is the translation layer between the canvas (a business artifact) and your IT team's recovery architecture (a technical artifact).

Tier 1: Critical. Must be operational within hours. Failure creates immediate revenue loss, contractual breach, regulatory violation, or safety risk. Examples: payment processing during business hours, customer-facing service delivery, regulatory reporting during compliance windows, active customer escalations. These processes map to the Tier 0 or Tier 1 workloads in a technical architecture and justify the investment in active-active or warm standby recovery designs.

Tier 2: Important. Should be operational within one to three days. Failure creates significant inconvenience and mounting costs but no immediate existential risk. Examples: internal reporting, non-urgent customer communications, most HR processes, routine financial operations outside of close periods. These processes can tolerate longer recovery windows and are typically served by hub-and-spoke DR with immutable backups.

Tier 3: Deferrable. Can wait three to seven days or longer. Failure is annoying but manageable with workarounds. Examples: marketing analytics, training programs, internal knowledge base updates, most planning and forecasting activities. These processes need basic backup but don't need sophisticated DR architecture.

The discipline is in being honest. Most business leaders want to put everything in Tier 1 because the consequences of being wrong feel asymmetric: if you under-classify, you risk the business during a crisis, but if you over-classify, the cost is invisible (you just pay for more protection than you need). This asymmetry creates inflated Tier 1 lists that exhaust the organization's resilience budget, leaving nothing for the processes that actually need protection. If everything is critical, nothing is. The exercise only works if you're willing to place real things in Tier 2 and Tier 3, even when it feels uncomfortable.

MVB across different business functions

To make this concrete, consider how different business functions apply the framework.

Finance typically finds that payroll processing, accounts payable for critical vendors, and regulatory filings cannot pause. These are Tier 1. Management reporting, forecasting, analytical work, and internal budget reviews are Tier 2 or Tier 3 — they're important, but the business can live without them for days or weeks. A CFO who runs this exercise often discovers that 80% of the finance team's work falls into Tier 2 or Tier 3, which is a liberating realization because it means the Tier 1 list is short enough to protect properly.

Customer Success typically identifies a small number of Tier 1 customers (accounts in active escalation, renewals within 30 days, strategic accounts with binding SLAs) and the small set of processes needed to serve them. Everything else — routine check-ins, satisfaction surveys, quarterly business reviews, internal analytics — is deferrable. A CS leader who has done this exercise can give IT a clear answer: "If systems are down, prioritize the ability to contact these 40 accounts and look up their contract terms. Everything else can wait three days."

Operations and Logistics typically find that active shipments in transit, inbound materials for production lines, and safety-critical systems cannot pause. Route optimization, capacity planning, procurement for future orders, and performance analytics can all wait. The Tier 1 list is usually small but extremely time-sensitive: a 4-hour outage of shipment tracking during peak dispatch hours might be more damaging than a 3-day outage of anything else the team does.

Product Management typically discovers that almost nothing they own is Tier 1. Their role is strategy, roadmap, coordination, and prioritization — all of which can pause for days without immediate business impact. The Tier 1 systems for product teams are usually monitoring dashboards for live customer-facing services, and those dashboards are typically owned by engineering rather than product. This is a useful realization: it means product managers can contribute to crisis response by supporting other functions rather than protecting their own work.

The 72-hour exercise

Once you've completed the canvas and classified your processes, test your MVB with a thought experiment. Block 60 minutes with your team and present the following scenario:

It's Monday at 9 AM. Every system your team uses is offline. IT tells you they can restore exactly three systems in the next 72 hours, and you have to choose which three. Which do you choose? What can you still accomplish with just those three? What happens to your Tier 1 customers during those 72 hours? Who needs to be contacted, and how?

The exercise almost always surfaces hidden assumptions. Team members realize they were assuming that "the CRM" includes the communication history they actually need, but it's stored in a separate tool. Someone realizes that the escalation process depends on a phone tree that hasn't been updated in a year. Someone else realizes that half the team doesn't know how to execute the manual workarounds that are supposedly documented somewhere.

Every surface-level "oh no" from the exercise is a specific, fixable gap. Document them and fix them, one at a time, over the following quarter. This is how MVB planning turns into real readiness.

The handoff to IT

After completing the canvas, the tiered classification, and the 72-hour exercise, you have something valuable that IT has probably been waiting for: a clear, business-priority list of what matters most.

The handoff conversation has a specific structure. For each Tier 1 process, give IT two pieces of information: the maximum tolerable downtime (your RTO, in business-impact terms) and the maximum tolerable data loss (your RPO, in the same terms). Reference the downtime economics framework if you need help quantifying those numbers.

Then ask IT: "Given these priorities, what does our current architecture protect and what doesn't it protect? Where are the gaps? What would it cost to close the gaps for the Tier 1 items?" This is the conversation that turns MVB from a document into a plan.

One warning: resist the temptation to let IT redefine your tiers. IT teams sometimes push back because protecting a process to Tier 1 standard requires real investment, and they may prefer to move it down a tier for budget reasons. The right answer, usually, is not to change the classification but to have an honest conversation about whether the investment is justified. If the Tier 1 classification is correct, the investment should be justified. If it isn't, the classification probably needs to be revisited — but that's a business decision, not a technical one.

Common mistakes in MVB thinking

Four patterns of failure show up repeatedly.

Making everything Tier 1. The most common failure. Remember: if everything is critical, nothing is. The purpose of the exercise is to rank, not to protect. A Tier 1 list with more than 30% of your processes in it is almost certainly wrong.

Defining MVB once and never updating it. Business priorities change quarterly. A customer that was Tier 1 last quarter might have churned. A new product launch might introduce new Tier 1 processes that didn't exist before. Review the canvas every quarter, the same cadence as your business reviews.

Leaving IT to guess which processes matter. The most costly failure mode. Every minute you spend filling out the canvas is a minute you save during an actual crisis when IT would otherwise be guessing under pressure.

Ignoring the people dimension. A Tier 1 process with only one person who knows how to run it has a hidden single point of failure. A Tier 1 process with a documented escalation path whose contacts have left the company has the same problem. The people quadrant is not optional.

The bigger picture

Minimum Viable Business planning is the exercise that forces honest conversation about what matters. It's uncomfortable because it requires explicit choices — which customers matter most, which processes can pause, which people are indispensable — and those choices can feel politically charged. But the alternative is making those same choices under crisis pressure, with incomplete information, at the moment when mistakes are most expensive.

The organizations that recover quickly from disruption are not the ones with the biggest DR budgets or the fanciest architectures. They are the ones where business leaders have done this exercise, where IT knows exactly what to prioritize, where the critical people are identified and reachable, and where the team has rehearsed the 72-hour scenario so many times that it feels routine.

If your organization hasn't done this exercise, you have a specific, concrete homework assignment: block 90 minutes, bring your direct reports, fill out the four quadrants, classify your processes into three tiers, and hand the result to IT. Dataring's BCDR consulting practice runs these sessions with business leaders across the GCC and can facilitate yours if you want outside help. Get in touch to schedule a working session for your team.