When theory meets reality
I came into business continuity management (BCM) the way many people probably do: through theory first, practice second.
Over the past few years, I went from studying these concepts at university to seeing them applied inside some of the world’s largest enterprises, while working at a fast-growing BCM technology startup. That transition from theory to practice changed how I thought about the discipline.
At university, frameworks can make resilience look relatively orderly: Identify the risks, build the plans, define the response, test them and improve. Then you see what happens inside a large organization; hundreds of processes, complex technology environments, third parties, supply chains and competing priorities which makes a disruption rarely fit neatly into the scenario someone at the company anticipated. And having more plans doesn't necessarily mean knowing what matters most when something actually goes wrong.
That was probably the assumption that changed most for me: preparedness and the volume of planning are not the same thing. Which brings me to the point of this article, a point I hadn't really considered before entering the corporate world and applying theory to practice.
How organizations approach crisis management. What problem was this process originally designed to solve? And does the traditional approach scale in a world of tightly interconnected processes, interdependencies, cloud infrastructure, multi-layered supply chains and AI?
Crisis management and disaster recovery have roots in disciplines that have existed for decades. But disruptions today are more frequent, interconnected and difficult to contain, making the intuitive response to scale the traditional model: More scenarios, more playbooks, more committees, more exercises. Basically, crisis management on steroids.
The problem is that scaling the volume of crisis management doesn't necessarily improve its focus. An organization can become very good at preparing for an enormous catalogue of things that might happen without being equally clear about the handful of things it simply cannot afford to lose.
This is where BCM started to make much more sense to me. BCM grew partly from the lessons of disaster recovery, but it introduces something important upstream of response and recovery: business prioritization. Rather than beginning with What could happen?, it begins with looking to answer a different question: What does this business absolutely need to keep running?
Once you know that, the rest of the resilience conversation starts to look different.
Crisis management and BCM: the fundamentals
On paper, the two disciplines can look similar. Both deal with disruption, preparedness and organizational resilience. In practice, though, they approach the problem from different directions. Crisis management tends to start with the event. BCM starts with the business.
There are a few fundamentals behind that distinction.
Crisis management is event-driven. BCM is proactive.
Crisis management kicks in when an incident exceeds normal operations and the organization needs to coordinate its response. BCM starts long before that point. It identifies the processes and services the organization depends on, understands what would happen if they were disrupted, and puts strategies in place to keep them running or recover them within an acceptable timeframe. One is asking, How do we respond to what is happening? The other is asking, What do we need to protect before anything happens?
Crisis management is scenario-centric. BCM is business-centric.
Crisis management often prepares around events: a cyberattack, supply chain failure, natural disaster, reputational crisis or another defined scenario. In that sense, the playbook becomes the recipe for how the organization responds to a particular type of disruption. BCM approaches the problem from the other direction. Instead of starting with What could happen?, it starts with What does this business absolutely need to keep running?
Take ransomware as an example. A scenario-centric approach might ask: What should we do if we experience a ransomware attack? A business-centric approach asks: Which critical services would a ransomware attack disrupt? How long could we operate without them? What dependencies would prevent their recovery? What would we need to restore first?
Neither question replaces the other. But the second gives the first much-needed context.
Crisis management is communication and decision-based. BCM is operations-based.
During a crisis, someone needs to make decisions under uncertainty. Someone needs to determine whether to escalate, coordinate stakeholders, communicate internally and externally, and provide direction while the situation is still unfolding. That is where crisis management comes in.
BCM provides the operational lens underneath those decisions. Which processes need to continue? Which can temporarily stop? How quickly must they recover? What dependencies are involved? Where should limited resources go first?
Crisis management helps the organization decide and communicate. BCM helps it understand what needs to keep operating and what needs to recover.
Crisis management is acute. BCM is continuous.
A crisis has a lifecycle. It happens, escalates, is managed and eventually moves towards resolution. That might take hours, days or, in more serious cases, weeks. BCM, however, doesn't begin and end with an event. It is a continuous program of understanding the business, designing continuity strategies, implementing them, testing them and improving them as the organization changes.
That distinction matters because resilience isn't something you build only when a crisis arrives. Much of the work that determines how well you respond has already happened before the crisis team is ever activated. This has become even more acute at a time where disruptions are becoming more frequent, more embedded and more interconnected across operations. Understanding the business landscape, risks and impact is even more critical to ensure effective crisis management for the survival of the organization.
Crisis management without BCM can lack prioritization. BCM without crisis governance can lack decision rights.
This, to me, is where the relationship between the two becomes most important.
Crisis management without a strong business continuity lens can become a sprawling collection of scenarios and playbooks. You prepare for cyber, supply chain disruption, reputational crises, natural disasters and dozens of variations in between. The organization becomes increasingly prepared for things that could happen, but not necessarily clearer about what matters most if they do.
That is how you can end up with crisis management on steroids: more scenarios, more playbooks, more committees and more exercises, but not necessarily better business prioritization.
BCM can have the opposite problem. An organization might have strong impact analysis, carefully defined recovery objectives and technically sound continuity strategies, but still struggle when a real crisis requires fast decisions, clear escalation and coordinated communication.
So I don't think the useful question is whether BCM or crisis management is "better". They answer different questions. Where organizations fail to leverage the functions to their fullest potential is when they're treated as the same discipline, or when one is expected to do the other's job. The most resilient organizations don't choose between them. They bring the two together, with BCM providing the business lens and crisis management providing the governance, decision-making and communication layer.
And that brings me to why I've come to see BCM as the bedrock.
Why I see BCM as the bedrock
Calling BCM the bedrock of crisis management doesn't mean an organization without a formal BCM function is destined to fail. Plenty of organizations manage crises effectively without a mature BCM program. And in practice, the boundaries between the disciplines are rarely as clean as they appear in frameworks. The more important distinction is the thinking behind them.
Crisis management helps answer: How do we respond when something goes wrong? BCM helps answer: What can we least afford to lose, and what must come back first? Without an explicit answer to the second question, organizations still have to prioritize during a crisis. They just do it differently. Through experience. Gut feel. Seniority. Whoever shouts loudest. Or whatever appears most urgent in the moment. Sometimes that works, but it isn't particularly repeatable.
BCM makes that prioritization explicit and evidence-based before the organization is under pressure. This is where the Business Impact Analysis (BIA) becomes much more than a compliance exercise.
At its best, a BIA forces an organization to make uncomfortable choices. Which services and processes are genuinely critical? How does their impact increase over time? What technology, people, suppliers and facilities do they depend on? How long could the organization realistically tolerate their disruption? And ultimately: what gets recovered first? Those answers should then become a filter for crisis management.
Instead of developing equally detailed playbooks for every imaginable disruption, you can ask which scenarios threaten the organization's most critical capabilities. Exercises can focus on those intersections, decision rights can be designed around them and resources can be concentrated where the consequences of failure are greatest. Without that business lens, crisis management can start to feel like shooting in the dark: a great deal of activity, but not necessarily aimed at the things capable of doing the most damage. BCM gives that activity a compass.
From "this is how it's done" to "why?"
That's probably been the biggest shift in my thinking since moving from theory into practice. I started with this is how BCM and crisis management are done. Increasingly, I've found myself asking: Why are they done this way, and does that still make sense?
I've seen organizations with crisis management but limited BCM, organizations with mature BCM programs, and organizations with both. Having the functions and frameworks in place doesn't automatically mean the underlying thinking is happening. What matters is how the disciplines work together.
For leaders who believe crisis management is already "covered", I'd ask a few fairly simple questions: Do we actually know our five or ten most critical business processes or services? Do we understand the dependencies that keep them running? Have we agreed how long they can be unavailable? And when we look at our crisis scenarios, can we trace them directly back to those priorities, or are we still working from generic categories such as "cyber", "supply chain" and "reputational crisis"?
For BCM practitioners, there's an equally important challenge. Don't let the BIA become something completed because a framework, regulator or audit requires it. Use it: Take the results back to the crisis team and ask: If this scenario happens, which of our critical processes are actually affected? Does the playbook reflect that? Where are we investing heavily in scenarios with relatively limited business impact while leaving our most consequential dependencies exposed?
That is where BCM and crisis management stop being parallel disciplines and start operating as one resilience system. And perhaps that's the question worth leaving with: Is your crisis management genuinely prioritized around what matters most to the business, or have you simply accumulated more preparedness activity?
A note from the author
Field Notes on Resilience is where I share observations from the field, shaped by working at the intersection of BCM and an AI-native technology startup. I explore established thinking, emerging technology and what the future of resilience could look like.If that sounds like your kind of conversation, subscribe to follow along. More field notes coming soon.
