The Disaster Recovery Plan - Part 4

IT Disaster Recovery Planning Process

Developing a technical disaster recovery strategy is just one step in the overall IT Disaster Recovery Planning process. This process is common to all IT systems and utilizes the following six steps:

1. Develop the Business Contingency Planning Policy and Business Process Priorities
2. Conduct a Risk Assessment
3. Conduct the Business Impact Analysis (BIA)
4. Develop Business Continuity and Recovery Strategies
5. Develop Business Continuity Plans
6. Conduct awareness, testing, and training of the DRP
7. Conduct Disaster Recovery Plan maintenance and exercise

The objective is to design a technical recovery strategy in step 4. Since this step is being accomplished before a Business Impact Analysis (BIA) can be performed in step 3, the recovery strategy is developed into a standard suite of service offerings that can be activated after the BIA has been completed. A BIA can take months to complete and some organizations do not have the budget for this. However, management should understand the potential return on investment for conducting a BIA.

The goal of the BIA is to define objectives for the recovery of host computing systems that run the applications that support the business processes. These objectives are stated as the Recovery Time Objective (RTO) and Recovery Point Objective (RPO). RTO is the number of hours or days management has put on resuming a business process or a system. RPO describes the age of the data you want the ability to restore to in event of a disaster. For example, if the RPO is 8 hours, systems should be restored in the state they were in no longer than 8 hours ago. The technical disaster recovery strategy depends upon meeting RTO and RPO specifications. The RTO and RPO requirements determine which option of disaster recovery plan to implement.

Recovery time, and how current data is are key components in determining the level of service a business process requires in the event of a major disruption. To properly implement a disaster recovery plan, one must know the RTO and RPO that the organization is willing to accept in case of a disaster. The technical disaster recovery strategy of different options of recovery is based upon a combination of these requirements.

Often times, in regards to business continuity, business and IT units are not on the same page. "As companies become more dependent on information, the business-continuity tolerance for information loss becomes less and less, particularly in e-business," says Don DeMarco, Director, IBM Business Continuity and Recovery Services. Although recovery management (maintaining an ITbased contingency plan and IT recovery plan) is an element of the systems management discipline, DeMarco says, "The decision as to the acceptable amount of risk for information loss must come from upper management."

For example, IBM uses RTO and RPO to classify the two objectives management must consider in business continuity. RTO is used by management to determine the amount of time needed to set up IT capabilities in order to resume critical business processes. RPO is something that management tends to forget. During an outage when business processes cannot be performed, how much data can the organization afford to lose and how current must data being recovered be? A manager of a bank cannot afford to loose six hours worth of data. Management must decide what are the acceptable levels of risk.

source:// SANS Institute InfoSec Reading Room