This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

Plan by Steps

15 February 2007

Writing a business continuity plan on a blank piece of paper is almost impossible to get right. Steven Garrod takes a step by step approach to developing a business continuity plan from analysis of risks to maintaining the plan

THE WORK OF WRITING A PLAN SHOULD START way back with thinking about the risks faced by your business and the scope and scale of any impacts that may result. If you don't have a clear idea of what you are trying to protect - and what you are trying to protect it from - how can you know what to put in the plan and what to leave out?

The key to getting this right is to follow a very simple, sequential process, like the one illustrated.

This is not the only model for implementing effective business continuity management, it may not even be the best, but it is amongst the simplest. And for those of you just starting out, I feel this is important; you can always refine it and make it more sophisticated later if you want to. Taking this model step-by-step.

Many organisations have good risk management processes, but not all. At its simplest, you should identify the risks facing your business. Think about physical things like the local environment, buildings and services, infrastructure and IT. Consider also some of the softer risks like loss of information, failure of a supplier, dependencies on key staff and critical deadlines. Having identified the sources of risk, evaluate them, and then prioritise and manage accordingly. Some risks may be too expensive or impossible to mitigate and this is often where insurance comes in.

There may be hundreds of risks facing your business, but the ones you should be most interested in are those that will have a huge impact. Consider, function by function, both the financial impact (lost revenue, cash flow, contract penalties) and the operational impact (on your customers, on your reputation, on management control) of a disruption to your business. Use this information to decide which functions are most critical in the first few days following a disruption and identify the inimum level of resources (people, equipment, systems) needed to keep them working. This step is often referred to as the Business Impact Analysis (BIA).

Using the information from the risk assessment and the business impact analysis, consider the options for increasing your resilience to the key risks you face and also for developing a response/recovery capability. For example, you could make a function more resilient to a disruption affecting one location by splitting it across two locations or by cross-training staff in another area. Resilience to network failure can be increased by implementing dual-routing or using two providers.

In terms of response/recovery, in the event of a building-related disruption you may decide to move people to an alternative location, either one of your own or one provided by someone else. In response to IT failure, you may decide to purchase new servers and rebuild/restore at the time. If you can't wait that long, you may decide to contract out for specialist IT disaster recovery services. The important thing is that you document your preferred strategy and implement it.

Finally, we've reached it. The plan should simply set out in a clear logical order what your (or your colleagues) will do in the immediate aftermath of a disruption. I suggest that at the front of the plan you list the things to be done first - together with the name or role of the person doing them - sometimes referred to as 'initial response actions'. Next, list those tasks necessary to invoke your agreed recovery strategy and, at the back of the plan, include any supporting information that would be helpful at the time of an incident (names, contact numbers, location maps, checklists, etc). Remember that it should be an action-orientated document, not a management report; keep background material and introductions to a minimum.

Having implemented your response/recovery arrangements and written a plan that ensures they can be invoked successfully, it make a great deal of sense to prove that they will work. One of the simplest exercises to perform is a tabletop walkthrough; bring together the various members of your response/recovery teams - with their plans - and talk through a potential scenario. This kind of event will drive out most errors, omissions and false assumptions that exist. It also provides something tangible to what some people consider a very dry, abstract subject. In addition, of course there are 'real' things that can be tested: restoring back-up tapes, connecting to remote servers, switching telephone lines, trying out manual workarounds and so on.

By this point, you will have invested time and money in developing proven business continuity arrangements. It is important that this investment does not decay over time simply through neglect. Implement a simple maintenance routine, perhaps in conjunction with your internal audit team, to ensure that once every three to six months or so, each team meets to review their plan and check that nothing has changed. If it has, update the strategy and/or the plans and re-issue.

Eventually, you may need to go back to the beginning and re-assess your risks and check the business impacts. For some fast-moving businesses, this might be an annual event, while for others once every two to three years may suffice. You will be able to define this as part of your maintenance process. And there we have it: A very simple process that will take your business through the various stages of the business continuity lifecycle. This should ensure that you engage your colleagues at each stage in the process and avoid the common pitfall of writing a plan in isolation; a plan that few will use and even fewer will understand. I believe it was Eisenhower who said "plans are nothing; planning is everything". I think he was right!

....Steve Garron is a consultant at Garrison Continuity which will be exhibiting at Business Continuity - The Risk Management Expo 2007 at London's Excel, Docklands from 28th-29th March 2007.

Print this page | E-mail this page