While backup and recovery technology is an important survival practice for your company and has improved, business systems are increasingly complicated, and we rely on them more than ever. My framework of best practices for disaster recovery (DR) will improve the restoration of business services if an outage occurs:
1. Make DR an official business project
Business continuity plan updates and testing must be treated as a formal business project. Otherwise, it may get secondary treatment or even be postponed in favor of other critical business objectives. Even in difficult economic times, DR is important enough to ensure that you maintain testing and updates to the plan.
2. Formally organize a DR team
Plans require people and it is critical that you formally secure resources for disaster recovery operations. Organize your DR team, hold periodic meetings and stay focused on its critical role. DR is usually a part-time assignment of the employee, but formal job objectives and resource commitments can help secure participation. A formal plan ensures that you properly budget for people, technical resources and travel expenses.
3. Invite business participation
A technology-only DR approach is ineffective. The strategic business
4. Support education and training
Disaster recovery planners must continually evaluate new technologies and approaches for using it. Emerging technologies like cloud computing or Windows 7 are new challenges in 2010, and new methods of backup might even include looking at Carbonite or similar services for remote users. It's important to invest in training the DR leader and team, thereby creating the most cost-effective and protective scenarios.
5. Test the plan
A former manager once stated that "anyone can take a backup, but can they recover?" Formal testing of mock disasters is one of the most worthwhile evaluations possible for a disaster recovery plan. Our auditors would even periodically declare simulated disasters, where we performed on-site recovery in a lab to save expenses. The goal is to evaluate the business recovery plan as thoroughly as possible, so that it's successful when Murphy's Law does occur. Don't let higher priority projects put DR testing on the shelf.
6. Involve the entire DR team
While budgets and resources are tight as our nation's economy recovers, it's important to involve users and the business during recovery tests. It should not be a technical exercise only. Team participation provides valuable experience and training. It also facilitates differing perspectives that will improve the plan.
7. Sample different applications
It's always important to recover the most critical application, but other business systems should be rotated into quarterly or annual test cycles as part of the plan. Random selections help ensure that your team is adhering to documentation standards as application maintenance occurs.
8. Maintain security
The business of evaluating security controls is sometimes neglected in the testing process. During recovery testing, all security controls must be carefully reviewed to ensure sensitive customer data would not be compromised during a real recovery. For example, a weakly secured wireless LAN may allow important customer information to leak out.
9. Formally document DR tests
Using a lessons learned approach, document all findings for each test. Look for specific areas of improvement for the application tested. Also evaluate general areas for improvement in the disaster recovery process itself.
10. Exercise continuous improvement
The DR process will only be as good as the plan and its supporting documentation. Standards for change management must include updating DR considerations as applications change. The technical foundation for IT systems is constantly changing and new technologies must be addressed, e.g., cloud computing.
Harry Waldron, CPCU has worked in the IT profession for over 35 years. A Microsoft MVP, he works as a senior developer for Fairfax Information Technology Services in Roanoke, VA, where he provides technical, business and leadership support on key development projects. He writes about security and best practices for several technical forums, including myITforum.com. He has earned 10 professional designations in technology, business, and insurance fields.
This was first published in January 2010