In Part 2 of Charlie's bulletins on business continuity plans, he looks at the different audiences and how we can develop future plans.
In last week’s bulletin we looked at what plans are for and the different purposes of business continuity and crisis management plans. Today we will look at who the different audiences are and I will share some personal thoughts on how I am looking to develop future plans.
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 the 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!