What would happen to your business if a disaster were to strike? What would happen if your business were shut down for a day? For a week? For a month? At some point, if you can't do business, you'll be out of business. You can't always prevent disasters, but having a disaster-recovery plan (DRP) can prevent a disaster from ruining your business.
Also known as a business continuity plan, a DRP outlines the steps that need to be taken if an event occurs that stops your business sites from operating. The DRP helps your business continue to function.
Preparing your company to survive a shutdown isn't simple, but careful planning coupled with follow-through can turn a potentially business-ending event into a temporary interruption. The Gartner Group has said that 40 percent of business enterprises that experience disaster go out of business within five years of the event. If you want to be in the 60 percent of businesses that survive, you must have a DRP in place before a disaster and follow the plan if a disaster occurs. (Gartner has done many reports on disaster preparedness, which you can find at http://www.gartner.com/1_researchanalysis/focus/aftermath.html.)
The complexity of your disaster preparations depends on several factors, including the size of your business. In most cases, recovering a small business is easier than recovering a large business. But although a large business might require a more extensive or complex plan than a small business, all disaster-planning processes, regardless of the size of the business, should include the steps outlined in the sidebar "Disaster-Recovery Checklist".
A complete recovery plan includes technical, personnel, and facilities considerations. I walk through the IT aspects here, but remember, your plan must also adequately address crucial facilities and personnel requirements.
Put Together Your DRP Team
The first step in creating a DRP is putting together the planning team, typically a management team that determines
what needs to be in the DRP and designates who's responsible for each part of the plan. In a small business, the DRP
team might simply be the company owner and the IT person.
In a large corporation, the DRP team might be made up
of the department heads or division vice presidents. In all
businesses, the DRP team needs to include people who are
empowered to make key decisions and who know what data
and business processes need to be protected in the event of
a crisis.
In your DRP, you need to address budgetary, organizational, and business-process requirements, and the DRP team must agree on how to handle these requirements. The DRP team can delegate some responsibilities—for example, the team might assign certain steps to subordinates whose expertise covers what needs to be done—but it's crucial that DRP team members have authority to make the decisions necessary to implement the complete plan.
Evaluate Your Business Processes
After you have the DRP team in place, it's time to evaluate
your business processes and determine which business functions are "mission critical," which are "must-haves," which are
"nice to have," and those that aren't essential. First, identify
which business processes are needed for the business to
continue in a crisis. Then, determine the minimal technology
resources that your business needs to restore those processes.
Note that although disaster recovery is often expensive, even
in a small company, when the DRP team determines the
minimum requirements, you must be prepared to preserve
resources and not cut any resources below that minimum
level. There's little point to having a DRP that requires
redundant hardware and software systems if someone up the
corporate chain of command decides that sufficient money
or support isn't available for those resources.
When determining what equipment is needed for the recovery plan, you'll want to point out the investments that serve double duty. For example, you might determine that you need to have network servers in reserve, but you can't do much with that hardware while it waits to be used; if you put reserve servers into service, you increase the number of systems for which you need to provide redundant hardware. But you can maximize your investment. Although hardware such as online and offline data-protection systems are crucial to your DRP, you can also make them everyday parts of your IT process. Your recovery plan might, in this case, motivate the business to add additional capabilities and features beyond what you need for regular backup and recovery so that the expenditure towards the DRP is incremental. For example, you might add new generations of backup and recovery hardware, which improves day-to-day workflow and improves your disaster preparedness.
The DRP team also needs to decide what level of catastrophe the business is prepared to recover from. Your DRP might cover everything from a simple short-term telephony or networking outage to a full-blown Hurricane Katrina–level devastation of local public and private infrastructure. However, most plans commonly focus on catastrophes that are the most likely (fire, flood, weather problems). Be sure to specify the level of disaster your DRP addresses.
Detail the IT Aspects of Disaster RecoveryIn " Backup and Recovery Basics" (January 2007), we talked about your data backup and recovery plan. You'll want to include that data plan in your DRP. The data-recovery plan should, at a minimum, cover the basics of protecting your mission-critical (and valuable) corporate data. Note that some items that are optional in simple data-backup plans may become requirements in DRPs. For example, your backup and recovery plan will likely include the ability to restore servers if they crash. Perhaps you've even provided backup server hardware. But as part of a good DRP, you might want the ability to restore servers to nonidentical hardware, which would then require extra steps in the backup and restore process.
If your business is large enough, your DRP might include a plan for duplicate data centers, set up as redundant sites. If your business is large enough to have multiple data centers, you might want extra capability at each site to intervene should a data center become unavailable. In all cases, you need to be able to back up data offsite so that the loss of the primary location doesn't mean the end of your business.
Offsite data storage can range from the low end (an employee is responsible for taking the daily backup tapes to a secure offsite location) to the high end (sufficient network bandwidth is available to allow for real-time data replication to offsite storage). Internet-based backup and recovery systems can serve a dual purpose, providing regular backup and recovery services along with a reliable and secure offsite location for mission-critical corporate data.
Test and Implement the
Disaster-Recovery Plan
You've decided what aspects of your business to
protect and how you're going to protect them.
Now you're ready to test and implement the
DRP. This means documenting each DRP task,
outlining the order in which the tasks should be
carried out, designating the person responsible
for seeing each task is completed, specifying
who manages the entire DRP operation, and
testing the entire DRP.
After you roll out any additional hardware or software, you'll want to walk through the entire DRP, making sure that the planning documentation matches the actual recovery process. This is the time to make necessary changes to the plan or to the technology. Remember, as you make changes, you'll want to re-confirm previous steps to make sure that they still apply. Having a DRP is not a one-time event: You need to keep working through the DRP until you achieve repeatable, consistent results.
When you're certain that the DRP works and that the documentation accurately reflects the process, you're ready to have the DRP team approve the final version of the DRP. Then, you're ready to distribute the plan as appropriate, in whole or in part, to all affected parties. Also, be sure you have secure offsite storage for printed copies of the detailed DRP.
The Ongoing DRP Process
Even though you now have a DRP in place,
you've only just begun the disaster-recovery
process. Very few businesses are static, so as
business changes, your DRP will also change.
As with any business-critical activity, testing and
maintaining your DRP is an ongoing process.
As you add technology to your business, you
must determine how the new technology affects
the DRP, then change the DRP and associated
processes as necessary. Changes in the way you
do business can also affect the DRP, so be sure
that you alter the DRP to reflect any changes
to business workflow. Regularly evaluate your
plan—how often you evaluate depends on
how fast and how often the business changes.
Simply documenting changes is unlikely to be
sufficient. Your DRP should be tightly integrated
into your business model—any changes to the
business also mean that the DRP will change
and need to be updated and re-tested.
The job of the DRP planning team continues as well. The composition of the team may change somewhat after a functional DRP is in place, but the DRP team still needs to organize the management and maintenance of the DRP. Regularly scheduled DRP team meetings can give multiple departments the chance to interact and the opportunity to provide recommendations for current and future updates of the DRP and its processes. Continuing involvement with the DRP team also helps remind business staff of the ongoing importance of having an up-to-date disaster-recovery plan.
Various analysts studying disaster recovery have noted that nearly 50 percent of all large companies lack any sort of comprehensive DRP, with that number climbing closer to 80 percent when small businesses are included in the calculation (for more information, see http://www.gartner.com/1_researchanalysis/focus/aftermath.html). Every business, regardless of size, can benefit from having a DRP. Defining what needs to happen in the event of an emergency lets you gain some control over a crisis that might otherwise put you out of business. Implementing a DRP, even on a small scale, can make the difference between business survival and failure.
