Create a Right-Sized Disaster Recovery Plan Close the gap between your current DR capabilities and service continuity requirements. Recent natural disasters such as Hurricane Sandy have increased executive awareness and internal pressure to have a functional DRP. Industry and government-driven regulations are placing more focus on BCP ― and therefore DRP by extension. Customers are also demanding that organizations have a workable DRP before agreeing to do business. Despite the mounting pressure to have a DRP, organizations continue to struggle with creating DRPs, let alone making them actionable. Traditional DRP templates are onerous and result in a lengthy, dense plan that might satisfy auditors but is not effective in a crisis. Similarly, the myth that a DRP is only for major disasters and should be risk-based leaves organizations vulnerable to more-common incidents. The increased use of cloud vendors and co-lo/MSPs means you may be dependent on vendors to meet your recovery timeline objectives. Myth #1: DRPs need to focus on major events like natural disasters and other highly destructive incidents such as fire and flood. Reality: The most common threats to service continuity are hardware and software failures. Myth #2: Effective DRPs start with identifying and evaluating potential risks. Reality: DR is not about mitigating risks; it’s about ensuring service continuity. We know failure can happen regardless of your risk profile, so strive for overall resiliency that will enable you to recover regardless of the specific risk or incident Myth #3: DRPs are a separate entity from normal day-to-day operations. Reality: Again, the goal of DR is to maintain service continuity, and that starts with day-to-day service management. Myth #4: I use a co-lo so I don’t have to worry about DR. That’s my vendor’s responsibility. Reality: You can’t assume your co-lo’s DR capability meets your needs or that DR services are part of your agreement. The same is true for cloud vendors. Myth #5: A DRP must be so detailed that anyone can execute the recovery. Reality: DR is not like an airplane disaster movie. You aren’t going to ask a business user to execute a system recovery, just like you wouldn’t want a passenger with no flying experience to land a plane. Keeping in mind your audience – knowledgeable IT staff – you can take a more visual and concise approach to documentation, which ultimately makes it more usable, easier to maintain, and therefore more effective. Choose flowcharts over process guides, checklists over procedures, and diagrams over detailed descriptions.

Create a right sized disaster recovery plan

Download PDF Report

Upload
info-tech-research-group
View
195
Download
1

Embed Size (px)

Citation preview

Page 1: Create a right sized disaster recovery plan

Industry and government-driven regulations are placing more focus on BCP ― and therefore DRP by extension.

Customers are also demanding that organizations have a workable DRP before agreeing to do business.

Despite the mounting pressure to have a DRP, organizations continue to struggle with creating DRPs, let alone making them actionable.Traditional DRP templates are onerous and result in a lengthy, dense plan that might satisfy auditors but is not effective in a crisis.

Similarly, the myth that a DRP is only for major disasters and should be risk-based leaves organizations vulnerable to more-common incidents.

The increased use of cloud vendors and co-lo/MSPs means you may be dependent on vendors to meet your recovery timeline objectives.Myth #1: DRPs need to focus on major events like natural disasters and other highly destructive incidents such as fire and flood.

Reality: The most common threats to service continuity are hardware and software failures.

Myth #2: Effective DRPs start with identifying and evaluating potential risks.

Reality: DR is not about mitigating risks; it’s about ensuring service continuity. We know failure can happen regardless of your risk profile, so strive for overall resiliency that will enable you to recover regardless of the specific risk or incidentMyth #3: DRPs are a separate entity from normal day-to-day operations.

Reality: Again, the goal of DR is to maintain service continuity, and that starts with day-to-day service management.

Myth #4: I use a co-lo so I don’t have to worry about DR. That’s my vendor’s responsibility.

Reality: You can’t assume your co-lo’s DR capability meets your needs or that DR services are part of your agreement. The same is true for cloud vendors.

Myth #5: A DRP must be so detailed that anyone can execute the recovery.

Reality: DR is not like an airplane disaster movie. You aren’t going to ask a business user to execute a system recovery, just like you wouldn’t want a passenger with no flying experience to land a plane.

Keeping in mind your audience – knowledgeable IT staff – you can take a more visual and concise approach to documentation, which ultimately makes it more usable, easier to maintain, and therefore more effective. Choose flowcharts over process guides, checklists over procedures, and diagrams over detailed descriptions.