Caution: 6 Signs of a Business Continuity Plan in Trouble

Not all Business Continuity plans are created equally.  Calling something a “plan” doesn’t make it one.  Real planning should go into its creation – not simply filling in blanks in a template, or copying a bunch of lists to an appendix.

A viable Business Continuity plan is actionable, applicable to any disruption, and effective under all circumstances.  It should be accessible, practiced and up-to-date.

In the rush to meet deadlines, satisfy regulatory standards or avoid audit write-ups, those real measurements of effective BCM plan development may get lost or overlooked.

Consider the following six caution signs.  If a plan exhibits two or more, it might not be a plan; it may simply be a document.

If the Plan is:

  • Predicated on Assumptions.  Assumptions can be useful, if they’ve been validated.  But assumptions can also be an excuse for threadbare plan content.  The more plentiful and comprehensive the assumptions (“This plan assumes all personnel, IT networks and applications will be available½”) the less useful the Plan will be.
    • Solution:  Focusing on restoring critical assets (a Process, an Application) rather than ‘operations’ will make planning easier – and assumptions less necessary.
  • Untested.  Claiming what a plan will do – without testing – is as easy as claiming you can make yourself invisible.  The trick is simply to avoid having to prove it.  Testing finds the inevitable gaps that need fixing.  Without testing, they’ll stay hidden – until it’s too late.
    • Solution:  Even simple tabletop tests will help identify the gaps and weaknesses.  Make sure testing is done without grading (nor Pass/Fail).  The objective is to learn. How often?  At least once a year.
  • A Closely-guarded Secret.  If only the author has seen the plan, or, nobody but the boss has a copy, it will be very difficult to implement in a crisis.  Especially if the author or boss isn’t available!
    • Solution:  Make copies of a plan available to everyone who will have a role in executing it.  If there are some thing in the Plan (customer data, financial information, IP addresses) that not every member should see, put those in an Addendum distributed only to those need-to-know participants.
  • Out-of-Date.  BCM is a process, not a project.  Businesses change.  If plans don’t keep up with those changes, they can’t be effective.
    • Solution: How often should a plan be updated?  Preferably, every time there’s a fundamental change within the business (or business unit, or function) it is designed to recover.  At a minimum, once a year – but every 6 months would be wiser.
  • A Book of Lists. A list of who’s in charge, a list of whom to call, a list of critical applications, a list of vital records.  It’s easy to turn a plan into a reference document:  provide a list of everything that might be needed and someone will figure out how to use them.
    • Solution: While the list (the ‘what’) is important, it’s really the ‘how’ that make it a plan. The reason for the list may be because the plan has such a wide scope (all the functions in a facility, every function in a major department, for example).  Narrow the scope, and focus on assets.  If the plan is designed to recover a single critical process, it is much easier to plan for the possibilities if any of its assets (people, facility, IT apps, vendors, etc.) are suddenly not available.
  • Based on a Scenario.  We like to think that a plan based on “No access to Facility”, or a “Tsunami Plan” will work.  Scenario-based plans rely on Assumptions (see #1 above).  Odds are that Mother Nature and chance – or a combination of both – will make the real life situation different (or more likely, worse) than the plan anticipates.  Unless the scenario plan can be expanded or scaled back quickly and easily, it may not be useful.
    • Solution: Scenarios have their place (if you can prepare in advance – such as for a Hurricane, or a Pandemic – a scenario plan makes sense), but impact scenarios are just too numerous.  Instead, focus on assets.  If you know what you need, you can plan what to do if that asset becomes unavailable.  It doesn’t matter what caused the disruption – as long as you know what actions you can take to recover the missing assets.

A well-developed plan provides a degree of comfort – knowing that you are prepared, should the unforeseen happen.  Substituting a poorly constructed document for a real plan creates a false sense of preparedness.  Take the time and the right approach to create viable, actionable plans, and you’ll be prepared for anything.

In upcoming blogs, I’ll talk about each of these Solutions in detail.

Related blog:
The Value in Business Continuity Planning – Beyond Preparedness

SHARE:
Jim Mitchell

Jim Mitchell

A frequent speaker at Business Continuity conferences, many of Jim Mitchell’s blogs can be found elsewhere on eBRP’s website and has published articles in DRJ, Continuity Insights and Continuity Central. Jim has more than 20 years of experience in Business Continuity; if you don’t agree with his opinions – he won’t be surprised.

Related Posts

Enterprise Resiliency: Navigating Through Disruptions

Enterprise Resiliency: Navigating T...

In today’s threat landscape, the ability of an organization to…
Orchestrating BC/DR Testing: Virtual – Emergency Operations Centers

Orchestrating BC/DR Testing: Virtua...

  Enhancing Planning and Logistics Management  Coordinating BC/DR tests involves…
Insights into creating a successful Disaster Recovery Test – Part 2: Preparation

Insights into creating a successful...

Insights into creating a successful Disaster Recovery exercise – Part 1: Objectives

Insights into creating a successful...

Aligning Cyber Incident Response Planning with Your BC/DR Program

Aligning Cyber Incident Response Pl...

Cyber disruptions – and their impact on both reputations and…
What Can You Do when your BCM software Relationship Falls Apart

What Can You Do when your BCM softw...

“This isn’t working.”  “I’ve changed.”  “I don’t see a future…
Aligning BC/DR to CSIRP Challenges

Aligning BC/DR to CSIRP Challenges

The immediate reaction to a cyber-security incident is the FUD…
Technology Modeling – the eBRP Way

Technology Modeling - the eBRP Way

Definition: Technology modeling is a point-in-time snapshot of an Enterprise’s…
eBIA – The eBRP Way

eBIA - The eBRP Way

Definition: A Business Impact Analysis (BIA) is the cornerstone of…
Threats, Impacts, BCPs

Threats, Impacts, BCPs

Within Business Continuity circles there is ongoing debate about the…