You're wrapping up a call with your primary regulator on a Tuesday morning and your Chief of Staff walks in with a note. "Every screen in the company is frozen behind a ransom note." Your technology leaders are on a bridge call that stopped being useful twenty minutes ago. And the continuity plan you approved last year — the one with the tabs, the RACI chart, the recovery-time objectives — is answering a question no one in the building is asking. It tells you how to bring everything back. It says nothing about what to do until then.
That gap is where organizations fail.
Most continuity planning starts from the wrong question: how do we recover everything? It produces a plan too big to run under fire, because on the worst day you will not have the people, the hours, or the clarity to execute all of it at once. The right question is smaller and much harder: what is the least this organization can be and still be this organization — and can we prove we can hold it while we fight to restore the rest?
That irreducible core has a name. It is your Minimum Viable Organization — the smallest set of critical services, with the people and infrastructure that keep them running, that lets you survive a severe outage without losing your customers, your standing, or your license to operate. The running heart of it — the services actually kept alive on the worst day — is your minimum viable operation. Naming the organization is the first act of resilience. Everything else is downstream from there.
I want to make one argument here: resilience is a design choice you make — before the crisis — by naming your Minimum Viable Organization — and it is a choice that cannot be delegated. Three things follow.
You cannot protect what you have not named
Most firms have a disaster recovery plan. Very few have a purpose-defined MVO. They are not the same thing, and mistaking one for the other is the most expensive error in resilience space.
A disaster recovery plan is an inventory of systems and how to restore them. An MVO is a statement of which business services must keep running for the enterprise to remain viable — expressed as services your customers receive, not applications your technologists restart. That distinction is the whole game. Applications are a poor proxy for services. Restoring one application implies restoring the applications it depends on, and the platforms beneath those, and the data behind those — a chain that can run for days while the service your customer actually needs sits dark the entire time.
Name the service first. Then work down to what it truly requires to run. Most organizations have never done this exercise, which means that on the worst day they are defining their minimum viable operation for the first time — in the dark, at 3 a.m., with regulators circling and the press already writing the story.
You do not want to be discovering your priorities during the incident. And yet that is exactly the plan most companies have: a very expensive plan to figure it out later.
Criticality is not size
Here is the trap that catches nearly everyone. I've watched a few hundred capable executives walk straight into it.
When the U.S. financial sector set out to define what a bank must protect to survive a destructive cyberattack, almost every banker in the room started in the same place: loans. It's a reasonable instinct. Loans are a large share of a bank's assets and income. Surely they are critical.
They are not — not for this purpose. No customer panics because they can't make a loan payment today. Every customer panics if they can't see their balance or reach their money. The thing we were protecting was public confidence, and confidence has almost nothing to do with the size of the asset and everything to do with what a frightened person needs to see in the first hours. The sector started with more than thirty banking services, narrowed to ten, then to four, and finally agreed on two: give customers access to their balance information, and give them access to their funds. Everything else could wait a few days. Those two could not wait at all.
That is the entire discipline in one example. Criticality is a function of consequence and speed — what breaks, how fast the harm becomes intolerable, and whether anyone can route around it — not of revenue, headcount, or how much attention the function usually commands. Your most visible function is often not your most critical one. A market can close for a day and the world keeps turning. A payment rail cannot stop for an hour. Get that ranking wrong and you will pour your resilience budget into the function that photographs well while the one that actually keeps you alive goes unguarded.
This is not a banking story. Ask a hospital what its minimum viable operation is and the reflex answer is "all of it" — until you point out that the assumption underneath every downtime plan, that staff can revert to paper, quietly expired a decade ago. The manual muscle has atrophied; when the record system goes dark, care degrades to unsafe, not merely slow. Ask a telecom carrier and the honest answer is a service that is a rounding error in traffic volume — completing a call to emergency services — sitting above billions of best-effort packets that could all wait. Every sector has a core that looks small and matters most. The work is having the discipline to find it before the crisis does.
It cannot be delegated to a department
Once you have named the MVO, resilience stops being an insurance policy you buy and becomes a property you design into your operations. Each service in your minimum viable operation carries an impact tolerance — the maximum time and volume of disruption you can absorb before the harm is irreversible — and that tolerance becomes an architecture requirement, a staffing requirement, a rehearsal requirement — by Design, not bolted on.
And here is what organizations get wrong even after they've done the hard work of definition: they hand the whole thing to a new office. A Chief Resilience Officer, a program, a framework, a certificate on the wall. This is the disease wearing the costume of the cure. The moment resilience becomes someone else's department, the line leaders who actually run the critical services stop asking hard questions about their own decisions. Accountability isn't created by the new box on the org chart. It's relocated — away from the people who hold it.
Which is why a certification is a floor and never a finish line. Every major enterprise crippled by ransomware in the last five years held at least one industry-recognized security certification. The paperwork was in order. The capability was not. You are far better off building a real minimum viable organization and being resilient — and then showing your regulators how you did it — than clearing every examination without being able to survive a Tuesday.
The teller
Because in the end this is not an abstraction about systems. Picture the branch teller on the morning of the outage. There is a customer in front of her. The customer wants to know where their money is. Every screen she has is dark. What she says in that moment — whether she has an answer, whether the organization handed her one in advance — is your resilience, made human.
The board defines the MVO. The teller lives it. If the people at the top haven't done the work, the people at the counter pay for it, and so does everyone watching them on the news that night.
The work
So the job is not to buy a tool or stand up a team. It is to sit your leadership down, before the crisis, and answer the smallest hard question there is: what must survive, and can we prove we can keep it alive? Name your Minimum Viable Organization. Attach a tolerance to each service inside it. Rehearse it until the teller has her answer without having to think. That is resilience - by Design — and it belongs to you, not to a department you can point at when it fails.
That is the work we do: understand what your Minimum Viable Organization is, and help you deliver it.