10 Steps to Assess Your Disaster Recovery Plan

After you have created an effective recovery strategy, the ability to execute that strategy is of primary importance. Along with training and testing, the documentation and procedures required to perform a practical and usable technical recovery are essential. You may not think it is necessary, but a Disaster Recovery plan that facilitates an actual recovery (and not just some documentation no one is likely to use) is a major component to overall recovery capability and cannot be ignored.

In fourteen years of reviewing the best and the absolute worst of business recovery plans, we have seen it all.  This includes plans that do not a logical format, recovery strategies that do not work, no listing of what business processes are being recovered, lacking identification of requirements for recovery, vague or missing recovery steps, contact information that is outdated, etc. 

Is your recovery plan capable of recovering your business unit?  Today, we’ll take you through 10 ways to assess your plan and also include how to test it. Assess the plan using the following ten steps:

1. Does the Plan Follow a Standardized, Logical Format? Is there organization and logic to your recovery plan? Do the table of contents take you down a logical path from activating the plan, assembling the team, assessing the event, implementing recovery steps, etc.? We don’t need a 300 page document detailing, but, we still need a standardized format that provides the guidelines to a logical path of recovery.

2. Is A Recovery Team Leader And Team dentified? Who is in charge of the recovery? Each recovery plan must have a Recovery Team Leader and members identified who are responsible for plan development, maintenance, and most importantly, execution in an unplanned disruption.

3. Does the Plan Identify the Critical Business Processes that Need to Be Recovered and their Recovery Timeframes? To be effective, we must know exactly what processes we are attempting to recover, in what timeframe they must be recovered and what computer applications they depend on. If you don’t know, thats not a good sign.

4. Is the Plan Event Neutral? – You can’t write a plan for every possible scenario out there. A good plan strives to be “Event Neutral” and address scenarios such as be as Loss of Building, Loss of Telecommunications, Loss of Data Communications, Loss of Resources and Loss of Other Channels. Whatever the event was that occurred does not matter, how we deal with the impact is what is important.

5. Are the Recovery Strategies Real? – Lets be honest here. Hope is not a strategy. In today’s business world, if you need to recover your business functions in 72 hours or less you better have a pre-established, in place alternate recovery strategy (e.g., alternate site, backup phone system, etc.) that has demonstrated capability. Stating you will identify and implement a strategy at time of event is no longer a valid option if you need to be recovered within a short timeframe.

6. Do the Recovery Steps Make Sense and Will They Work? – Recovery steps do not need to be exhaustive in nature but should provide a comprehensive list of steps that outline to recover the business process.

7. Are Critical Contact Lists Comprehensive and Up to Date? Are the contact lists comprehensive in nature (e.g., recovery team members, associates, key vendors, etc.) and have up to date information.

8. Do Recovery Team Members Have Access to the Recovery Plan 24×7? The Recovery Team Leader and Members must have access to the plan at work, home and anywhere else they may be during a disaster. Plan should be in all formats possible (e.g., hardcopy, electronic, etc.).

9. Has the Plan Been Exercised Regularly? Its simple, if your plan has not been exercised, you have less than a 50-50 chance of a successful recovery. If you regularly exercise the team and plan you significantly raise the potential for success.

10. Does Senior Management Sign Off on the Plan? A good plan will have senior management review and sign off annually. This ensures an upper management executive is personally responsible for the plan, its content, regular exercising and update.

Many organizations consolidate their disaster recovery and security recovery plans into one package without asking if this approach makes sense. IT security and disaster recovery plans are related but they are not the same, and at MHA Consulting, we advise against combining them.

How Disaster Recovery and Security Recovery Plans  Differ

DR and IT security recovery plans appear to be very similar. Both plans include procedures to minimize the impact of an event. They also have procedures to recover from the event and return to production, and will likely have a process to minimize the possibility of a similar event occurring again. Yet, beyond that, disaster recovery and IT security recovery plans are fundamentally different.

