Tag Archive for disaster recovery plans

Disaster Recovery Planning vs. Disaster Recovery Plans

So often, when we are engaged to review existing business continuity and disaster recovery plans, we find volumes of “plans” with very important planning information but very little in the way of action plans for at-time-of-recovery activity.

By this, I mean, many “plans” include information discovered in the BIA and Risk Analyses.  There are tables and reports on what the impacts are for being down, what the requirements are in a recovery center, how many desks are needed in a recovery site, special equipment requirements, special forms, vital records listings and locations, what the critical applications are, RTO’s, RPO’s, vendor listings, employee listings, and on and on and on.

All of this information is CRITICAL INFORMATION for designing a recovery solution, but is of no real value at time of an incident.

At time of disaster, I need to know how to engage the plans and how to employ the capabilities that are provided –based on all that information listed above.

In my opinion, this information should be segregated.  When a business interruption event occurs, I do not care what the findings were in the BIA or RA – all I want to know is what is in place now, how do we get to it and what do we do when we get there.

I review many plans that pass the weight test but are so full of “noise” and so loaded with information that they become too bulky and are not usable as an action plan for what we do.

Sometimes it can be as simple as separating the two parts of the plan – many times, the “action plan” component is missing altogether.  This is sometimes especially true when a database software tool is used.  The database reports look so good and fill up so many pages, people think that that is the plan.  No, that is a collection of information needed to ensure we put the proper capability in place, but is not the action plan for how we employ that capability.

Practical, pragmatic, easy-to-use action plans are hard to come by, but, what I am most interested in finding when asked to review an organization’s level of response preparedness.

Do not confuse a compilation of information gathered in the planning process as being your disaster recovery plan.

Removing the Fluff from the Stuff

I understand and appreciate the need to document your Business Continuity, mission, objectives, process, justification and analytical results.  I think all of this information is valuable in advancing and promoting your programs; educating management and participants on your program; and, providing a foundation for internal and external audits.  And, I think it is important to mandate that certain, key players in your program read and understand all of this information.

But …  Oh, come on, you knew there was a “but” coming.  But, I don’t think that stuff belongs in the same document that includes your “at-time-of-interruption” action plans.

Too often, I see organizations create one tomb of everything Business Continuity and call that their Business Continuity Plan.  In my opinion, you should have the book that explains everything business continuity related and then a stand-alone “Action Plan” that is you instruction manual of what to do when the lights go out.  In fact, you should probably create a whole bunch of “Action Plan”s – one for each unique function in your continuity, recovery and emergency response program.

I think reading and understanding “the book” prior to an emergency is important and should be mandated.  However, much of the stuff in “the book” just gets in the way at time of event.

“The book” should: set the premise for your program; identify objectives, assumptions and givens; explain, holistically how teams work together; provide background on how and why strategies and solutions were selected; explain the entire planning and implementation process – all stuff that is important to know, prior to an interruption, but just becomes a burden to flip through when trying to figure out just what to do now that an event is occurring.

The “Action Plan”s should be concise and detailed, step-by-step, vetted through testing, tactical tasks to be undertaken once a disaster is declared.  These plans need to be easy to follow (relatively) easy to reference and to enough detail that a backup team member, with less experience in the process, can follow and successfully implement.

I have seen organizations get very creative in producing wallet sized plans, tri-folds and/or thin plans that get right to the point and, in some cases, provide a way to record which steps were executed along the way.

There are a number of software products that also help maintain these action plans and allow you to track the implementation process at time of disaster.  These can be very powerful emergency management tools if properly implemented and monitored.  (They can also become just as cumbersome and useless as the War and Peace-like plan if implemented incorrectly.)

So look at your documentation and ask yourself if you have successfully separated the wheat from the chaff?  Do your team members have a useful tool to help them execute their recovery responsibility at time of disaster without having to flip through pages of “fluff” to find out exactly what they are supposed to do?  And, when you test your program, do you make sure these plans are being referenced and updated to ensure the documentation matches the reality?

More on this topic to come in future blogs, but – I use that “but” word a lot, don’t I – I think that is enough for today.  Thanks for visiting our blog.

Why I Hate the Word ‘Plan’

I have already discussed, and most of us already understand, that business continuity, disaster recovery and crisis management professionals are challenged by use of an inexact and often confusing jargon.  We use terms such as business continuity, disaster recovery, resiliency, hot site, warm site, cold site, recovery time objective, recovery point objective, business impact analysis, contingency plans, etc., that are often used to mean very different things to experienced and practiced professionals – not to mention what they mean to the uninitiated.  It can be confusing and often lead to misunderstandings and gaps between expectations and deliveries.

But, the one word I hate the most.  The word that makes me cringe when I hear it.  The word I try to eliminate from the vocabulary of consultants who work for me is … “plan”.  Such a little, simple word – how can I possibly have such distaste for this common word amongst all those other confusing terms?  Well, I’ll tell you.

What exactly do people mean when they say the word “plan”?  And what exactly do people assume when they hear the word “plan”?

There have been more than one occasion where a consultant went into an organization and had this conversation:

CONSUTLANT:  “Do you have business continuity (or disaster recovery) plans?”

CLIENT:  “Yes.”

CONSULTANT:  “Can I see them?”

CLIENT:  “See what?”

CONSULTANT:  “Your plans.”

CLIENT:  “Oh, there is nothing to see, our plan is to …”

What the consultant was meaning to ask was, “Do you have a manual of documented business continuity policies and procedures?”  What the client heard was, “Do you have a business continuity solution in place?”

Then there was this rather uncomfortable moment I had in a corporate board meeting where I was reporting on the company’s business continuity posture:

CEO:  “Okay, Joe, cut to the chase.  You have been here a while, what is your greatest fear that could impact our ability to operate our business?”

JOE:  “A data center disaster.  This is the one disaster that will impact your operations world-wide and bring everything to a halt.”

CEO:  “But, we have taken care of that.  Our IT Director just gave us a presentation last month on his Disaster Recovery Plan in case of a data center disaster.”

JOE:  “Yes, I saw that presentation.  His plan is a plan to build out a recovery capability – but you have no recovery capability today.  His presentation showed a backup site that he recommends be established but isn’t there today.  If your data center goes down today … you are out of business.”

CEO:  (Turning to the IT Director)  “Is that true?  We don’t have a recovery plan today?”

IT DIRECTOR:  “No, we have a plan.  It is just going to take us 15 months to get it up and running if the budget gets approved.”

CEO:  “Oh, that’s not good!  I was under the impression we had a plan in place and not just a plan to build a plan.”


I have seen it time and time again.  The board of director does what it is told to do; ask if we have a plan in place.  The responsible party gives a nice terse, “Yes” answer and everybody is happy.  Then I come in later and explain, “Well, you might have a recovery ‘plan’ but you don’t have a recovery capability.”

I instruct my consultants:  If you want to know if they have a recovery capability, ask them what their recovery capability is; If you want to know if their capabilities are supported by documented policies and procedures, ask them to see their documented policies and procedures.

My consulting plan is – avoid the word “plan” – and, be more precise by stating what you want that word to mean.