There are many items that are required in IT disaster recovery (DR) plans -- some are location-specific but some are more generic. This article will discuss the top 10 items critical for the success of
1. Disaster recovery plans must have an accurate communication or call list. Communicating with other employees is essential during a disaster. Some organizations use third-party vendor products such as Everbridge Inc. or MIR3 Inc. for this. Regardless of how you generate your call list, the list must be current. The list should have designated backups for each key individual and multiple contact information for them as well. If you are using a call tree, make sure that you have a loop back so that the last person on the list will confirm that the call was made. Also, someone should be designated as the communication list manager to monitor responses and contact backup staff as necessary.
2. Work off of a detailed script during a disaster. When you are in recovery mode, many things occur at the same time, and confusion is a given. In order to make the disaster recovery process easier, have a detailed script or step-by-step instructions in your DR plan. The script should be formally reviewed by several different members of the DR team. And since there is no guarantee that the script will be followed by the same person who wrote it, it's best to use a simple bulleted list with easy-to-follow steps. When in a real recovery scenario, there will be intense pressure and many things going on at the same time. Also, a disaster can occur at any time, so if the plan is executed late at night, confusion is likely to be high. Whatever can be done in the plan to make the steps easier to follow will go a long way. If at all possible, try to anticipate errors and include remediation steps. An example bulleted point can be as follows: "Connect network cable to PC. If network not found, first check if PC Ethernet connection shows signal." Straightforward and simple instructions go a long way when you are under extreme stress and fatigue. Avoid using terms that may not be understood when extreme fatigue hits. If you must use technical terms that may not be understood, add a glossary of terms.
3. Test and retest the detailed disaster recovery plan. It is possible to test separate portions of the DR plan on their own, but make sure the whole plan is tested at least once a year or if a major change takes place. If you exercise or test the DR plan at least once a quarter, then the staff will become more familiar with the plan. And to make it more effective, try to exercise the plan with different staff members if you can. When testing the DR plan, don't assume that everything will go according to plan -- this is why it's important to test. Always anticipate unusual conditions. For example, you must come up with solutions for unexpected events, i.e. what would the team do if a drive or a technical component fails?
4. Each member of the team should be familiar with their defined role. Additionally, the backup members must be familiar with their roles. If a team member whose primary role is applications has a backup role as a telecommunications resource, make sure they know what that role entails.
5. Have a list of 24-hour supply delivery resources and restaurants at the recovery site. This next item may sound odd as a "must have," but it is of utmost importance sometimes. You will likely spend many hours at a recovery site and will need to replenish supplies. You do not want to start searching for places when every minute and resource counts. You may very well need to be at the recovery site for longer than 24 hours at a time. Also, be sure you know where the nearest hardware and office-supply stores are at your recovery site.
6. Include an application list in the DR plan. An application list is any software package or system that will be part of the recovery, and it should always appear in a master list. Each entry in the list should have the application name as the technical staff identifies it, the name the business side recognizes and any technical details such as server name, etc. Along with the technical items, include the application owner, their full contact information and backup contacts.
7. Include a current network diagram of the entire network and recovery site in the DR plan. Each node on the switch and panels should have some means of identification. In a recovery, you do not want to start following cables and wires through switches, etc.
8. The DR plan should contain an easy-to-follow map and directions of how to reach the recovery site. Do not assume everyone knows how to get to the recovery site. Secondary directions should be provided too in case the main route is congested or impassable. Also, include available parking facilities.
9. Include additional documentation such as a list of vendor contacts and insurance documentation such as policy numbers. These items as well as a list of all the hardware and software licenses you may have are helpful to have in a disaster recovery plan.
10. The disaster recovery plan must be current. The most critical issue regarding a disaster recovery plan is that it is current and that a backup copy exists at the recovery site. You do not want to go through a recovery process with an outdated plan. In order to avoid this, update the plan at least once a year, or whenever modifications are made that require a change in the disaster recovery plan. These changes can be in hardware, software upgrades virtualized servers, or any change that would modify the current disaster recovery environment.
Additional best practices for IT disaster recovery plans
Some final IT disaster recovery plan best practices include making sure the plan is clearly laid out and easy to follow. Keep in mind that there's no need to make it too lengthy or complex. The DR plan should be concise with easy-to-follow bullet points.
Also, keep in mind that there may be circumstances that do not allow the plan's author to be present during the recovery period. Disaster recovery plans should be written so that someone with a similar skill level can accurately follow all steps in the plan. Knowing this, the author should omit any shorthand or technical jargon from the instructions. It is important to realize that DR plans will probably be exercised under extreme conditions of stress and timing. When reviewing and editing the plan, ask yourself if the plan is simple and concise enough to follow under stressful and tiring situations.
About this author: Harvey Betan is a certified business continuity planning consultant with experience in disaster recovery in both technology and business functions. He migrated to BC after the restoration of a large insurance company with a major presence in the World Trade Center on Sept. 11. His career has spanned a dozen years in business continuity after a 15-year career as a senior manager in information technology for the financial, insurance and nonprofit sectors.
This was first published in April 2010