It's the worst day. A destructive cyberattack has taken your bank's operating platforms down to the studs — and because whoever did this knew what they were doing, they reached your backups first. The recovery plan you rehearsed is recovering nothing. Your customers can't see their money. The media has the story. Regulators are calling to ask what you need. And somewhere in the building, someone is deciding, for the first time and under the worst possible conditions, which service to bring back first.
That decision should have been made years earlier — in a quiet room, by people with level heads and time to test their thinking. That is what a Minimum Viable Organization is: the answer to what must we keep alive to survive?, settled before you need it.
For ten years, Sheltered Harbor worked at the center of the U.S. financial sector on exactly this scenario, and Resilience - by Design is still on that mission. What follows is our point of view, formed the hard way — by getting hundreds of institutions to agree on what "minimum" really means, and then helping them make it real. You'll see why an MVO for a severe cyber outage is different from ordinary disaster-recovery prioritization, how the industry actually did the work, and where organizations get stuck when they try it themselves.
A note on the term
Your Minimum Viable Organization (MVO) is the whole — the critical services, plus the people and infrastructure that sustain them, that keep the enterprise viable through a severe outage. The running heart of it, the specific services you keep alive on the worst day, is your minimum viable operation. The organization is what you protect; the operation is what you run.
Five things worth keeping in mind before you start
- Getting to an MVO is iterative. As the organization matures, you add to the initial version — you don't have to define everything at once.
- Planning even a small MVO gets the whole organization thinking about resilience differently. Sheltered Harbor started with two simple services and grew the model to cover almost anything an institution might call critical.
- Real resilience takes a cultural shift. It comes from the top and takes some early effort — but once people catch it, resilience thinking spreads into everything, and defining the next MVO gets easier.
- Educating your people is essential. Resilience is as much about culture as it is about people, process, and technology.
- Treat the whole effort as a chance to upgrade the organization — one critical service at a time.
What an MVO is, and what it is not
Define it against a specific, brutal scenario: service delivery has to continue despite the loss of normal operating capability, and the fallback and failover you counted on are gone too. In a dedicated attack, assume the adversary already altered your backup systems and backup data — your normal recovery approach has been rigged to fail. That is the context. It is not a storm that floods a data center. It is not a hardware failure you fail over from. It arrives suddenly, it is often total, and it poisons the very things you built to recover with.
An MVO is the minimum operational capability you must sustain to keep delivering your critical business services during and immediately after that kind of disruption. It is internally focused — policy decisions, essential processes, infrastructure, and people held at a base level until full recovery is possible. It:
- centers on continuity, not full performance
- covers critical functions, not all functions
- prizes speed of restoration under constraint
- drives crisis response and incident management, not steady-state operations
Much has been written about operational resilience, and to many organizations the phrase still lands as a synonym for disaster recovery or business continuity. The MVO is newer, and it exists because destructive cyber outages behave differently from everything those older disciplines were built to handle.
Where we tripped into MVO — 2016
Sheltered Harbor began because a broad coalition — institutions, regulators, service providers, law enforcement — reached the same conclusion: if a bank were operationally wiped out by a cyber incident, the loss of public confidence could spread into panic, and that had to be prevented. More than thirty financial institutions, key service providers, and industry trade groups contributed over three hundred subject-matter experts to the problem. Because most of the liquid assets that touch the largest share of the population sit in banks, credit unions, and brokerages, those institutions became the focus.
At the core sat a hard fact: in this scenario the institution likely cannot reach its own systems and data — or cannot trust what it can see. If no one knows who the customers are, and no one can see their balances, then no one can help. So we set out to preserve that information for the worst day. The first task was to agree on what critical data had to be protected in a cyber-resilient vault. And that is where, in 2016, Sheltered Harbor first walked into the concept of a minimum viable operation.
You might assume it's obvious what "critical data" means for a bank — who the customer is, and what's in their accounts. Thirty institutions held more than thirty opinions. The easy answer was to vault everything: take the full superset of customer and account data, encrypt it, call it covered. Easy was wrong.
It was wrong because the data serves one purpose — maintaining public confidence, as fast as humanly possible. Time is the binding constraint, and that reframes the whole problem:
- Minimize the data. This is among the highest-order PII, it has to be encrypted, and the more you store, the longer it takes to decrypt and put to use on the day you have no time to spare.
- Store a common, minimal set — who the customer is, what accounts they hold, and the balance in each as of a defined time — in a fully cyber-resilient vault that survives whatever took the platforms down.
- Make the data and the vault trustworthy enough that another institution can step in and help, with confidence, when a stricken bank needs a hand.
To agree on that minimal set, we had to keep returning to the use case. Picture the stricken bank: operationally out of the water, its customers cut off from their assets, no one able to help because no one can say who those customers are or what they own. The customers are frightened. The media is stoking it. Regulators are circling — wanting to help, or needing to answer a rising public demand. Customers of other banks start to wonder too. Your disaster recovery may be making progress, but you can't say whether it will take hours or weeks. Imagine the noise.
The two services
In that scenario, the most important thing you can do is give customers reasons not to panic: communicate early and often, and make it clear the bank is solvent and this is a temporary operational outage you were ready for. That's where the community landed on what a bank, broker, or credit union must deliver soonest. More than three hundred experts agreed on two services, deemed equally important — Priority 1A and 1B:
- give customers access to their balance information
- give customers access to their funds
Usefully, delivering those two services also buys the institution the time its recovery plans need to bring normal operations back.
Sheltered Harbor-certified banks and brokers were required to make both services fully available within 24 to 36 hours of the onset of the outage. As a floor, that holds up. But meeting it forces each institution to get specific about how — captured in a Resilience Plan unique to that institution. One bank may have customers come to a branch for balances and cash. Another may prioritize balances on the web and funds through ATMs. Many will do both, over different time windows. The agreement on what the MVO is becomes the start of the roadmap for how the institution survives.
Define your MVO against a specific scenario and outcome, and be as specific about the outcome as you can. A vague definition almost never survives contact with a real recovery on a severe day.
Some look at this and call it oversimplified. For some organizations it may be; for others it's exactly right. The point is that this is a minimum — not everyone's MVO. Yours may match a competitor's or differ from it. It doesn't matter. Worry about your own, and you're on the road to real resilience.
So what's the big deal?
That was a high-level summary of something that took the industry thousands of hours. It skips the confusion and the disagreements we worked through to reduce more than thirty services to two. We did it in a few short months — and the striking thing we learned afterward is how hard that is to reproduce inside a single organization. We had advantages most companies don't. The Sheltered Harbor group:
- was well educated on the severe-outage scenario
- understood the urgency
- had no immediate personal stake in the impact of its suggestions
- had already worked together for months before MVO became the focus
Teaching institutions to prepare for a severe outage year after year, we keep finding the same bottleneck at the start of the journey: agreeing on the MVO. It demands an alignment of knowledge, goals, availability, and creative freedom that most organizations don't have lying around. Here are the traps we see most often.
1. Conflating the MVO with disaster-recovery priorities
The most common error is treating cyber incident response as if it were disaster recovery and business continuity. At the far end, some organizations try to define their MVO straight from existing business impact analyses. On the surface it seems sensible, and a current BIA is a useful starting point. But the outcome you're planning for here is different. In a severe cyber outage you are racing to recover just enough to sustain the MVO — not to restart the whole production environment in a clean state. That is what DR and BCP are for. Some of what a traditional BIA prioritizes will actively mislead a cyber recovery.
2. Conflicting interests and perspectives
Even when an organization accepts that this needs different planning, it too easily lets everyone shape the "true" minimum. Ask several leaders what the minimum viable operation is and you'll get several answers. Try to make every candidate service equally resilient and you may never finish — and cost will stop you before you do. Ask the heads of retail operations, customer service, regulatory reporting, and treasury which services are most urgent after a total blackout, and each names a different one. Your head of technology may say it's already handled — the business continuity plan has prioritized critical applications. But applications aren't a clean proxy for business services, and recovering one drags in its dependencies and platforms, which can stretch out the recovery of the service that actually mattered.
3. Who actually decides
The ideal MVO is defined — or at least ratified — by the C-suite. Too often the journey starts from the middle or the bottom, and those efforts reliably produce wasted resources and paper-only plans. When two executives each believe their service outranks the other's, how does it get resolved? Frequently both are simply declared equal priority. Sometimes that's necessary; often it's costly, and it may not serve the extreme scenario you're planning for. Remember that you define the MVO in order to invest in keeping it secure and running through an outage — and the more you fold into "minimum," the longer recovery takes. You don't want to be arguing about where recovery resources go on the worst day. You want that settled and funded long before.
4. Confusion about the MVO's purpose
Some organizations read regulatory requirements for operational-resilience MVO and map them onto unrelated obligations. We've covered the DR and BCP confusion. We've also seen firms point to their "living will" requirements and assume those can be repurposed — which pushes them toward planning for a maximum viable, discrete organization instead.
5. No discipline about "minimum"
Resilience is not a compliance exercise. It's a discipline, and it needs a culture that supports continuous adaptation and improvement. The MVO sits at the core of what the organization calls its most critical operations, which means it decides where the most rigorous resilience design gets applied. Get it wrong and a severe cyber outage may finish you.
Time is the binding constraint, and a severe outage brings a typhoon of competing priorities. You need an unambiguous strategy for what must be functional in the least possible time — no room for interpretation about the order of recovery, because ambiguity there costs the very time you don't have.
Take the lazy path as a cautionary tale. Declare that every service is required, call the MVO "done," and lean on your existing BCP and DR until the day arrives. Then everyone is recovering everything with no real sense of priority, the recovery collides with itself, it runs long, and the organization fails. Customers are stranded, no one has a job, and someone may go to jail.
In the early days we started with more than thirty services banks provide and had to find the handful that must survive. Thirty became ten, ten became four, four became two. The counterintuitive lesson bears repeating: nearly every executive began with loans, because loans are a large share of the balance sheet. But our purpose was maintaining confidence, and no customer panics over a loan payment deferred by a day, while every customer can panic if they can't reach their money. A bank could withstand a few days without servicing loans. It could not withstand customers unable to check a balance or make a payment.
6. Regulatory frameworks that assume you already know your MVO
Financial regulators everywhere share the same worry: the damage a cyber outage could do to the financial system, and the tear in the social fabric that follows a loss of trust. There is a litany of operational-resilience regulation aimed at limiting that damage. Some, like DORA in the EU, are explicit about resilient minimum operations. Others say nothing about the MVO and simply assume institutions know which services matter most. In between sits enough variation in language and metrics that a global bank has to be half-schizophrenic to satisfy all of its regulators at once. As one senior industry figure put it: "MVO and resilience are great concepts — until semantics get in the way."
That variation is a good argument for having a well-articulated MVO and a well-tested plan to keep it running through a disruption. Demonstrate that level of resilience and you'll satisfy nearly every regulator. You may have to tailor the reporting to local metrics, but the substance of what you do — at the level of policy and behavior — can stay consistent everywhere.
7. Fear of the unknown
Early on — usually before the right stakeholders are in the room — leaders can freeze on the belief that they need every answer before they can rally the organization. Call it fear of failure. The fix is to bring a broader group of leaders and influencers into the why before you demand the what.
Nobody holds all the answers on the MVO before a wide enough cross-section of the organization's functions has argued it out. Defining your MVO is iterative by nature: every added perspective sharpens the line between what is truly critical and what is merely nice to have. It's natural, as the person leading a program, to feel you should hold every answer. But defining an MVO — and planning to keep it running no matter what — is a transformational effort. You set a direction, a few guardrails, some success metrics, and then you let a smart collective carry it forward. Get good at one level of MVO, and the organization will extend the approach to more services on its own.
The opportunity
Defining a Minimum Viable Organization, and committing to keep it running through the worst day, is not a compliance chore. It's a chance to change how the organization thinks — to make it more resilient one critical service at a time, and to build the muscle and the culture that resilience actually requires. We started with two simple services and grew the model to cover almost anything an institution might call critical. You can start smaller than you think. You just have to start where it counts.
That's the work to become Resilient - by Design: understand what your Minimum Viable Organization is, and make it real.