The core difference between these plans is that disaster recovery is about business continuity, while IT security is about information protection. Therefore, disaster recovery plans tend to be actionable while security plans tend to be more validation and configuration driven. Part of the disaster recovery tasks performed to make applications or environments available include the necessary security architecture and settings that might also be found in an IT security recovery plan.

Security plans include the items to be validated and ensure these are in place and functional. Security testing to restore functionality related to data breaches or cyber-attacks may not require a disaster recovery environment. You can do penetration testing and access segregation in a production environment. The security component of DR testing ( i.e., are the recovered systems in compliance with an organization’s security policies) is part of your DR testing.

Why Separating Your Plans Makes More Sense

While an all-in-one approach can seem like a more convenient solution, consolidated plans tend to not have as much detail or get too unwieldy in size.

Another reason to separate your plans: stealth. DR and IT security plans contain specific security and non-security (infrastructure or application) tasks. By nature, business continuity and DR plans contain more public-facing information, while security recovery often calls for a more closed-off investigation and analysis. There is sensitive information you may not want to have people from other areas see.

Using separate plans (or documents) makes it easier to use during testing or in a real event. Testing is critical to the success of each plan. Separate plans make it easier for the individuals performing the tasks to identify and find the appropriate actions and sections faster with less extraneous information. This includes not only security, but infrastructure, network and applications.

Managing and Updating Your Disaster Recovery and Security Recovery Plans

Security and disaster recovery plans are managed and maintained by different teams. Disaster recovery plans have multiple sections and associated components similar to the IT security plan, but they also have many components that need the attention of different departments. The complexity of each plan and its content should be managed and performed by the appropriate team – information security, infrastructure, and application.

Management includes updating. Consolidated plans are often more difficult to maintain. Why? Information gets misplaced and it can be difficult to locate. This brings on unnecessary complications because you should update the information in all plans, no matter their purpose, on a regularly scheduled basis. In today’s volatile security environment, you may need to ensure that the security plan and strategy are reviewed more frequently as the risk probability for certain events may change. However, non-security related changes in the IT environment change even more often; so to ensure proper functional recovery, all plans should be updated as changes occur. DR plans and strategies should be an integral part of the change management process.

Take a look at the primary objective of your disaster recovery and IT security recovery plans. A disaster recovery plan is created to give an organization business continuity after a disaster. You design your IT security recovery plan to protect your assets after a breach. Two plans with varied objectives should not be combined together. If not separated, the effectiveness of response and overall plan management will suffer. As your organization matures, it should have developed a more nuanced approach to each plan.

Disaster Recovery Plan Testing

Exercise and testing can consist of talking through recovery actions or physically recovering things. Testing can be discussion-based or operations-based. There are several different kinds of testing each categorized by their complexity involving set-up and number of participants needed.

• Standalone Testing – the person who authored the plan reviews it with someone that has a similar technical background (i.e. manager, backup support, etc.) It is useful for catching omissions in the plan and can also provide insight into the process for the backup support person.
• Integrated System Testing – occurs when all components of an IT system are recovered from scratch. This type of testing can reveal many of the interfaces between IT systems required to recover a specific IT function.
• Table-Top Exercises – these simulate a disaster but the response to it is conducted in a conference room. A disaster scenario is provided and participants work through the problem. Similar to walk-through testing except the team responds to an incident scenario.
• Simulation Exercises – requires taking a table-top exercise one step further and includes the actual recovery site and equipment. A simulation is the closest that a company can come to experiencing (and learning from) a real disaster. Simulations provide numerous dimensions that most recovery plan tests never explore. They are time-consuming and expensive to conduct.

Further Reading on Disaster Recovery Planning

For more information on disaster recovery, learning disaster recovery, and other hot topics in business continuity, check out the following recent posts from MHA Consulting and BCMMETRICS:

• The Cost of Calamity: How Being Unprepared Can Harm An Organization
• The Plan that Time Forgot: The Importance of Protecting Your Business Processes
• What to Include in Your Crisis Management Plan
• After the Smoke Clears: 7 Things to Do Once an Emergency Is Over
• 8 Bad Things: The Most Common Business Continuity Threats
• As Easy as 1-2-3: How to Launch a Business Continuity Program