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

In the BCDR exercises I've sat through, one moment recurs: the scenario reaches the point where IT says recovery will take 4–12 hours, with systems coming back one at a time, and asks the business leader which to prioritize. The leaders who have thought about this question in advance produce an answer in seconds. The leaders who haven't usually improvise, and they almost always make choices they regret in the post-mortem.

This post is about the framework that produces the prepared answer. I call it Minimum Viable Business (MVB), borrowing from the startup concept of a Minimum Viable Product. MVB is the stripped-down version of an organization that must survive a disruption — the essential processes, people, data, and customer commitments needed to keep going while everything else waits.

For the broader BCDR architecture context, see our cloud DR in the GCC pillar. For the related downtime-economics framework, see our RTO and RPO post.

The thesis

Recovery is always sequenced. Either you've decided the sequence in advance, with input from the people who actually understand the business, or the sequence gets decided under pressure during the crisis by whoever happens to be in the room. The latter usually defaults to whatever IT finds technically convenient — the easiest systems first, the loudest internal complainers first, or the systems generating the most support tickets first. None of these correlate with what actually matters to the business. The work of MVB is the work of making the priority decision before it has to be made under pressure.

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 practice, no real recovery works that way. There is always a sequence, and the sequence reflects priorities whether or not anyone has written them down.

The useful analogy is evacuating a building. You don't take your bookshelf and your wardrobe. You take your passport, your medication, your phone, and your wallet — the minimum set that lets you survive and rebuild. MVB is the same idea applied to the organization: the smallest set that lets the business keep serving its most critical customers and meeting its most binding obligations while everything else waits.

The core question, plainly: if you had to run your business unit at 20% of capacity for 72 hours, which 20% would you keep? This is the exact decision that gets forced on you in every real disaster. Leaders who have answered it in advance handle the crisis well. Leaders who haven't, don't.

What MVB is, and what it isn't

A Minimum Viable Business is the smallest set of 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. It is not a backup strategy. It is not an IT artifact. It is a business priority decision owned by business leaders and handed to IT as input.

Two distinctions matter.

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 operate is not continuity. A manual workaround that keeps customers served isn't DR but is absolutely MVB. The two disciplines overlap and have different owners: DR belongs to IT; MVB belongs to business leaders.

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 wait. The BCP answers "what do we do?" MVB answers "what matters most?"

The MVB Canvas

The framework I use is a four-quadrant canvas. Work through it as a team, typically in a 90-minute session with direct reports. The output is the priority document you hand to IT when the next disaster hits.

Quadrant 1: Critical customers

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

Ask: which accounts, if left unserved for 72 hours, would create unrecoverable damage? Not customers who would be annoyed; customers who would churn, sue, or publicly complain in ways you can't undo. For most B2B businesses this is a small number — the top 10 to 50 accounts by revenue, plus any in active escalation or renegotiation. For consumer businesses, it's typically the highest-LTV segments or those with binding regulatory obligations (healthcare, financial access, safety).

Quadrant 2: Critical processes

For each critical customer, what processes must remain operational to keep serving them? This is where leaders often discover that the critical-customer list and the critical-process list don't match. You may have identified the top 20 enterprise accounts as critical, but the processes that actually serve them turn out to include the CRM, the billing system, the product delivery pipeline, the customer support platform, and the executive escalation channel — each depending 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 may support both critical and non-critical processes; you only need to protect it during a crisis if one of its processes is critical.

Quadrant 3: Critical data

What information must be accessible to keep the critical processes running? 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.

In my experience, the critical-data exercise often surfaces 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 the most overlooked quadrant and often 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 business hours. Then check: are those people documented in the continuity plan? Do they know they're on the list? Is there a named backup if someone is on leave or unreachable? In most assessments I've done, the answer is "no" to all three for most processes — and fixing it costs nothing except a series of conversations.

The three-tier classification

Once the canvas is filled in, 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). For the architecture pattern that follows from each tier, see our pattern decision guide.

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 escalations.

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.

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 updates, most planning and forecasting activity.

