Ten easy ways to improve your business continuity plan

Get free weekly news by e-mailBy Kevin Howells ACFS

Over the years I have looked at hundreds of disaster recovery plans, business continuity plans and other variously termed business resilience documents, going back to my auditing days. In my present role, I continue to view them and review them, and now also test them as well, via bespoke scenarios written for clients. In my experience I have noticed that the problems that could be found with the plans can be summarised into ten categories, as follows:

1. IT specific

During 2007, I was surprised to receive the documentation from a public sector organization relating to business continuity for review, and find that it all related to IT, and the main document related to Year 2000 compliance. As we all know, business continuity professionals constantly have to educate colleagues (normally senior management colleagues) that all processes need protecting, and not just IT specific ones, but it still surprises me when I find plans that are still solely IT focussed.

2. Narrow plans

A business continuity plan needs to take into account the threats to the operation of all aspects of an organization, or at least the key threats. Plans I have reviewed have sometimes been too operational, i.e. only including the threats to specific projects and locations. Alternatively, I have also seen business continuity documentation that only includes the processes in relation to central or head office functions, such as IT, human resources and finance. Clearly, neither of these approaches led to the business continuity documentation being worthy of the name, and each time the organization needed a significant re-think.

It is also important for a business continuity plan to consider beyond just the organizational level. For a start there is the organization’s supply chain to consider, and then stakeholders such as customers, staff and partner organizations, and then the community as a whole. These all need to be considered in terms of the consequences of the incident itself, but also as a resource to be used by the organization; for example, working together to create reciprocal arrangements for use of offices / IT resources.

3. Not process driven

Too many plans I review have a specific resolution in place for dealing with a small number of specific potential incidents, normally a fire, power failure, IT failure and more recently a flu pandemic. The problem with this approach is that unless the actual incident exactly matches the potential incidents planned for, the organization is essentially unprepared, and there is little point in having the plans in place at all. Business continuity plans need to concentrate on processes and generic threats (such as a building being unusable, lack of power, lack of telecommunications or a significant proportion of staff being unavailable).

4. Documentation not available

In my internal audit days, we were aided by the use of a checklist for reviewing business continuity plans, and the first question on that was “Where is the plan held?” More often than not, the answer was either “In my desk drawer” or “On the computer”. This was great in one way, as I had an easy recommendation for my report, but not so great for the organization itself, particularly if an incident occurred, and that incident involved the building they were in or the IT systems, or both! If those with responsibility for business continuity do not have access to the plans, then they cannot be applied.

5. Outdated

Any document needs to be updated in order for it to remain relevant, and this applies as much to business continuity plans as to any critical document. In a time of crisis, the last thing a business continuity team need is to find that their plan has not been kept up-to-date, and they are then scrabbling around trying to contact someone whose number they don’t have (or that the insurers/bankers have been changed), or being referred to a document (or department) that does not exist in the organization anymore. Business continuity plans should be formally reviewed on at least an annual basis.

6. No testing is planned

Many organizations sit smugly with a BS25999 compliant business continuity plan in place, blissfully ignorant that there are problems within their plans; maybe not major ones, but of a scale that they could cause significant deterioration of either efficiency or effectiveness of service should an incident affect them, and they need to invoke the plan. Only by actually testing a plan, in as close to actual conditions as it possible (preferably a scenario workshop rather than a desk-top exercise), will an organization identify the improvements that are needed, and the limitations inherent within the plan. A follow up exercise may also be needed to truly iron out the problems identified in the first test, and enable their business continuity plan to be a ‘ready’ document.

7. Too complicated

It is easy to get carried away when writing business continuity documentation and worrying that they are not detailed enough for those who need to use them when they are invoked. However, I have seen several plans where there is so much detail contained within them that in the end the core information is lost beneath different categories and levels of incident. By way of an example, in a time of crisis, a member of staff should not be confused as to when to apply Disaster Code A, B or C, these codes/levels should be clearly defined in the document, or not be there at all. The core detail that should be included within a business continuity plan is what tasks should be undertaken, by whom, when and why.

8. Wrong tense

A small number of business continuity plans I have reviewed have been written in completely the wrong tense. Instead of saying, “The Key Contact Listing is shown at Appendix A” they say “We will put together a Key Contact Listing”, showing that they do not have a plan in place, merely a strategy to put a plan in place. A business continuity plan needs to be ready for use, and not an aspiration.

9. Poor assumptions

Many a business continuity plan falls down because of a bad assumption on the part of the staff that put it together. For example, why should it be assumed that there could not be more than one incident affecting the organization at any one time? When identifying their key threats, there is also a very real danger of assuming that “we will get by”, or even “someone else will do that”.

There are also many plans in existence that do not have provision within them for defining either what an incident is (and therefore when a business continuity plan should be invoked), or when an incident is over (and normal operations, and authorisations, restart).

10. No media planning

There is a plethora of footage and newsprint showing company representatives being interviewed and saying something either controversial, inappropriate or downright damaging to their employer’s reputation. This normally happens when someone that has not received media training takes it upon themselves to be interviewed, often with the best of intentions. A good business continuity plan should clearly assign personnel to liaise with the media, train them, and specifically prohibit anyone else from talking to a media organization. Dealing with a damaging incident is bad enough without having also to deal with criticism from the media, and thereafter the local community and other stakeholders.

If these 10 points are dealt with appropriately, and staff from across the breadth of the organization have been actively involved in identifying the key threats, then an organization should have a workable and appropriate business continuity plan ready to use.

Author

Kevin Howells is a manager in BTG Intelligence, part of the Begbies Traynor Group, which specialises in the provision of high quality corporate intelligence, risk and security management, business continuity and fraud investigation services.

kevin.howells@btg-intelligence.com
www.btg-intelligence.com

•Date: 12th March 2010 • Region: UK/World •Type: Article •Topic: BCP development
Rate this article or make a comment - click here





Copyright 2010 Portal Publishing LtdPrivacy policyContact usSite mapNavigation help