Define what the business continuity management system covers before you run the BIA, set recovery priorities, or claim certification readiness.
Use the scope as controlled BCMS documented information: products and services, locations, activities, dependencies, outsourced processes, exclusions, interfaces, owners, and review triggers.
The ISO 22301 must identify the parts of the organization and the products and services included in the business continuity management system. It must be available as documented information. Suppliers, shared services, technology, and other dependencies need to be identified and controlled when they affect in-scope delivery. An external provider remains outside the organization's management-system scope, but an outsourced function or process within the BCMS remains in scope and under the organization's control.
1
Section 1
What should the ISO 22301 BCMS scope decide?
Clause 4.3 requires the organization to determine the BCMS boundaries and applicability. The scope decision must consider internal and external issues, relevant interested-party requirements, and the organization's mission, goals, and obligations. It must establish the included parts of the organization, taking account of location, size, nature, and complexity, and identify the products and services included.
Apply ISO 22301:2019 together with Amendment 1:2024. The amendment requires the organization to determine whether climate change is a relevant issue under Clause 4.1 and notes that relevant interested parties can have climate-related requirements under Clause 4.2. Record the determination and any scope consequence; do not assume climate change is relevant or irrelevant without considering the organization's context.
A useful scope is specific enough for recovery owners to know whether their process is in scope. It should avoid vague phrases such as "all operations" unless the BCMS actually covers every location, , support function, product line, and service interface.
Use the scope as the boundary for the rest of the BCMS. The , disruption-risk assessment, continuity objectives, strategies, plans, exercises, internal audit, and management review should all use the same included products, services, and organizational parts.
Decide each boundary item explicitly. Include organizational parts and products or services governed by the BCMS; retain control of an outsourced function or process while treating the external provider as outside the management-system scope; document and explain any ; and escalate an unresolved interface for management decision. Record the decision, rationale, owner, approval date, affected requirements, and downstream BCMS records.
Name the legal entity, operating unit, or group functions covered by the BCMS.
List the products and services whose continuity is covered, including the customer-facing or internal services that must remain within acceptable time frames.
Identify the locations, remote-work arrangements, technology platforms, people dependencies, suppliers, outsourced functions or processes, and supply-chain interfaces that support those products and services. Distinguish the external provider from the in-scope outsourced function or process.
Document and explain exclusions. An cannot impair the organization's ability and responsibility to provide business continuity as determined by the or disruption-risk assessment and applicable legal or regulatory requirements.
Assign an owner for the scope statement and connect it to controlled documented information.
What evidence should support the scope and boundaries?
The standard requires the scope itself to be documented; it does not prescribe a scope template or require every supporting record listed here. Choose evidence proportionate to the organization. A context assessment, interested-party and legal-requirement record, product and service inventory, process map, supplier list, location list, dependency map, and approval history can make the scope decision traceable.
For audit and customer assurance, useful evidence connects scope to operation: the in-scope products and services appear in the , their supporting activities are assessed for disruption impact, strategies and resource requirements are selected, plans are exercised, and changes feed management review.
Context evidence: internal and external issues, continuity obligations, customer commitments, critical suppliers, outsourced processes, and interested-party requirements.
Traceability evidence: mapping from in-scope products and services to entries, recovery priorities, continuity strategies, plans, exercises, and corrective actions.
Boundary evidence: diagrams or registers for shared services, cloud platforms, facilities, call centers, manufacturing sites, logistics partners, and other interfaces that affect delivery.
Review evidence: management-review minutes, internal-audit findings, change records, exception decisions, and actions taken after scope-impacting changes.
This ISO 22301 guide helps turn scope wording into a maintained evidence set: covered products and services, dependencies, exclusions, interfaces, approvals, and change-triggered reviews.
How should teams maintain BCMS boundaries through change?
Review the scope through BCMS change control. ISO 22301 requires planned BCMS changes, and it requires and disruption-risk assessment reviews at planned intervals and when significant changes occur. A new product, discontinued service, acquisition, facility move, cloud migration, , supplier replacement, major incident, customer contract, or continuity obligation may therefore require a scope decision and downstream updates.
The scope owner should decide whether the change affects products and services, supporting activities, resources, legal obligations, interested-party expectations, or continuity objectives. If it does, update the scope and then refresh downstream evidence such as the , risk assessment, strategies, plans, exercises, and audit scope.
Trigger review when a covered product, service, site, legal entity, , technology platform, supplier, or recovery obligation changes.
Classify each change as inside scope, outside scope, a justified , or an unresolved boundary issue requiring management decision.
Update the interested-party and legal/regulatory requirement records when customer, regulator, owner, personnel, provider, partner, or community expectations change.
Refresh and risk-assessment inputs when scope changes affect acceptable time frames, predefined capacity, resource requirements, or recovery dependencies.
Record who approved the boundary decision and which BCMS records were updated.
A scope can be too broad to operate or too narrow to support the stated assurance claim. If the BCMS covers a service but omits how a call center, cloud platform, single-source supplier, or shared operations team affects that service, the organization may not be able to show that the preserves its continuity ability and responsibility.
Do not treat exclusions as silence. Clause 4.3.2 requires exclusions to be documented and explained. The organization still needs to control outsourced processes and the supply chain under Clause 8.1 and determine partner and supplier dependencies through the under Clause 8.2.2.
Do not claim enterprise-wide BCMS coverage if the , plans, exercises, and audit program only cover one business unit or region.
Do not exclude outsourced processes simply because the external provider is outside the organization; record whether the outsourced function or process supports an in-scope product or service.
Do not leave shared services ambiguous. HR, facilities, IT, security operations, logistics, finance, and communications may be boundary interfaces even when they are not the product owner.
Do not let the certification scope, customer assurance scope, and internal recovery scope drift apart without a documented explanation.
Do not rely on old scope wording after a merger, divestiture, site closure, new platform, supplier change, or major incident.
What should a good BCMS boundary statement include?
A good boundary statement is readable without the standard beside it. It identifies the included organizational parts, locations, products, and services; explains exclusions; and points to the context and requirements that shaped the boundary. Supporting maps can then show the activities and dependencies needed for delivery.
The statement should also be usable in isolation by sales assurance, internal audit, continuity planners, supplier managers, and incident responders. Those teams should be able to decide whether a process, location, supplier, or platform belongs in the BCMS evidence set.
Covered organization: legal entities, business units, functions, and accountable scope owner.
Covered outcomes: products and services, acceptable continuity expectations, and the customers or users affected by disruption.
Boundary and interfaces: included locations and organizational parts, plus the critical activities, resources, technology, suppliers, outsourced processes, and supply-chain interfaces that support in-scope products and services.
Exclusions: out-of-scope activities, sites, products, or dependencies with rationale and residual-risk owner.
Governance: approval, document control, review cadence, change triggers, and links to , risk assessment, strategies, plans, exercises, audits, and management review.
Clause 4.3 requires the scope to be documented and Clause 4.3.2 specifies the organizational parts, products, services, and explained exclusions it must address.