The RUsecure policy document has some details on Business Continuity Planning (BCP). BCP breaks down into the following six key areas:
- Initiating the BCP project Any BCP project needs to be formally approved by the company's board of directors. Without sanction and backing from the highest echelons, any BCP plan can result in inadequate preparation.
- Assessing BCP security risks BCP ensures that in the event of a disaster key business services can continue to function. You need to analyse the specific risks that may affect you as well as their likelihood and the degree of impact.
- Developing the BCP You need to create a detailed plan to deal with the risks that you have identified. Since you can rarely afford to reduce all risks, you need to prioritise them and base your plan on those priorities. The priorities will vary greatly, depending on the specific nature of your business. The BCP will contain the specific steps you would take in the event of a disaster, thus it is likely that the BCP will be complex and detailed.
- Testing the BCP Your BCP plan is a great starting point, but you need to test it in advance. Testing both assesses the viability of your BCP and also ensures your staff are capable of operating the plan.
- Training and staff awareness on BCP For a BCP plan to operate at all, your staff have to be made aware of it and be able to operate it when necessary. As the RUsecure document pointedly notes: Even a BCP that is tested can fail if personnel are insufficiently familiar with its contents.
- Maintaining and updating the BCP You need to keep your BCP relevant to your current situation. There is no point in having plans covering buildings or companies you no longer own, for example.
In most cases, the BCP will cover ground that is outside the IT group's remit. Thus the IT group will play a key role in BCP planning, but may not own the process of developing the plan.
Plans, as they say, work well until you put them into action. But, as any good manager knows, plans need to be tested against reality - and refined accordingly. The big issue here is that activating a disaster recovery plan, and actually moving your operations between a primary and backup site, is both a potentially expensive and a possibly dangerous thing to do.
Without testing, you'll never know if your plan will stand up and deliver. Full-scale testing can be carried out, but it has to be planned very, very carefully. Test each component of your overall plan in isolation and then slowly build up to a full-scale test.
As you design your systems, you should include recoverability and security from the start. Where possible you should be designing systems that are easy to replicate - both from a scalability and a recoverability point of view. You should ensure that your systems are dispersed and that all single points of failure are identified and, if possible, eliminated.
During the design of your applications and your infrastructure, you should be performing a detailed risk analysis of the system. The identified risks can then be managed and controlled. If you can't avoid the risks, you might at least be able to minimise their effects.
Reproduced with the kind permission of Just from Enterprise Server Magazine (ESM), July 2003. ESM is the only magazine independently owned and produced in the UK that specialises in Windows and Enterprise Server computing.