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 requirements; if this is the case, you should identify those that are relevant to your organisation. As with the context of the organisation, this is a macro-scale exercise intended to identify the parties and their requirements, not the risks or opportunities that might arise from those requirements.
The outputs from this procedure feed directly into the requirements in part six of the Standard, and you will be required to review and update them periodically. Therefore, although not explicitly required, you should keep a record of the parties and their requirements to demonstrate the link between the two, and to assist with the review process.
4.2.2 Legal and regulatory requirements
Section 4.4.2 of the Standard requires that you identify, document and assess applicable legal requirements that are related to the continuity of your products or services, or to the resources and activities involved in delivering them, and ensure that they are considered when implementing and maintaining your BCMS.
If you provide digital services in the EU or UK, for example, you may be in scope of the EU Directive on security of network and information systems (the NIS Directive; or the NIS Regulations in the UK), which requires specific continuity measures depending on the service provided.3 Similarly, US healthcare providers in scope of the Health Insurance Portability and Accountability Act (HIPAA) must develop a disaster recovery plan and ensure it is tested.4
Many organisations already operate a register of legal requirements. If you do not, you will need to create one. A spreadsheet or similar document is perfectly sufficient.
ISO 22301 requires that you keep the register (or whatever method you use to document your legal requirements) up to date. An annual or twice-annual review will be adequate to ensure that the register is properly maintained, though the person responsible for maintaining it should also be expected to keep a weather eye on the news, relevant industry publications or other media that might provide advance notice of upcoming changes to relevant laws.
4.3 Scope of the BCMS
Before implementing a BCMS, you first need to define the system boundaries - what it will include, and what it will exclude. The scope of the BCMS is a key part of the initial implementation exercise, and should be considered carefully, as it will strongly influence the certification process.
For smaller organisations operating at a single site, the scope will likely cover the whole organisation, while larger organisations may operate one overarching BCMS that covers all sites, or multiple site-specific ones. When determining the scope of your BCMS, consider the following:
Products and/or services
Countries or regions of operation, and individual sites or buildings
Organisational divisions, e.g. the constituent organisations within a larger group
Operational divisions, e.g. the different departments, etc. at a single site
The Standard also requires that you consider the context of the organisation and the requirements of interested parties, and the goals and obligations your organisation is subject to, during this process. In practice, this means accounting for legal requirements, the expectations of interested parties that are directly relevant, such as customers, suppliers and regulatory authorities, and any obligations in respect of the services your organisation offers. If your contracts stipulate that you will provide 24/7 warranty support, for example, it makes little sense to exclude your service department from the scope of the BCMS.
All dependencies on which the operations within scope rely, such as materials or resources, are considered in scope by default - after all, without them, achieving continuity would not be possible. You do not need to identify every dependency at this stage, but an awareness of the more significant dependencies is beneficial, in that it may reveal other functions of the business that rely on the same dependencies in less visible ways (and therefore may need to be included in the scope).
The scope does not necessarily have to cover the entire organisation. Some organisations may not need to recover all products or services in order to continue operating, while large organisations with multiple locations might restrict the scope to a single critical site. Although exclusions are permitted, any exclusion you make must not affect your ability to ensure continuity, as determined by the risk assessment and BIA processes defined later in the Standard.
Your rationale for any exclusion should be sound and documented in...
