ISO 22301:2019 is built on the High Level Structure, a common architectural framework shared by modern ISO management system standards. Understanding the clause architecture is a prerequisite to effective implementation. The standard does not lay out a philosophical debate about business continuity—it prescribes a structure. The structure determines how to scope the BCMS, what must be documented, what must be tested, and what an auditor will assess.
The ten clauses of ISO 22301 are not equal in weight. The first three—Scope, Normative References, and Terms and Definitions—establish the foundation but contain no auditable requirements. Clauses 4 through 10 define the actual management system. Of those, Clause 8 (Operations) is the largest and the most heavily weighted in certification audits because it is where the actual business continuity capability lives: the plans, the procedures, the exercises, and the evidence of resilience.
This article walks through the ten clauses, explains what each requires, and examines how the High Level Structure alignment with ISO 27001 and ISO 9001 enables integrated management systems in organisations that hold multiple certifications.
The High Level Structure: A Shared Architecture
The High Level Structure (HLS), formally known as Annex SL in ISO guidelines, is a common management system framework adopted by ISO in 2015 to create consistency across standards. It defines: scope and applicability; normative references; terms and definitions; context of the organisation; leadership; planning; support; operation; performance evaluation; and improvement. If you have implemented ISO 9001 (quality), ISO 14001 (environment), ISO 27001 (information security), or ISO 45001 (occupational health and safety), you already recognise this architecture.
The benefit is substantial. Organisations that hold multiple ISO certifications can share the management system infrastructure—the policy framework, the governance structure, the internal audit process, the document management system, the training and awareness programme, and the management review cycle. The BCMS does not need its own separate board governance, its own separate audit team, or its own separate quality management process. The management system architecture already exists; the BCMS plugs into it.
This is not theoretical. Organisations that successfully implement integrated management systems reduce duplication, lower certification audit costs, and achieve faster certification timelines than organisations that treat each standard as a separate programme. The HLS alignment is one of the most underutilised advantages in multi-certified organisations.
| Clause | Title | Core Requirement | Key Output |
|---|---|---|---|
| 1 | Scope | Defines applicability of the standard | Understanding of BCMS boundaries |
| 2 | Normative References | No normative references cited | N/A |
| 3 | Terms and Definitions | Establishes BCMS vocabulary | Shared terminology across the organisation |
| 4 | Context of the Organisation | Internal/external context, stakeholders, BCMS scope | Scope statement, stakeholder register |
| 5 | Leadership | Top management commitment, policy, roles | BC Policy, assigned roles and responsibilities |
| 6 | Planning | Risk assessment, BIA, objectives, plans to achieve them | BIA output, risk treatment, BCMS objectives |
| 7 | Support | Resources, competence, awareness, communication, documented information | Training records, communication plan, document register |
| 8 | Operation | BCPs, crisis management, ICT continuity, exercises | Business Continuity Plans, exercise records |
| 9 | Performance Evaluation | Monitoring, internal audit, management review | KPI reports, audit reports, management review minutes |
| 10 | Improvement | Nonconformity, corrective action, continual improvement | Corrective action register, improvement log |
| KEY IDEA | Clauses 1–3 set the stage but contain no auditable requirements. The certification audit is focused on Clauses 4–10. Of those, Clause 8 (Operations) carries the most weight in a Stage 2 audit because it is where the actual business continuity capability lives—plans, procedures, and exercises. |
Clause 4 — Context: The Foundation of Scope
Context is where the BCMS begins. Clause 4 requires the organisation to understand its internal context (organisational structure, capabilities, existing systems, relationships), external context (market, regulatory, competitive, technological, social, economic environment), and interested parties (stakeholders whose interests the BCMS must respect: customers, suppliers, staff, regulators, insurers, shareholders).
The BCMS scope flows from this analysis. Scope defines which activities, locations, functions, processes, and systems are in scope for the BCMS and which are explicitly out of scope. Scope is not arbitrary; it is determined by the context analysis and top management decision. An organisation might decide to scope only critical financial systems, or it might scope the entire organisation. The decision is the organisation’s. But it must be deliberate, documented, and explained.
Scope is the boundary within which the Business Impact Analysis will be conducted, the Business Continuity Plans will be developed, and the certification audit will assess compliance. An under-scoped BCMS avoids difficult areas but provides no protection there. An over-scoped BCMS creates implementation burden without corresponding risk reduction. The right scope is determined by stakeholder requirements and the organisation’s risk tolerance.
Clauses 5–7: Leadership, Planning, and Support
Leadership (Clause 5) establishes top management commitment to the BCMS. This is critical: top management is not IT. Business continuity is a business responsibility, not a technology problem. Top management must establish the BC Policy, assign BC roles, ensure resources, and demonstrate commitment. Without visible top management commitment, the BCMS becomes an IT project that will be underfunded when budget priorities shift.
Planning (Clause 6) is where the BIA happens. The Business Impact Analysis is the central input to the entire BCMS. The BIA identifies which activities are critical, how fast they need to recover (RTO), how much data loss is acceptable (RPO), what the absolute deadline is (MAO), and what resources are required. The BIA is business-driven, not IT-driven. It is conducted with business process owners, not IT. The BIA output drives risk assessment, continuity strategy, recovery targets, and exercise design.
Support (Clause 7) covers resources, competence, awareness, communication, and documented information. The BCMS requires funding, people with explicit BC responsibilities, training, and clear lines of communication. Documented information—BC policies, BCPs, risk registers, training records—is the evidence that the BCMS exists. If it is not documented, it is not part of the certified BCMS, and an auditor will not recognise it.
Clause 8: Operations — The Heart of the BCMS
Clause 8 is the largest clause. It covers planning and implementing business continuity processes, preparing the BCPs, establishing crisis management procedures, planning ICT continuity, designing and conducting exercises, and managing change. This is where the BCMS becomes operational rather than documentary.
Business Continuity Plans are the cornerstone. A BCP is a procedure that describes how to restore a critical activity after disruption. It identifies activation criteria, roles, responsibilities, communication protocols, recovery procedures, and alternative work arrangements. The BCP is not a 500-page document; it is a concise, procedure-focused document that someone can activate in a crisis. BCPs must be tested regularly through exercises.
ICT continuity planning (often called disaster recovery planning or IT continuity planning) is typically the largest component of the BCP. It includes backup strategy, recovery runbooks, RTO targets for each critical system, failover procedures, and testing schedules. If the organisation relies on ICT systems—and nearly every modern organisation does—ICT continuity is the make-or-break element of the BCMS.
| IMPORTANT | Clause 8 is the clause that determines whether an organisation can actually recover. Organisations that focus audit preparation on documented information (Clauses 4–7) but underinvest in Clause 8 operational content—incomplete BCPs, untested ICT recovery procedures, inadequate exercise programmes—are the organisations that accumulate Stage 2 major nonconformities. |
Clauses 9–10: Evaluating and Improving the BCMS
Performance Evaluation (Clause 9) requires the organisation to monitor BCMS performance through KPIs, conduct an internal audit of the BCMS at least annually, and conduct a management review of the BCMS at least annually. KPIs might include: percentage of critical activities with tested BCPs, average BCP exercise participation rate, time to activate the BCMS, or incident recovery time against RTO targets.
Internal audit is the primary mechanism for assessing BCMS compliance and effectiveness. The internal audit must be independent, must assess all areas of the BCMS from Clause 4 through Clause 10, and must report findings to management. The management review takes those findings, reviews the effectiveness of the BCMS, and directs improvement.
Improvement (Clause 10) closes the cycle. Nonconformities—failures to meet the standard—require root cause analysis and corrective action. Improvement actions might come from internal audit findings, exercise debriefs, or lessons learned from actual disruption events. The corrective action process is documented, tracked, and verified for effectiveness.
| HLS Clause | ISO 22301 BCMS Content | ISO 27001 ISMS Equivalent |
|---|---|---|
| Clause 4 | BCMS scope, stakeholder BCM requirements, legal/regulatory BCM obligations | ISMS scope, stakeholder information security requirements |
| Clause 5 | BC Policy, top management commitment to BCMS | Information Security Policy, ISMS leadership commitment |
| Clause 6 | Business Impact Analysis, BC risk assessment, BCMS objectives | Information security risk assessment, risk treatment plan, IS objectives |
| Clause 7 | BCM competence and awareness, BC communication plan, BCMS documented information | IS competence and awareness, IS communication, ISMS documented information |
| Clause 8 | Business Continuity Plans, crisis management, ICT continuity, exercise programme | Security controls (Annex A), incident management, IS continuity (A.5.29–5.30) |
| Clause 9 | BCMS KPIs, BCMS internal audit, management review of BCMS | IS performance metrics, ISMS internal audit, management review of ISMS |
| Clause 10 | BCMS nonconformity and corrective action, BCMS improvement | ISMS nonconformity and corrective action, ISMS improvement |
| BITLION INSIGHT | Organisations implementing both ISO 22301 and ISO 27001 can share the entire management system infrastructure—context, policy, objectives, competence, awareness, internal audit, and management review—with only the operational content (Clause 8) remaining truly separate. In practice, a combined ISMS/BCMS adds roughly 30–40% to the implementation effort of ISO 27001 alone, not 100%, because the management system architecture is already in place. |