My Favorite Mistake: 6 Common Business Continuity Misconceptions
![In the course of our client engagements, MHA’s consultants routinely encounter people with beliefs or assumptions about business continuity that are incorrect and counterproductive. In today’s post, we’ll look at six common misconceptions about BC then set the record straight on each one. [Related on MHA Consulting: Hit or Myth: 5 Common Misconceptions About IT Disaster Recovery] Invalid Assumptions and False Beliefs The most common misconceptions people have about business continuity today include a few classics and a few new misunderstandings that have sprung up in the wake of the migration to the cloud. Here are some of the invalid assumptions and false beliefs we encounter most frequently, along with accurate information on each issue. As you read, think about whether you or any influential people at your organization hold any of these misguided BC beliefs. 6 Common BC Misconceptions “The IT department takes care of business continuity; we don’t have to worry about it.” At the heart of this misconception lies a failure of imagination, or a tendency toward amnesia. It is based on the mistaken idea that the only kind of disruptions an organization can experience are ones centered in their IT systems. Granted, many of the worse threats companies face today are IT-related (e.g., outages, ransomware and data breaches). But all the familiar non-IT threats (e.g., wildfires, power outages, incidents of workplace violence) are still out there; by some measures, these threats are more prevalent than ever. Plus, even IT-related outages require participation from non-IT personnel. Who else is going to develop and perform the manual workarounds needed to keep things going while the IT department is restoring the IT functions? Business continuity is not simply “IT’s problem.” It is also the concern of the business departments. “IT can meet our RTOs, no problem.” The business units often assume (without validating the assumption) that IT is able to meet the Recovery Time Objectives for the systems and applications they depend on. Actually, the issue is even bigger than that: often the organization has no formally determined RTOs. In these cases, the business units typically have a rough idea of the timeframe in which they believe their systems should be restored. They assume IT knows this information (by mind-reading, perhaps). They also assume IT agrees with this timeframe and is committed to meeting it. Meanwhile, IT has its own assumptions, usually very different from those of the departments. A common result in these cases, when and if an event occurs, is costly delays coupled with frustration and hard feelings. “Our customers will understand if we ever have a little problem.” Actually, they probably won’t. Nor will your vendors. These days, customers and vendors expect the organizations they deal with to be able to continue to provide goods and services no matter what. The assumption today is, responsible organizations are aware of the possibility for disruptions and are prepared to deal with them. Good companies own their performance and availability. They don’t use an assumption that others will be easygoing to excuse them from having to prepare. To rely on other people to be forgiving is to court such impacts as loss of revenue, defection of customers, and reputational damage. “I don’t need DR, my apps run in the Cloud.” The cloud is great, but it is far from being immune to problems and cyberattacks. It is important to remember that cloud is more than just Software as a Service. There are organization-managed applications running in the public cloud, and that vendor is not responsible for availability. In fact, cloud computing installations are a frequent target of hackers. Even if your applications run in the cloud, you still need to think about IT disaster recovery, including vetting the resilience of your provider. “We don’t need a formal BC program. If we ever have a disaster, our folks will be able to figure how to respond in the moment.” Well, maybe. But most organizations who take this approach, when forced by an event to put their ability to the test, report encountering unexpected problems that delay their recovery and raise the cost of the incident. Plus, even the best seat-of-the-pants responders can be stymied when the data they need to work their magic is not available as a result of the outage. The safer, saner, more cost-effective approach is to plan ahead and practice. “Figuring out manual workarounds in advance is a waste of time. If we ever need any, we’ll be able to set them up on the fly.” In today’s environment, assuming that system outages will be brief is rash. Lately, many organizations have experienced outages lasting multiple weeks. This underscores the need for manual workarounds. But coming up with such workarounds on the fly is often exceedingly difficult. Workarounds often depend on measures that are easy to take before an outage and impossible during one. It’s far better to devise and validate your manual workarounds before you need them. Closing Gaps and Ensuring Resilience Common business continuity misconceptions today include both longstanding myths about BC and new misunderstandings that spring from the migration to the cloud. Some originate in erroneous assumptions about what other people think or will do, some reflect overconfidence, and some arise from an unwarranted faith in the security of the cloud. BC practitioners should strive to become aware of and correct these misconceptions, whether held by themselves or others. By doing so, they can close gaps in their readiness and improve their organizations’ resilience. Further Reading The Cloud Is Not a Magic Kingdom: Misconceptions About Cloud-Based IT/DR All About RTOs: What They Are and Why You Have To Get Them Right Rehearsing Plan B: The Importance of Mastering Your Workarounds How to Get Business Units to Take Ownership of Their BCM Programs Hit or Myth: 5 Common Misconceptions About IT Disaster Recovery 6 Common Business Continuity Misconceptions](https://www.mha-it.com/wp-content/uploads/2022/11/bc-myths-1024x683.jpg)
In the course of our client engagements, MHA’s consultants routinely encounter people with beliefs or assumptions about business continuity that are incorrect and counterproductive. In today’s post, we’ll look at six common misconceptions about BC then set the record straight on each one.
Related on MHA Consulting: Hit or Myth: 5 Common Misconceptions About IT Disaster Recovery
Invalid Assumptions and False Beliefs
The most common misconceptions people have about business continuity today include a few classics and a few new misunderstandings that have sprung up in the wake of the migration to the cloud.
Here are some of the invalid assumptions and false beliefs we encounter most frequently, along with accurate information on each issue.
As you read, think about whether you or any influential people at your organization hold any of these misguided BC beliefs.
6 Common BC Misconceptions
- “The IT department takes care of business continuity; we don’t have to worry about it.” At the heart of this misconception lies a failure of imagination, or a tendency toward amnesia. It is based on the mistaken idea that the only kind of disruptions an organization can experience are ones centered in their IT systems. Granted, many of the worse threats companies face today are IT-related (e.g., outages, ransomware and data breaches). But all the familiar non-IT threats (e.g., wildfires, power outages, incidents of workplace violence) are still out there; by some measures, these threats are more prevalent than ever. Plus, even IT-related outages require participation from non-IT personnel. Who else is going to develop and perform the manual workarounds needed to keep things going while the IT department is restoring the IT functions? Business continuity is not simply “IT’s problem.” It is also the concern of the business departments.
- “IT can meet our RTOs, no problem.” The business units often assume (without validating the assumption) that IT is able to meet the Recovery Time Objectives for the systems and applications they depend on. Actually, the issue is even bigger than that: often the organization has no formally determined RTOs. In these cases, the business units typically have a rough idea of the timeframe in which they believe their systems should be restored. They assume IT knows this information (by mind-reading, perhaps). They also assume IT agrees with this timeframe and is committed to meeting it. Meanwhile, IT has its own assumptions, usually very different from those of the departments. A common result in these cases, when and if an event occurs, is costly delays coupled with frustration and hard feelings.
- “Our customers will understand if we ever have a little problem.” Actually, they probably won’t. Nor will your vendors. These days, customers and vendors expect the organizations they deal with to be able to continue to provide goods and services no matter what. The assumption today is, responsible organizations are aware of the possibility for disruptions and are prepared to deal with them. Good companies own their performance and availability. They don’t use an assumption that others will be easygoing to excuse them from having to prepare. To rely on other people to be forgiving is to court such impacts as loss of revenue, defection of customers, and reputational damage.
- “I don’t need DR, my apps run in the Cloud.” The cloud is great, but it is far from being immune to problems and cyberattacks. It is important to remember that cloud is more than just Software as a Service. There are organization-managed applications running in the public cloud, and that vendor is not responsible for availability. In fact, cloud computing installations are a frequent target of hackers. Even if your applications run in the cloud, you still need to think about IT disaster recovery, including vetting the resilience of your provider.
- “We don’t need a formal BC program. If we ever have a disaster, our folks will be able to figure how to respond in the moment.” Well, maybe. But most organizations who take this approach, when forced by an event to put their ability to the test, report encountering unexpected problems that delay their recovery and raise the cost of the incident. Plus, even the best seat-of-the-pants responders can be stymied when the data they need to work their magic is not available as a result of the outage. The safer, saner, more cost-effective approach is to plan ahead and practice.
- “Figuring out manual workarounds in advance is a waste of time. If we ever need any, we’ll be able to set them up on the fly.” In today’s environment, assuming that system outages will be brief is rash. Lately, many organizations have experienced outages lasting multiple weeks. This underscores the need for manual workarounds. But coming up with such workarounds on the fly is often exceedingly difficult. Workarounds often depend on measures that are easy to take before an outage and impossible during one. It’s far better to devise and validate your manual workarounds before you need them.
Closing Gaps and Ensuring Resilience
Common business continuity misconceptions today include both longstanding myths about BC and new misunderstandings that spring from the migration to the cloud. Some originate in erroneous assumptions about what other people think or will do, some reflect overconfidence, and some arise from an unwarranted faith in the security of the cloud.
BC practitioners should strive to become aware of and correct these misconceptions, whether held by themselves or others. By doing so, they can close gaps in their readiness and improve their organizations’ resilience.
Further Reading
- The Cloud Is Not a Magic Kingdom: Misconceptions About Cloud-Based IT/DR
- All About RTOs: What They Are and Why You Have To Get Them Right
- Rehearsing Plan B: The Importance of Mastering Your Workarounds
- How to Get Business Units to Take Ownership of Their BCM Programs
- Hit or Myth: 5 Common Misconceptions About IT Disaster Recovery
- Debunked: 9 Common Business Continuity Myths
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.
