DR vs. BC
Dueling Recovery Plans

By GREG HOLDBURG, MRP

Many companies today have created an environment of hostility between disaster recovery planning (DRP) and business continuity planning (BCP). Companies are creating two independently operating groups tasked with planning for a disastrous event.
Below is the industry’s own definition of the disciplines from the DRJ glossary:
DISASTER RECOVERY PLAN (DRP): The document that defines the resources, actions, tasks, and data required to manage the business recovery process in the event of a business interruption. The plan is designed to assist in restoring the business process within the stated disaster recovery goals.
BUSINESS CONTINUITY PLANNING (BCP): Process of developing advance arrangements and procedures that enable an organization to respond to an event in such a manner that critical business functions continue with planned levels of interruption or essential change.
How did the two grow apart? The best way to understand the situation is to look at the history of the recovery process.
We went from back-up tapes and reciprocal agreements to contracted recovery centers and mirrored systems. Disaster recovery was purely the domain of the IT department. This was the birth of disaster recovery planning. Everything focused on, “How can we recover our data systems?”
This went on for years until someone figured out that a data center without the dependent departments and business units is worthless. A plan needed to be developed that would address the end users. This was incorporated into the disaster recovery plan and supported by the bigger disaster recovery “hot-site” support companies as “end-user recovery.”
As time went on business requirements changed and a need to recover all critical business functions of a company became mandatory. The solution was called business continuity planning (BCP).
Now companies could design plans that would cover help desk functions, order departments, payables, manufacturing and distribution centers, and many other critical areas. The BCP, in many cases, was not controlled by the IT group. It was instead handed over to another department such as security or finance.
Just prior to this, the fledgling industry of disaster recovery planning (now business continuity) began to train and certify professionals in the disciplines of both IT disaster recovery and business continuity.
In the early years of the certification process, most of the attendees at the training were IT professionals and most plans being developed were heavily slanted to the needs of IT operations. It did not take much time, however, for non-IT professionals to begin to be certified in the industry. Company management began to create a position for the business continuity planner to design plans to address the issues of continuity planning not addressed by the IT disaster recovery plan.
This was the start of a problem that many companies are facing today. Do the two plans link up where needed in the event of a disaster? Many areas are gray as to which group, DRP or BCP, is responsible.
For example, computers located outside of the IT data center may be covered by BCP and not DRP, even though systems in the IT data center are dependent on the files these systems generate. DRP is responsible for data communication lines, and BCP is responsible for voice lines. If a relocation is required for recovery, do both plans coordinate the separation of the IT department to a “hot-site” that may be hundreds of miles away from an alternate operations facility? This situation brings to mind the old adage of “a house divided.”
In my almost 15 years in the business continuity industry, I have seen many plans that were flawless in design and have been tested in table-tops and mock drills but would be useless in an actual disaster situation because the business continuity plan and the IT disaster recovery plan do not linkup.
In many cases company politics have entered the equation. The two groups have very little interaction with each other. They report to differing management groups battling for the same budget dollars.
I’ve seen companies with different versions of planning software, one group with planning software and one without, and planning software from different vendors. They could not merge or coordinate recovery steps even if they wanted to.
Users are annoyed with multiple business impact surveys from the two groups, and other groups get completely passed over because one group assumes the other is responsible for that area. I’ve even seen individuals from one group spying on the other.
Many recovery planners get frustrated and leave the company in search of “greener pastures.” This leads to the loss of valuable recovery procedure knowledge and leads to additional business impact surveys to already frustrated recipients.
Now that we understand how we got into this mess, we can explore how to correct it.
First, a company’s senior management needs to understand there is a problem. External and internal auditors as well as external consultants can aid in this discovery. Hopefully, in advance of this, a manager of one of the dueling groups will describe the situation to management and an external source can confirm the issue. Once management grasps the situation, the decision to combine the two groups will need to be made. I’m not advocating these two groups should be or should not be absorbed into a single group. But I am suggesting the total planning effort be controlled under a single manager. This would allow for a coordinated effort of the two groups to meet a common goal.
There are many benefits to the single manager approach. The user departments will get a feeling of greater confidence in the planning process by not receiving multiple questionnaires and attending multiple meetings with the same topics. The teams conducting the information gathering will have a “big picture” understanding of the entire business continuity/disaster recovery process. Team members can be cross-trained in the full range of tasks in the total planning project.
This will be of great help to lessen the impact if a team member leaves the company. Most importantly, if an actual disaster affects the company, the recovery team members who were involved in the planning process will have a detailed understanding of the roles of other team members and can cover the gaps if a fellow team member was not available for the recovery of the IT center and business operations.

©Copyright 2005 Systems Support Inc. All rights reserved. Reproduction in whole or in part in any form or medium without the express written permission of System Support Inc. is prohibited.

«BACK to the Articles Index