What is the purpose of crisis and business continuity plans and how can they be improved?

As business continuity people, I think ‘the plan’ is the expression of our trade. I am sure we have all had this conversation with employers and clients, ‘just cut the crap, don’t bother with the BIA and just give me the plan'. I thought for this bulletin I would explore some ideas about plans. I find myself sometimes going around in circles about what a plan is for and how to write and construct one. I am currently exploring some new ideas for plans, which I thought I would share with you.

Business continuity and crisis plans can have a number of purposes:

1. They can serve as a guide on what we do on the day of an incident, and they give us a framework to follow. For this purpose, the plan should be written in the sequence that it could be used and should be quite minimalistic. Nobody at the operational or strategic (crisis) level wants to be wading through 50 pages in the middle of an incident, to try and find out what they should do.

2. We also have the generic plan of how to respond to any incident. This would detail how your organisation configures itself to manage and respond to an incident. It shows what the incident hierarchy is, what the roles and responsibilities of each of the teams are, and the roles within them. It should also include how to activate the plan, who can do it and where the team will meet under different circumstances. This plan can be used to manage any type of incident and would be used for an incident that we have not planned a specific response for.

3. The plan could contain information on how to respond to a particular threat or risk. There could be a plan for dealing specifically with the response to a pandemic being declared, and how to manage it when your organisation is in the middle of the pandemic. A specific plan could be for a hurricane, which includes what annual preparations are needed for hurricane season, what to do when a hurricane is imminent and how to respond after the event. You may have a specific plan on how to respond to a ransomware attack, which would be different from how you respond after a data breach. This type of plan could also be a multi-agency plan, which details how all agencies would work together in response to an oil spill, or in high hazard industries, how to respond to a fire or an explosion. We must also mention the classic business continuity plan on how to respond to the loss of premises, people, technology and key suppliers. The writing of hazard or installation plans could also be a key regularity requirement in the licence to operate.

4. Plans can be used to tell us how to carry out a procedure or give us a step-by-step guide on how to carry out a certain task. This is more particular in IT, where if you want to recover a server then you have a disaster recovery plan which tells you how to do this, down to ‘type in //12.23.67.890 at this prompt’. This plan needs to be very precise and detailed. If it is 100 pages, that just illustrates the complexity of the task, and so having a long plan is not an issue.

5. Plans can contain information and reference material needed on the day of the incident. A plan can include the number of recovery seats each department has and a list of names of who will sit in each seat. It could also contain telephone numbers of the references, how to use a conference call bridge or the codes to invoke work area recovery.

6. Finally, a plan can contain Standard Operating Procedures (SOPs). These are processes or tools we use to manage an incident. So, for PlanB Consulting, we have a standard agenda we teach incident teams to use during their meetings. We have a circle of Situation – Decision – Action with a series of actions during each, and this is the way in which we manage the response to incidents. We hope that those in the incident team can remember how to use these tools, but it is often useful to have an aide-memoire (a plan) of either how to use them or a mnemonic to remind them of the constituent parts of the tool. We can also use aide-memoires to remind us of the constituent parts of the plan and provide a shortened version, highlighting the key parts the team members need to know.

First, we need to look at the readers of our plans, as different audiences will want different things. The audience of these plans could include the following:

1. Those in the incident team who will actually use the plan. They require the plan to contain a reminder or checklist of what they should do, details of their roles and responsibilities, and details which they are unlikely to remember on the day, such as the RTOs of each activity, recovery numbers and key telephone numbers. The team need something they can use on the day of the incident, which only contains key information, as they don’t want to be wading through pages of irrelevant material. They should already know the main details and the document should just be used as a reminder of the plan.

2. The organisation as a whole needs to have documented how all the different parts of the plans work together. This should include details of the different recovery plans for specific incidents and how the whole organisation will work together to respond to the incident. Normally this information is spread throughout the different plans and some of the details, such as the roles and responsibilities of each incident team, will be duplicated in all plans. Usually there is no single document which brings this all together, therefore how the whole plan works together in a large organisation may only be known to those who wrote the plan.

