CHAPTER 1: USING ISO 22301
Readers approaching ISO 22301 for the first time can be forgiven for feeling some trepidation on sitting down to read it. Business continuity is far from the most accessible discipline, and the terminology and processes used can be complex and opaque, especially for new practitioners.
Fortunately, the order in which the Standard is written is, by and large, the order in which the BCMS should be implemented, so it is perfectly feasible to begin at the start and implement each requirement in turn. Although you can implement some requirements in an order other than that specified in the Standard, some aspects of the BCMS can only be effectively implemented after others are in place. It would be challenging to develop a comprehensive internal audit programme, for example, if large chunks of the BCMS are not yet implemented – the internal audit requirements are placed towards the end of the Standard for that reason.
The PDCA cycle
ISO 22301 applies the Plan-Do-Check-Act (PDCA) cycle to both implement and maintain the BCMS. PDCA was developed by quality management pioneer Walter Shewhart in the decades following World War Two, and has since become the core improvement philosophy behind many management system standards.2 The PDCA cycle is an iterative approach to improvement that should be applied to any action taken in respect of the BCMS.
The PDCA cycle is as straightforward as it sounds. Before taking any action, plan out how it should proceed (plan). Once your planning is complete, take the action in accordance with the plan (do). Once the action has been implemented, monitor and evaluate its effectiveness (check), then use the information gained to make improvements (act).
Each iteration of the cycle improves your knowledge of the system, and ensures that change is applied in a controlled manner. Applying PDCA whenever changes are made to the BCMS should ensure that any change that introduces a detrimental effect is quickly identified and mitigated.
It may sound onerous to apply PDCA to every single action taken in respect of the management system, but it is important to remember that the planning and level of analysis should be proportionate to the action concerned. There is no need to create extensive plans and in-depth analyses of relatively minor actions, but more complex actions, or those that could result in potentially serious impacts, should be subject to more detailed consideration.
The Standard does not require evidence that you are applying PDCA, so there is no need to document the planning and analysis for every single action, and the topic is unlikely to arise in any detail during audits unless there is evidence that actions are frequently taken without considering their potential impact. That said, it is useful to retain some evidence of the application of PDCA when preparing for initial certification, and more generally, for complex or high-risk actions taken within a mature BCMS, in case a third-party auditor questions your approach.
Companion standards
Like many management system standards, ISO 22301 is supported by companion standards that expand on specific aspects of the management system, or offer guidance on applying the requirements in the ‘parent’ standard.
ISO 22301 is supported by two such standards:
1.ISO 22313:2020 (Security and resilience — Business continuity management systems — Guidance on the use of ISO 22301); and
2.ISO/TS 22317:2015 (Societal security — Business continuity management systems — Guidelines for business impact analysis).
The former offers general guidance on the application of ISO 22301, and the latter provides detailed guidance on the methodology behind business impact analysis (BIA; a key part of any BCMS).
Unlike many supporting standards, which frequently add little to further the reader’s understanding of the topic at hand, ISO 22313 and ISO/TS 22317 both expand on the requirements of ISO 22301 in a detailed and useful manner. They are an excellent resource for any organisation looking to implement a BCMS.
Integrated management systems
Many organisations already operate a management system, such as ISO 9001 (quality management), ISO 27001 (information security management) or ISO 14001 (environmental management).
All ISO management systems, including ISO 22301, can be combined with any other ISO management system to create an integrated management system (IMS). This provides several advantages: common functions such as internal audit and management review can be adapted to cover the requirements of multiple management systems with only minor impact on resources, while the context of the organisation, interested parties and other common factors will already have been identified to a great extent, saving time.
An integrated approach results in an IMS that makes the most efficient use of resources to achieve the goals of the constituent management systems. Not only does this make for a robust assurance framework, but it can also form the basis for a strong culture of governance and improvement that benefits the entire organisation.
‘Shall’ and ‘should’
As you read through the Standard, there are two important terms to watch out for: ‘shall’ and ‘should’. Any instance of ‘shall’ refers to a mandatory requirement of the Standard – something that must be present for the BCMS to be considered in conformity with ISO 22301. Auditors will expect you to be able to show evidence that a ‘shall’ requirement has been implemented.
‘Should’ refers to a recommendation – something that could benefit the organisation or the BCMS, but which is not a mandatory requirement (and for which you will not be expected to provide evidence). You will also encounter ‘may’ and ‘can’, both of which refer to permissions or possibilities that can be deployed if they suit the organisation.
‘Top management’
All ISO management system standards refer to senior leaders as ‘top management’. Top management refers to the board, executive leadership team or other top-level authority responsible for the organisation, and this book will also use this term.
In particular, ‘top management’ refers to those ultimately responsible for the organisation, or part of an organisation that operates the BCMS. For example, in the case of an organisation that operates multiple sites under a single, overarching BCMS, top management are the persons responsible for overseeing all those sites. If the same multi-site organisation were to operate a separate BCMS at each individual site, then top management would refer to the persons responsible for the site in question.
2 Although developed by Shewhart, PDCA was popularised by W. Edwards Deming (another key figure in the development of quality management systems). Deming preferred ‘plan-do-study-act’ in the later years of his career, as it emphasises the need for analysis and evaluation of the action, rather than simple inspection, as implied by ‘check’.
CHAPTER 2: CONTEXT, INTERESTED PARTIES AND SCOPE
4.1 Context of the organisation
Before implementing any management system, it is necessary to identify the context in which the organisation operates, and any issues that arise from it that might affect the organisation or its BCMS.
Organisations implementing their first management system sometimes struggle with this requirement. The Standard does not provide much information on what this process should look like or what its outputs should be, and as a result, even experienced practitioners approach this requirement in radically different ways.
The goal of this requirement is not merely to reiterate the obvious – organisation X is in the business of Y, and so on – instead, the requirement drives analysis of the conditions (both internal and external) that the organisation operates within to ensure that those conditions do not adversely affect the organisation or its BCMS. By considering where you are now, and where you are likely to be in the future, you lay the foundations for effective governance.
‘Internal issues’ can include the products or services the organisation offers (including any standards, e.g. safety standards, that they must adhere to), employees and unions, the culture and values of the organisation, operational and development priorities, warranty and service requirements, governance concerns (such as any other management systems already in operation) and more.
‘External issues’ can include legal and regulatory requirements (whether they apply to the products or services offered or to the organisation itself), the supply chain, media and communication, the environment in which the organisation operates (whether financial, operational, etc.) and even technological changes in the field that might affect your business, such as a competitor developing a superior product or a new method of manufacturing that reduces cost.
It is important to note that the process of identifying context should not focus solely on issues that might result in a negative impact. You should also consider opportunities that could lead to a positive outcome, as these can have just as significant an effect (albeit in a different way) on the organisation and its BCMS.
One method to define the external context of the organisation (though by no means the only method) is to perform a ‘PESTLE’ analysis. This approach places external issues into six categories;
1.Political;
2.Economic;
3.Social;
4.Technological;
5.Legal; and
6.Environmental.
This provides an at-a-glance view of the issues affecting your organisation. At this stage, you are not trying to identify specific risks that may arise from the issues you identify; this is a macro-scale exercise designed to capture sources of potential impact, not the impacts themselves.
Internal context can be identified through a ‘SWOT’ analysis. This method considers the organisation’s strengths, weaknesses, opportunities and threats, and is often used in tandem with a PESTLE analysis. The combination of the two makes for a wide-ranging view of the organisation, which satisfies the requirements of the Standard.
The Standard does not require you to retain evidence that you have considered the context of the organisation, but the external and internal context outputs feed directly into the requirement to address risks and opportunities related to the BCMS in part six of the Standard, so it is important to keep a record of those outputs for use in that procedure. You will also need to periodically review and update the issues you have recorded as part of the BCMS improvement process, which is a lot easier to do if they are documented.
4.2 Interested parties
Once you have identified the context your organisation operates in, the next step is to identify ‘interested parties’ and their requirements.
Interested parties refers to stakeholders of any sort, those to whom your organisation owes a duty of care (whether inside or outside the organisation) and those that could affect, or be affected by, the BCMS. The list of potential interested parties is long, and can include:
•Customers;
•Suppliers and distributors;
•Shareholders and investors;
•Regulators and enforcement bodies;
•Employees and contractors;
•Media; and
•Neighbours, organisations that share the premises, members of the public, etc.
Each interested party has its own requirements. Your suppliers, for example, will no doubt require that you pay their invoices on time, while regulators will require that you follow applicable laws, contact authorities when appropriate, etc. Interested parties may have multiple requireme...