The ten most common mistakes people make when writing business continuity plans. By Charlie Maclean-Bristol.
With the New Year, one of your many resolutions after losing weight, drinking less and joining a gym might be to improve your business continuity plans. I thought I might share with you the ten most common mistakes I find in plans that I am asked to review:
1. Compliance with BS25999
Many of you may not be going for the BS25999 standard or even aligning with it but, if you are writing a plan, you should at least comply with the items the standard says should be in a plan. With Part Two of the standard you only have to comply with just over a page of items. If the standard says that in the plan there should be ‘a method by which each plan is invoked’ make sure that there is a section on this in your plan. I have seen lots of business continuity plans where large chunks of what should be present are left out.
Resolution – make sure all the items in Section 4.3 of Part Two of BS25999 are covered in your plan.
2. Connect to the BIA
Business continuity managers spend ages on their BIA gathering lots of detail and perfecting it. Then, when the business continuity plan is finished, there appears to be no relationship between the two. All of the conclusions reached in the evolution of the BIA and development of the strategy get lost before getting into the plan. The plan should be the tip of the iceberg; it contains 10 percent of the information. The other 90 percent is developed and produced as part of the business continuity lifecycle which informs the development of plans.
Resolution – make sure the BIA information is reflected in the business continuity plan.
This often happens to organizations that go for a standard plan template and occurs when someone has produced a reasonable plan template which is then copied by others. The issue is that it is almost impossible to distinguish between the different plans in the organization. They are almost all identical apart from minor details such as recovery numbers and the name on the front. It is fine to use a standard template and even some standard paragraphs, but ensure that some thought has gone into the plan: bespoking it to the organization.
Resolution – ensure that your plans are written for the organization and tailored to its requirements.
4. Telephone numbers
Almost all plans will contain names and telephone numbers. Often these are to be found at the heart of the plan or in an appendix at the back. Usually they are out of date because of a turnover of people or because people have not updated their plan. Numbers should never be in the middle of the plan as they are difficult to update without printing a whole new document. This either uses up vast amounts of paper or people just don’t bother to do it. If the numbers have to be in the plan put them as the final appendix and then it is easy to replace. Better still, many organizations already have telephone lists, updated by admin people, for operational reasons. Find out if these lists exist and then cross reference then in the plan and let someone else keep them up to date!
Resolution – review the best way to hold your telephone numbers.
5. Names in plans
As with telephone numbers the second most likely thing to be out of date in your plan are people’s names. Plans, I believe, should never contain actual names because as soon as the plan is published someone will move or leave and the plan is out of date. Use job titles as they change less often than the personnel who fill them.
Resolution – change all the names in your plans for job titles.
There is nothing wrong with a plan 5cm thick if it is dealing with a highly complex and technical recovery. A plan for a 10 person department is unlikely to need to be as detailed. A plan’s bulk should be commensurate with the complexity of the recovery and the organization being recovered.
Resolution – if your plan is too fat, slim it down.
7. Quality assurance
QA is essential to making sure that you have an up to date version of the plan. Too many plans make a half hearted attempt at quality assurance. Good practice is to give details of the following:
a. Amendments (Version, Date, Author, Description, Status)
b. Assigned personnel (Authoriser, Reviewer, Author)
c. Review / Approval (Version, Date, Approved by, Comment)
d. Date of next review (Date, Responsible person)
e. Distribution list (Copy number, Job title, Method of distribution)
Resolution – review your QA details, are they adequate?
If your plan is going to be used on the day of an incident then ensure that there is a flow to the plan. Too many plans have information in no logical sequence. Keep all the background information together at the back or the front, if it needs to be in the plan at all. Have invocation at the front and long term recovery at the back and ensure that all the information is in a logical sequence.
Resolution – work through each section of your plan to ensure it is in sequence.
9. How to do it
Too many plans lack essential detail which on the day could thwart or delay the recovery. If your plan requires the invocation of a recovery centre then put in the essential details, such as the telephone number to call, your reference number, what information is required and who is on the list to invoke the plan. Only by getting to this detail can you ensure that something as critical as invoking a recovery centre can be carried out.
Resolution – get someone who doesn’t know your plan to read through it and point out any detail or information they would need to implement the plan.
10. It’s the planning stupid
The plan is a useful document for reminding you of what is meant to happen in responding to an incident. A lot more important is the thought that has gone into developing the plan. This planning work is often short-circuited by people ‘just wanting a plan’. Plans can look beautiful but if they are planning for recovering the wrong things or they wouldn’t work on the day, the plan is a waste of time, effort and paper.
Resolution – review to see if you are really satisfied with your plans and that sufficient thought has gone into it.
Author: Charlie Maclean-Bristol is director of PlanB Consulting and head of training at Business Continuity Training Ltd. www.b-c-training.co.uk
MAKE A COMMENT / ADD NEW ITEMS TO THIS LIST
From experience of having to invoke a plan after an incident and now helping organizations write theirs, it is essential to have the relevant names included in the plan (whether it be e.g. as a press contact or security company), and a call tree for all staff relating to the particular plan also included. Staff will take an interest in a plan if they feel included in it. Any plan which is 5cm thick should be available online for staff to refer to their own team pages and have an automated cross reference provided by the software for any other relevant information required. The paper copy should be a back up reference only when no networked online version is available externally (although this should no longer happen). As every member of staff should be familiar with the plan and their role (and those of colleagues) in relation to the plan, the plan itself should be in as simple a format as possible to allow all levels of staff access to it and to familiarise themselves with it easily on at least a six monthly basis.
We now recommend that two members of staff have responsibility for updating names/numbers in the plan and ensure all new staff read the plan on joining an organization. Where the plan is held as part of a software package then it is simple to have all new starts/leavers amended daily if need be.
We also recommend that the plan and call tree are tested at least six monthly and the call tree copied to staff quarterly in a small office/organization or monthly in a large organization.
In light of the recent snow episodes we are now recommending that testing of call tress and plan reviews are undertaken in the autumn (UK) as a minimum. We are asking our clients to review each incident (might just be snow/absences) and update plan with lessons learned. This is already having positive results in view of the snow 2009/10 as well as staff chosen to hold responsibility for the plans being allowed to increase their company involvement, raise initiative, staff development and no longer have BCP as a tick box exercise and the plan filed in a drawer.
Also raising awareness of insurance cost savings are raising awareness of the importance of the plan. Business continuity planning used to be considered a means to an end, but experience is showing us that it can lead to so much more... and operational risk issues can be raised/targeted so much more meaningfully.
Director - Ortaz Associates Ltd
While I agree that names and phone numbers change most often, I also find that if the specific names are NOT included in the plans, those specific people do not read the plans nor do they engage with them, and every employee needs to engage with his or her plan. Therefore it is not a good idea, in my opinion, not to include specific names. I used to counsel using roles rather than specific names until my experience taught me otherwise.
If the names change often, then the plans should be reviewed and updated with a reasonable time interval (monthly or quarterly, depending on the criticality of the function). Some plans may need to be updated WHENEVER a name changes – such as critical emergency management & response teams, emergency communications teams, etc.
We all need to remember that plans exist to be used when needed and not to minimize update work. This task is easier if you have many plans (one for each team or business function) and the individual team leader is responsible for updating the plan when there are changes. Ginormous integrated plans with everyone’s information all together are cumbersome to use under emergency conditions and considerably less useful than the detailed team plans for actually doing what needs to be done. And there are very few people who actually need all of the information…
Kathleen Lucey, FBCI
New York City
It seems that everyone has forgotten the most important item.
Do not forget WHO the audience is.
Know the specific audience each plan is being written for. Remember, the plan is not being written for continuity professionals, but people who only will view the plan from their business perspective.
It is not a lecture or training in doing continuity planning. It is the plan.
Philip Oppenheim, CBCP, International Continuity Oversight Board, Chairman
Regarding Charlie Maclean-Bristol's article, point 6 ‘Thickness’, I don’t agree with having a 5cm thick plan at all, having plans that are 5cm thick I have found become unmanageable. The BC plan should be effective, manageable, and to the point.
My approach is to split off the plans, e.g separate the technical recovery, which probably will have a lot of ‘keystroke’ information that the BC manager doesn’t need to have this in the overall plan. Better to create a ‘suite’ of plans, incorporating technical recovery plans and departmental BC plans, that the BC manager can manage and delegate to appropriate staff if they need updating…
As far as Point 8: ‘Flow’. A simple desktop walkthrough exercise with all BC participants should solve the flow problem; followed by a company-wide exercise to validate the flow.
Michael Mitchell, Senior Consultant: BCP, DRP, Votar Partners Pty Ltd
I think point 10 should be ‘Remember to test it, stupid!’. I have seen too many plans that have never been used either in anger or for testing. Best way to keep a plan up to date and fit for purpose is to use it.
Noel Carey, MBCI, business continuity and resiliency consultant, IBM Global Technology Services
Further to Charlie Maclean-Bristol's article, I would add the need for strong governance as part of the BC planning process to validate the outputs of the BIA. Too often we see examples of where managers in organizations will overstate the time criticality of certain activities performed in their business area as they tend to be ‘over sensitive’ but also fail to assess the impacts of the loss of their business outputs based on an organizational perspective, tending to focus more on the impacts to their business unit. Before proceeding with the development of the BC plans, the governance group should validate the BIA outputs and adjust the recovery timeframes based on assessing the impacts to the organisation. Consideration should be given to the development of a quantitative impact rating to assist validate recovery time objectives of various business functions.
The other aspect to avoid as part of the BC planning process is to not make the scope of the BC planning too broad particularly if the organization is going through the BC process for the first time. By limiting the scope of the plan to a defined period of time i.e. business functions with a RTOs of less than 14 days or even 7 days as a means of at least being able to confine the terms of reference to those business areas that are in scope and which will also limit the amount of recovery procedures / documentation that will need to be created. Once the organisation is comfortable with the first iteration of its BC plan and comfortable with the process, they can then expand the scoping, as part of the next BC lifecycle review, and push the scope period out to say 30 days.
Chris Bakowski MBCI , senior consultant. LINUS Information Security Solutions
•Date: 21st January 2009• Region: UK •Type: Article •Topic: BC plan development
Rate this article or make a comment - click here
UPDATED 23rd FEB 2010