business continuity plans

Taking a step back here it's essential that your efforts align with the continuity plans of the business. If the business continuity plans are such that for business interruption scenario A they need to recover business process B in timeframe C, then then your plans needs to ensure that the IT systems they require to achieve that are recovered accordingly.

Frameworks such as ITIL and ISO20000 give you an overall approach for continuity management, e.g.

Step 1: Initiation - what is your scope, what is the organisation policy, initiate a project (this is a substantial effort so plan, resource and fund accordingly)

Step 2: Requirements & Strategy - business impact (of loss of service) assessment, risk assessment (assessment of threats and extent of vulnerability) and from that determining your service continuity strategy.

Step 3: Implementation - develop your plans (what you're going to do), your procedures (how you're going to do it), organisational planning and testing

Step 4: Operations (ongoing assurance) - through communication, education/awareness, change mgmt (when systems change, do the DR plans need to change to?), periodic testing and audit/verification.

I've skimmed at 50,000 feet here but there are plenty of resources available to help you drill into as much detail as you require.

Curtis, preparing for a disaster must start with a comprehensive Disaster Recovery plan that is agreed to by all stakeholders. Phil is on target with his comment that the plan must start with the business goals, specifically the business continuity plan if one exists. I also agree with his approach.

A challenge I have often come up against is that the business sometimes (often in smaller companies) has neither plan in place. If that is your situation, I would recommend that the IT organization take the lead on defining the business requirements, which means discussions with the various business leaders to understand their requirements and using those to drive the plan. This is an iterative process. The first initial expectation will often be instantaneous application failover and no data loss. Once the business understands the cost of such an implementation, more serious discussions can take place. Some observations from past efforts I have been involved in:

The plan must clearly define the criteria for declaring a disaster as well as the governance aspects, who can declare, who gets notified, etc. This plan must be communicated to all stakeholders

Many requirements are driven by regulatory requirements, especially in industries such as Financial Services and Healthcare

The DR implementation typically does not support the entire staff, but the more critical subset of staff that is needed to keep the business running until the disaster is addressed. This may be a few people in each department

The DR technical implementation is often smaller than the primary environment and may be a virtualized version set up (loaded) at the point of the disaster. I have often seen a Development or QA environment “repurposed” during a disaster to become the Disaster Recovery platform.

Connectivity becomes a major component of a successful plan. There will likely be a disaster site which houses some number of the most critical staff (such as traders in a Financial Services firm) and then support for staff to connect remotely from home or other location

Data replication becomes one of the most important and often challenging parts of the plan. The Recovery Point for a DR fail-over essentially deals with how much data can be lost when the systems swing to the DR site. This can be “no-data-loss” to substantial and will be different for each application.

Location of the DR site is of major importance – far enough from the primary site to ensure it is not impacted by the event that causes the disaster and close enough to the company’s IT staff to allow it to be managed. Use of colo facilities can help manage this particular issue

If the company has multiple locations, paired data centers can be considered. In other words multiple primary data centers that are used to back up each other.

Don’t forget to consider the fail-back portion of the plan. This is non-trivial and includes both the criteria for fail-back as well as the methodology for replicating new data back from the DR site to the primary site.

Also, don’t forget the office communications technologies, namely phones and fax machines. Some number of these will need to be redirected to alternate numbers.

Finally – test, test, test! Once the entire environment is set up there should be an actual DR test at least twice pre year. This semi-annual test should include the business folks. When changes are made to the primary environment, those changes should be reflected in the DR implementation and tested (separate test from the semi-annual test)

There are some good sample Disaster Recovery plans available on the Internet. These can be used as a framework from which you can build your plan.

Hope this helps.