The discipline is honesty. Most leaders want to put everything in Tier 1 because the consequences of being wrong feel asymmetric: under-classifying risks the business during a crisis, while over-classifying just costs more in protection. This asymmetry produces inflated Tier 1 lists that exhaust the resilience budget, leaving nothing for the processes that genuinely need it. If everything is critical, nothing is. The exercise only works if you're willing to put real things in Tier 2 and Tier 3, even when it feels uncomfortable.

MVB across different functions

A few examples to make this concrete.

Finance. Payroll processing, accounts payable for critical vendors, and regulatory filings rarely pause without consequence — these are Tier 1. Management reporting, forecasting, analytical work, and internal budget reviews are usually Tier 2 or Tier 3. CFOs who run this exercise often find that the majority of finance work falls into Tier 2 or Tier 3, which is liberating because it means the Tier 1 list is short enough to protect properly.

Customer success. A small number of Tier 1 customers (active escalations, 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, QBRs, internal analytics — is deferrable. A CS leader who has done this exercise can give IT a specific instruction: "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. Active shipments in transit, inbound materials for production lines, and safety-critical systems can't pause. Route optimization, capacity planning, procurement for future orders, and performance analytics can. The Tier 1 list is usually small but extremely time-sensitive: a 4-hour outage of shipment tracking during peak dispatch is more damaging than a 3-day outage of anything else.

Product management. Often, almost nothing product owns is Tier 1. The role is strategy, roadmap, coordination, prioritization — all of which can pause for days without immediate business impact. The Tier 1 systems for product teams are typically monitoring dashboards for live customer-facing services, and those usually belong to engineering. This is a useful realization: it means product managers can support other functions during a crisis rather than protecting their own work.

A 60-minute scenario test

Once the canvas is done and processes are classified, test the result with a thought experiment. Block sixty minutes with the team and present the 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? What can you 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 the CRM included communication history that's actually in a separate tool. Someone realizes the escalation process depends on a phone tree last updated a year ago. Someone else realizes half the team doesn't know how to execute the manual workarounds that are supposedly documented somewhere.

Every "oh no" from this exercise is a specific, fixable gap. Document them and fix them, one at a time, over the following quarter. That's how MVB planning turns into real readiness.

The handoff to IT

After the canvas, the tiered classification, and the scenario test, you have what IT has been waiting for: a clear, business-priority list.

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

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: don't let IT redefine your tiers. IT teams sometimes push back because protecting a process at Tier 1 standard requires real investment, and they may prefer to move it down for budget reasons. The right answer is usually not to reclassify, 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 revisiting — but that's a business decision, not a technical one.

Common mistakes I see

Making everything Tier 1. The most common failure. 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 Tier 1 processes that didn't exist before. Review the canvas every quarter on the same cadence as your business reviews.

Leaving IT to guess. The most costly failure mode. Every minute spent filling out the canvas is a minute saved during an actual crisis when IT would otherwise be guessing under pressure.

Ignoring the people quadrant. 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 whose escalation contacts have left the company has the same problem. The people dimension is not optional.

Tradeoffs and honest limitations

The exercise produces priorities, not architecture. The canvas tells IT what to prioritize. It doesn't tell IT how to build it. Without the architecture-pattern conversation that follows, the canvas is shelfware.

Tiering is iterative. The first time you run this, you'll mis-classify some processes. That's expected. Re-classify after the first real incident or test — those events surface processes whose business value was misunderstood.

The canvas can become political. Identifying critical customers means naming non-critical ones. Identifying critical people means naming non-critical roles. Be ready for the conversation; the discomfort is the point. Done well, the artifact stays inside the leadership team and isn't published broadly.

A practical takeaway

If your function has not done this exercise, the homework is concrete: block ninety minutes, bring your direct reports, fill out the four quadrants, classify your processes into three tiers, and hand the result to IT. The first version will be imperfect. It will still be more useful than no version, which is what most organizations have.

For the downtime-economics framework that complements MVB, see our RTO and RPO post. For the architecture patterns that follow from MVB tiering, see our pattern decision guide. For the broader regional context, see our cloud DR in the GCC pillar. If you'd like outside facilitation for the canvas session, Dataring's resilience practice runs these regularly. Get in touch.