Relevant Contents
Need Tailored Business Continuity Insights?
Contact Us Now for Personalized Guidance!
When recovery plans fail during an outage, the breakdown can often be traced to casual assumptions that were proven false when the plan was put to the test.
The way to avoid this is by identifying and challenging your plans’ critical assumptions.
Related: The Overlooked Dependency That Could Derail Your Recovery Plan
Summary
- A business continuity plan does not guarantee that the organization is prepared to recover.
- Plans often fail because of untested assumptions about workarounds, alternate locations, personnel, and communications.
- The goal is to replace assumption with validation by testing the people, resources, dependencies, and steps required to execute the plan.
A Recovery Plan Does Not Guarantee Preparedness
Many organizations and BC offices seem to believe that once they have a recovery plan for a particular business process, system, or application, they have reached a place of security. That process, system, or app is now safe and sound, they think. There’s no need to worry about it anymore. If a disruption occurs, no problem. All they have to do is pull out and implement the plan they made, and all will be well.
In fact, a common mistake we see means that in many cases like this, all is not well. When people who have fallen prey to this error try to implement their plan, it often doesn’t work. As a result, the workaround envisioned cannot be activated. This leaves the original disruption to go on unmitigated, increasing its cost to the organization.
The mistake referred to is that plan authors frequently make assumptions that are not borne out by reality. In their planning, they commonly speed along from one major item to the next, failing to think carefully about all the steps in between. Often, when an event occurs, those steps do not work out as smoothly as the planners unconsciously assumed they would. If something critical is missing, the plan will not work.
Here’s an everyday example. Suppose a person is planning to set off in the family car on a long drive through a remote area with no cell service. In the back of their mind, they have the plan to use their jack and lug wrench to change the tire if they get a flat. Then they do get a flat. This is no big deal, they think. I’ll just jack it up and throw on the spare. Then they open the trunk and discover the jack is missing.
Just because you have a plan, it doesn’t mean you have the ability to recover.
Four Common Recovery Traps
In workplace recovery scenarios, fatal assumptions tend to crop up in the same three or four areas.
Workarounds
Alternate ways of getting things done are often defined vaguely in recovery plans. A plan might say, “In the event of an outage to our ordering system, we will manually track our transactions.” But the details of how exactly that will be done are frequently not defined, much less tested and practiced. Do the people who are expected to implement the plan have the forms they would need? Do they know where they are kept? Do they know how to use them? If the employees tasked with executing a plan don’t have everything they need every step of the way, the plan won’t work.
Alternate Work Locations
This is another area where we see a lot of casual assumptions that are often not borne out in reality. A recovery plan might say, “In the event Building X is unusable, staff will work from home.” That’s great, but there are a lot of issues that can make working from home difficult or impossible. These range from connectivity and authentication problems to data and device security. If these challenges are not thought through in detail and addressed ahead of time, that breezy instruction about working from home might prove useless.
Personnel
Another thing we often see in recovery plans is a line like, “Any available person will be able to perform that function.” This is very reassuring. Unfortunately, it frequently turns out not to be the case. We’ve seen organizations make this assumption about people in specialized roles like engineering, IT support, and the skilled trades where in fact it turns out not to be the case that someone else can do their job. There’s an outage, the specialist is away, and no one else around can do what they do. Or it could be a situation where the one person who knows how to use a certain machine is on vacation, or the one person who is authorized to grant certain approvals is home sick. Plans built on assumptions about the availability of such people cannot safely be relied upon.
Communication
Finally, there’s the issue of communicating about the emergency. We’ve seen quite a few plans that say something like, “If our regular communication channels go down, we’ll contact everyone through our ENS.” Then it turns out their contact groups or information is out of date or individuals don’t know how to use the emergency notification system. Once again, the organization has a plan, but it can’t be put into practice.
In each of these cases, the problem was not that the organization lacked a recovery plan. It was that they didn’t fully develop, test, and maintain the capabilities needed to execute it.
How to Turn Plans Into True Recovery Capability
Developing recovery plans is an important first step. It reflects a genuine commitment to preparing for the unexpected, meeting compliance obligations, and looking out for stakeholders.
We would just encourage organizations to take the extra steps needed to ensure that the plans they’ve put together will work when they need them.
Doing this requires identifying the exact and specific steps needed to execute their plans and making sure each one can be accomplished under all the circumstances that could foreseeably be in effect during an outage. The idea is to replace assumption with validation.
Doing this means asking questions such as:
Do People Know What to Do?
Recovery procedures should not exist only on paper. Personnel responsible for executing them should be trained, understand their roles, and have opportunities to practice.
Do People Have What They Need?
If a plan depends on manual processes, alternate locations, special equipment, communication tools, or other resources, those capabilities need to be available when needed, not just mentioned in a document.
Have the Dependencies Been Considered?
Recovery activities often rely on other systems, people, vendors, approvals, and processes. Those dependencies should be identified and addressed before an actual disruption occurs.
Have the Plans Been Tested?
Exercises are where assumptions meet reality. They reveal the gaps between what an organization believes will happen and what is actually possible.
A recovery plan should be treated less like a finished product and more like a capability that must be built, exercised, maintained, and improved over time.
The goal is not to create perfect plans that anticipate every possible disruption. The goal is to create realistic plans supported by the people, processes, and resources needed to execute them when it matters most.
In sum, a plan tells you what you intend to do. Preparedness determines whether you actually can do it.
From Plans to Preparedness
A business continuity plan is an essential foundation for recovery, but a document alone does not make an organization prepared. Recovery depends on validating the assumptions behind the plan and ensuring the necessary people, processes, and resources are in place.
The organizations best positioned to respond to disruption are those that look beyond the plan itself. They test their capabilities, challenge their assumptions, and continuously improve their ability to execute when conditions are less than ideal.
MHA Consulting helps organizations identify the gaps between documented plans and actual recovery capability. Contact us to learn how we can help you build a BC program that is practical, tested, and ready when it matters most.
Further Reading
- The Benefits of Stressing Out: Why You Should Stress Test Your Recovery Plans
- The Overlooked Dependency That Could Derail Your Recovery Plan
- Falling Short: When Programs That Look Good on Paper Fail in Practice
- Saying No: When the IT Department Reflexively Opposes the BC Program
- Using AI in Your BC Program: Opportunities, Risks, and Oversight
Frequently Asked Questions
Why isn't having a business continuity plan enough?
A written recovery plan describes what an organization intends to do during a disruption, but it does not guarantee the organization can actually do it. Recovery depends on having the people, processes, training, resources, and supporting capabilities needed to execute the plan under real-world conditions.
What kinds of assumptions most commonly undermine recovery plans?
Some of the most common involve manual workarounds, alternate work locations, personnel availability, and emergency communications. Plans often assume these capabilities will be available without confirming that they have been fully developed, tested, and maintained.
How can organizations reduce the risk of recovery plans failing?
They should examine every step required to execute the plan, identify critical dependencies, ensure the necessary people and resources are available, provide training, and validate assumptions through regular exercises and testing.
What role do exercises play in business continuity?
Exercises reveal the difference between what a plan assumes and what an organization can actually accomplish. They uncover missing resources, unclear procedures, training gaps, and other issues that are difficult to identify by reviewing documents alone.
What is the difference between a recovery plan and recovery capability?
A recovery plan is the documented approach to responding to a disruption. Recovery capability is the organization's proven ability to execute that plan successfully. True preparedness requires both documented plans and the validated capabilities needed to carry them out.
Richard Long
Richard Long is one of MHA’s practice team leaders for Technology and Disaster Recovery related engagements. He has been responsible for the successful execution of MHA business continuity and disaster recovery engagements in industries such as Energy & Utilities, Government Services, Healthcare, Insurance, Risk Management, Travel & Entertainment, Consumer Products, and Education. Prior to joining MHA, Richard held Senior IT Director positions at PetSmart (NASDAQ: PETM) and Avnet, Inc. (NYSE: AVT) and has been a senior leader across all disciplines of IT. He has successfully led international and domestic disaster recovery, technology assessment, crisis management and risk mitigation engagements.