On Sept. 10 I published a column discussing the benefits of having a business-continuity/disaster-recovery plan...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
in place. In the article I described several disasters that had occurred throughout the years, specifically the 1993 bombing of the World Trade Center. In a twist of irony, the next day -- Sept. 11 -- the World Trade Center was again the focus of attacks. It drove home the fact that disaster can strike at any moment, and companies need to have plans in place to handle them.
In this tip, I'll discuss the requirements for developing a business-continuity plan (BCP) and a disaster-recovery plan (DRP). A BCP, by definition, is an all-encompassing, "umbrella" term covering both disaster recovery planning and business resumption planning. A DRP, on the other hand, is a document that defines the resources, actions, tasks and data required to manage the business recovery process in the event of a business interruption. The plan is designed to assist in restoring the business process within the stated disaster recovery goals.
The actual steps for creating these documents are too lengthy to cover in just one tip, but here are the basic procedures you need to follow:
1. Obtain management approval. Without approval from upper management, the project will be stranded before it even gets of the ground.
2. Put together a committee. This committee should include representatives from the various departments in your organization. The main goal of the committee is to define the scope of the BCP and DRP.
3. Perform a Business Impact Analysis/Risk Assessment. A key component required is to determine what types of disasters can affect your system. This assessment should determine the type of risk (i.e., natural or manual disasters) and the effects these disasters would have on your operations.
4. Identify the key processes/IT systems. Critical processes (i.e., payroll or accounts receivable) as well as critical IT systems (e-mail or Web servers) should be identified. That is, the committee should determine what are the critical components of the organization that should be protected (and recovered quickly) in the event of a disaster. Remember, however, that the main purpose of the DRP is to protect lives.
5. Determine recovery methods. There are several options available. Critical business processes that use IT systems could perhaps be done manually. When it comes to the recovery of IT systems, options include hot sites, warm sites, cold sites, reciprocal agreements and service centers.
6. Document the plan. The DRP, for instance, should contain procedures for system recovery. The plan should include important contact information such as critical call list (vendors, employees, emergency agencies, etc.), as well as any other pertinent and critical documentation.
7. Test the plan. It is not wise to wait until an actual disaster to see if a plan works. The plan should be tested periodically (at least once a year), and any problems found in the test should be corrected and the plan modified accordingly. The plan should also be updated when new critical business processes and/or IT systems are introduced.
8. Approve the plan. Once the plan is tested, management should then approve it. Management will be responsible for disseminating the plan to the various departments, establishing policies for its use, and most of all, making sure the plans meet with the strategic objectives of the company.
This list just skims the surface. The work involved can sometimes be tedious. And as much as you try to plan for every possible disaster, there will always be something overlooked. Do not despair. The business-continuity/disaster-recovery plans are living documents that will change as your business changes. Hopefully, you will never have to put the plan into place. But if disaster strikes, at least you will be prepared and will have the ability to resume business operations quickly and effectively.About the author
Mark Edmead, CISSP, has more than 22 years of experience in software development, product development and network systems security. He is co-author of the book Windows NT: Performance, Monitoring and Tuning published by McMillan Press. In addition, he has written numerous articles for technical publications and is currently writing a book on Internet security certifications.