3. You may have regulators or as part of an audit you may have to supply copies of your plan. If you have a 2 page plan/aide memoire and you send this across to the auditor or regulator, they will probably ask where the rest of it is, as this is not a proper plan. For the regulator, you need to have a full document containing all the elements of a plan, as listed in the BCI’s Good Practice Guidelines or ISO 22301. 

4. I have noticed that we at PlanB Consulting are getting quite a demand for business continuity role out, from organisations who have been asked to have business continuity in place by their customers. Whereas in the past, there was a single tick box in procurement documents next to the question; 'Do you have a business continuity plan?'. Now there are a list of questions and organisations are asking their potential suppliers for evidence that business continuity is in place and for copies of actual documents, including a copy of their business continuity plan. The issue for some companies is that the business continuity plan may contain sensitive and personal information or recovery details, which they may not want to share outside the organisation.

Different audiences want different things from a plan, so as business continuity professionals we need to think about how we can satisfy all these different audiences and give them what they want, as well as making the information they will need on the day of an incident available.

In our existing plans, at PlanB Consulting, we try and satisfy all the audiences by producing a standard format plan or series of plans. It contains the following elements:

1. They only include information needed on the day of an incident, so all background information, such as how often the plan must be exercised, is documented in a separate ‘operations manual’.

2. The plan is in chronological order, so the information that you need at the beginning of the incident is at the front of the document and the recovery details are at the back.

3. We follow a 5-step approach to incident management, so in each section there is a checklist of tasks to be carried out. If you are familiar with the plan you only need to use the checklists, but if you are not so familiar with the plan or the reader is a customer, auditor or regulator, then there is more detail provided within the plan.

4. We have recovery plans for specific incident scenarios, such as loss of premises, loss of IT and a pandemic. These recovery plans are tied to a particular risk to the organisation.

5. We are often asked to carry out incident management training for incident teams and within the plan, we include details of the tools and techniques we teach during the training. I am always wary of bulking up the plans and putting in lots of tools, especially if those executing the plan have not been taught them, as they won’t be used and the plan will become bulky and contain superfluous information.

On average our plans sit between 20 and 40 pages, which I think is quite large, but I struggle to see how you can take out some of the information without removing key requirements from the plan. Although I think our plans are as user friendly as they can be in this format, I am convinced there might be a better way.

My thoughts are as follows. I have not yet implemented this, but it is a direction I think I am going to take:

1. The initial plan that the team are going to use is a ‘two-sider' plan preferably printed on a Z-CARD which can always be carried around by incident team members - I also need to think about an electronic version. This card will provide the team with enough information to get them through the first 24 hours of an incident. It will contain checklists for activating the team, who’s on the team, locations and an agenda for running the first 2 or 3 team meetings. It will also have information regarding the initial communications to be made. I have yet to think through whether there can be a standard ‘two-sider’ per organisation or per level of team, or whether it will always have to be tailored to the organisation. 

2. A separate plan, which will be a reference document, will explain the roles and responsibilities of the teams, the incident hierarchy, recovery plans based on scenarios and background information on how the organisation will respond to an incident. It will be there for two purposes, as a reference for the team to use if they want more detail than their ‘two-sider’ and to be available to customers, auditors and regulators.

3. There is reference information needed on the day such as telephone numbers, numbers of recovery seats, IT lists, RTOs and other information which is taken from the BIA and will need to be referred to during the incident. I have yet to decide if this should be on a separate reference sheet, on the back of the ‘two-sider’ or in the reference document, depending on the amount of information. I need to try and implement it and see what works.

Within our profession, I think we have to constantly innovate, push and change our ideas, even if it takes us 10 years to come back to what we started with. If we put out the same thing year after year without any thought, then perhaps it is time to find another career!