IS YOUR RECOVERY PLAN “DONE”?

By Randall A. March

The Plan is done. All significant functional areas have been addressed and each team has a complete plan of their own, fully documented. Ah h h h...now you can sit back and relax, right? Wrong! You have only just begun, as the song says. Your business recovery plan must mirror your operational organization at all times in order to be effective when it is needed. It must be kept current and up to date, ensuring that changes in the organization are reflected in the recovery plan, as appropriate.
Following a major disruption, many organizations may be able to recover and resume operations, even without careful planning. The question is, can they recover within a time period that ensures that the organization does not incur an unacceptable impact from the disruption? It is the ability to recover and restore operations within the critical time requirements that makes a plan effective. The maintenance of the plan helps ensure that the plan remains effective. So what’s the best way to accomplish this?

Update Frequency

The plan must be updated on a regular basis. But what is regular? The definition of regular depends upon your organization. How often do changes occur in your organization? For most modern organizations, significant changes will occur during any six month period. People move, leave the organization, people are hired. Computer application systems are retired, new ones are developed. Computer systems are decentralized, adding more responsibilities to the business function areas. Facilities are closed, new facilities are opened, operations are consolidated. All of these changes dictate revisions to the recovery plan.
Changes in external organizations (e.g., vendors) may also affect your recovery plan. The plan must be updated to reflect the changes in other organizations upon which your organization depends.
On the other hand, some organizations are more stable, having relatively fewer changes over the same period. The frequency of formal revisions to your recovery plan depends upon the volatility of your organization.
Many organizations test and revise their plan once a year. Revising and testing the plan once a year results in your plan being effective for about three months of the year.
About a month before the test/revision, everyone gets busy, dusts off the recovery plan manual, updates it and gets ready for the test. The familiarity with the plan and its viability remain high for about two months after the test. Then it slowly fades into the background. Considering the investment that has been made in developing the plan, this is not an acceptable business recovery environment.
There is another argument for more frequent revision of the plan. Everyone involved in the plan must be thoroughly familiar with the plan and its strategies. If you test and revise the plan once a year, the people involved in the plan only think about it once a year. The plan should be in the back of everyone’s mind at all times.
When changes occur, one of the things they should think is, “Hey, this should be changed in the recovery plan!” To create this atmosphere, you should meet with the recovery teams every quarter, or at a minimum, every six months.
For organizations that experience continual change, we recommend that the plan be formally revised once each quarter. For more stable organizations, we recommend that formal revision occur at least every six months.

Basic Information Changes

There will be continual changes to names, addresses and telephone numbers in the plan. These should be updated once a quarter. When telephone numbers change, most telephone companies maintain the recorded referral to the new number for a minimum of three months, and then until the old number is reassigned. After that, it will be more difficult to reach someone who has had their telephone number changed.
Quarterly updates are sufficient to ensure that telephone numbers in the plan are up-to-date. In one organization I know of that accomplishes quarterly updates, the human resources department actually goes to the business recovery coordinator to obtain updates for personnel files. Their people more readily think about updating the recovery plan with changes than they do about notifying human resources.
Vendor organization names may change, as well as the people within the vendor organizations with whom you work. Vendors can move or go out of business. You are well aware of changes that occur with vendors with whom you work on a regular basis. But what about vendors whom you are expecting to use for supplementary or alternative support? They must be contacted regularly to ensure that their recovery plan information is up-to-date.

Major Revisions

The changes to basic information can be accomplished during the regular revision process. There are, however, major changes that should be incorporated into the plan as soon as they occur. These include:

Organizational Changes
-discontinuing departments
-forming new departments
-expanding or reducing departments
-adding facilities
-moving facilities
-reorganizing the management structure

Operational Changes
-adding new products or services
-revamping products
-discontinuing products or services

These changes can prompt revisions in time criticalities, required vendors, and alternate site requirements. The acquisition of a new computer system, or even a single piece of computer equipment, may require new contracts with the backup site vendor. These changes are significant enough to require immediate changes to the recovery plan, without waiting for the standard revision dates.

Foundational Aspects

The process of establishing the foundation for the recovery plan, usually done at the beginning of the development project, includes elements that are often overlooked as candidates for update. These include the risk assessment that identifies vulnerabilities, and the business impact analysis (BIA) that establishes time criticalities.
As the organization changes, vulnerabilities and business impact change as well. A risk analysis should be accomplished annually so that new and no longer existing vulnerabilities can be identified. Changes like these may require changes to your disaster prevention or security program.
Time criticalities for business functions and computer applications can change. Business functions can be de-emphasized or expanded due to a change in products or services. Computer applications that may have been under development during the initial BIA may be now in full operation and critical to the organization. Other applications may have been phased out and have a much lower time criticality. These changes affect the recovery criticality sequence of the business functions and applications. They may require updates to information and data backup procedures, alternate operating site requirements, or to the contract with the backup site vendor. Therefore, the BIA should be accomplished annually as well.

Recovery Plan Training

People, along with information, are the most important part of the recovery plan. Recovery teams must be familiar with the recovery process, and with their individual and team responsibilities, if they are to implement the plan following a disruption of their functional area.
As team membership and individual responsibilities change, team members need to become familiar with their revised team section of the plan. Even if there are no changes to their section of the plan, team members need refresher training to ensure that they can implement the plan if necessary. Each recovery team should meet for about two hours, at least once each quarter, to review the plan and to participate in a “walk through” test of the plan. Testing also uncovers any changes in operations, vendors, recovery strategies, procedures, and personnel information that may have been overlooked and that must be made to the plan. Testing also helps to keep recovery planning in the forefront of the minds of all team members.

Maintenance Tools

We have shown that basic recovery plan information must be kept up to date. This includes telephone numbers, equipment and supply lists, vendor lists, etc. Different people within the organization will have the knowledge required to keep this information current. One of the best tools to use to coordinate or control the update of this information is the table of contents of the business recovery plan. The person who is most knowledgeable about the information can be identified and their name placed next to the appropriate item in the table of contents.
Next, with the help of that person, an estimate can be made of the average length of time during which changes to that information can be expected. A notation as to how often that information should be reviewed (monthly, quarterly, semi-annually) can then be made. You now have a tickler file for requesting updated information.
Over the last 10 years, technology has provided major enhancements to maintaining the information in the recovery plan. In order to update a word processed plan, one had to know every place the information was referenced in the plan. With the development of relational database recovery planning software, you only have to know the one place that the piece of information is stored. You can change it there and the changes will be reflected everywhere in the plan.
To be effective, a recovery plan must enable the organization to recover and restore operations within the defined critical time frames of that organization. In order to meet those time requirements, a recovery plan must be maintained and kept up to date, so that it mirrors the operational organization at all times. Formal updates to the plan should be made on a quarterly basis.
Quarterly recovery team meetings help to keep recovery personnel involved and familiar with the plan. Maintenance of the recovery plan is a continuous process, not a once a year happening. The recovery plan is never “done”.

Randall A. March, CDRP, is Vice President, Consulting for Computer Security Consultants, Inc. (CSCI)

Disaster Recovery Worldİ 1999, and Disaster Recovery Journalİ 1999, are copyrighted by Systems Support, Inc. All rights reserved. Reproduction in whole or part is prohibited without the express written permission form Systems Support, Inc.