Determining the scope of the BCMS

To meet ISO 22301:2019 Clause 4.3, you must formally define what parts of the organization the BCMS covers and what it does not cover, with clear boundaries, rationale, and interfaces. The scope must reflect internal/external issues and interested-party requirements, and it must be operationally workable for BIA, risk assessment, plans, exercises, and audits. ¹

Key takeaways:

• Write a scope statement that names included/excluded products, services, locations, processes, and org units, plus boundary interfaces.
• Align scope with real recovery obligations: contractual, regulatory, customer, and operational dependencies.
• Keep evidence that the scope is approved, communicated, reviewed, and consistently applied across BCMS activities.

“Determining the scope of the BCMS” sounds administrative until you try to execute a BIA, map dependencies, or defend your program in an audit. Scope is the control point that decides what must be protected, recovered, tested, and resourced. ISO 22301:2019 Clause 4.3 requires you to define the BCMS boundaries and applicability so the organization can operate a coherent management system rather than a set of disconnected continuity documents. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat BCMS scope like a regulated “system boundary” decision: define inclusions and exclusions, document the rationale, identify interfaces to things outside scope, and get formal approval. If you get scope wrong, everything downstream becomes fragile: your BIA misses critical services, your third-party continuity posture is undefined, and your testing program can’t be justified. This page gives requirement-level guidance you can implement quickly, with artifacts you can hand to auditors and operational leaders.

Regulatory text

Requirement excerpt: “The organization shall determine the boundaries and applicability of the business continuity management system to establish its scope.” ¹

What an operator must do:
You must produce and maintain a clear BCMS scope definition that states:

• Boundaries: where the BCMS starts and ends (organizational units, locations, processes, products/services, and technology environments).
• Applicability: what continuity requirements apply within that boundary, based on your context and obligations.
• Consistency: the scope must be usable across the BCMS lifecycle (governance, BIA, risk assessment, plans, exercising, metrics, and continual improvement). This scope must take into account internal and external issues and interested-party requirements, because those factors drive what the organization must be able to continue or recover. ¹

Plain-English interpretation

Define what your business continuity program is responsible for, in writing, and make it defensible.

A strong scope statement answers, without debate:

• “Which services must we keep running or restore?”
• “Which teams and sites are covered?”
• “Which systems and third parties are part of delivery of in-scope services?”
• “What’s explicitly out of scope, and what is the interface if an out-of-scope area affects an in-scope service?”

Scope is not a marketing summary. It is an enforceable boundary that determines what you will analyze (BIA), protect (risk treatment), and prove (tests and exercises).

Who it applies to

Entity types: Any organization implementing or certifying to ISO 22301, and the people accountable for business continuity governance and assurance. ¹

Operational context where this shows up:

• Enterprise BCMS programs covering multiple business units or legal entities.
• Regulated or contract-driven environments where customers expect continuity commitments.
• Complex operating models with shared services, cloud environments, and material third parties.

If you have more than one line of business, more than one location, or meaningful outsourcing, you need a scope that explicitly handles boundaries and dependencies.

What you actually need to do (step-by-step)

1) Establish scope decision ownership and approval mechanics

• Assign a scope owner (often BCMS manager) and an approver (executive sponsor, risk committee, or equivalent governance body).
• Decide where the scope statement lives (BCMS manual, governance policy set, or controlled document repository).
• Define how changes are approved (change control trigger examples: acquisitions, major outsourcing, new critical product/service).

2) Inventory candidate inclusions (start from services, not org charts)

Build a list of products and services delivered to customers or internal stakeholders. For each, capture:

• Delivery owners (business unit)
• Primary locations
• Key systems/platforms
• Material third parties
• Peak seasonality or operational constraints

Practical tip: if you start from org charts, you will miss shared services (IAM, network, HR/payroll, finance operations) that can become single points of failure for in-scope services.

3) Identify “drivers” that make something in-scope

ISO 22301 expects you to consider internal/external issues and interested-party requirements when deciding scope. Convert that into a short driver checklist you can evidence:

• Interested parties: customers, regulators, shareholders, employees, critical suppliers, and internal service consumers.
• Requirements: contract SLAs, customer due diligence commitments, sector expectations, and internal risk appetite decisions. ¹

Output: a documented rationale for why a service/process is in scope.

4) Draw explicit boundaries (include/exclude) and document interfaces

Create a scope statement that includes:

• Included: named services, org units, locations, and environments.
• Excluded: named items and why they are excluded.
• Interfaces: where excluded areas support included services (or vice versa), and what control you use to manage that interface (for example: dependency mapping, OLAs/SLAs, third-party continuity requirements, incident escalation paths).

A common “scope failure” is excluding shared infrastructure while still claiming the service is covered. If a shared platform outage can stop an in-scope service, you must define the dependency and how it will be managed within the BCMS boundary.

5) Validate the scope against operational reality (BIA and dependency “spot check”)

Before finalizing, run a quick validation workshop:

• Pick a handful of clearly critical services.
• Walk end-to-end delivery: people, process, technology, facilities, data, and third parties.
• Confirm the scope statement actually contains the required organizational units and dependencies to run BIAs and build recovery plans.

If the walk-through requires key components that sit outside the draft scope, either expand the scope or define enforceable interfaces.

6) Publish, communicate, and align downstream BCMS work products

• Publish the controlled scope statement.
• Communicate it to continuity coordinators, IT/operations, procurement/third-party risk, and internal audit.
• Align BCMS artifacts to scope: your BIA population, risk register entries, exercise calendar, and continuity plans must reference the same boundary.

7) Establish scope review triggers

Define review triggers and record the review outcome:

• Business model changes (new product lines, major clients, new geographies)
• Technology shifts (data center exits, major cloud migrations)
• Third-party changes (outsourcing or insourcing critical processes)

ISO 22301 requires you to “determine” scope; in practice, auditors also expect you to keep it current and demonstrably used. ¹

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with versioning and approvals:

1. BCMS Scope Statement (controlled document)

• Inclusions/exclusions
• Boundaries (organizational, geographic, technical)
• Interfaces and dependencies
• Rationale tied to context and interested parties ¹

2. Scope decision record

• Meeting minutes, decision memo, or risk committee extract approving scope and key exclusions.

3. Scope-to-inventory mapping

• A table linking in-scope services to owning units, locations, key systems, and critical third parties.

4. Change log

• What changed in scope, when, why, who approved.

5. Communication evidence

• Distribution list, training/briefing record, BCMS portal posting, or coordinator acknowledgments.

If you use a GRC tool (including Daydream), capture these as structured records: scope object, relationships to services/third parties, and approvals. That makes audit sampling faster and reduces “tribal knowledge” risk.

Common exam/audit questions and hangups

Auditors and certification bodies commonly probe these points:

• “Show me the scope statement and approval.” They will look for controlled-document discipline, not a slide deck.
• “What is excluded and why is exclusion acceptable?” Exclusions must have a rationale that does not undermine continuity objectives. ¹
• “How did you account for interested parties and requirements?” Expect to explain which obligations drove inclusion decisions. ¹
• “Does your BIA population match your scope?” Mismatches are a frequent nonconformity pattern: BIAs performed for entities outside scope or missing in-scope services.
• “How do you manage dependencies outside scope?” They will want to see interfaces and accountability, especially for shared services and third parties.

Frequent implementation mistakes and how to avoid them

Mistake 1: Writing a scope statement that is only a location list

Fix: Scope must include activities/products/services and organizational units, not just sites. Tie it to service delivery.

Mistake 2: Excluding critical shared services without defining interfaces

Fix: If a shared service can stop an in-scope service, either include it or document an interface control (dependency mapping, OLAs, escalation, third-party requirements).

Mistake 3: Treating scope as “set and forget”

Fix: Add review triggers and a change log. Make scope updates part of operational change management for major initiatives.

Mistake 4: Letting each business unit define scope differently

Fix: Use one enterprise scope statement with clear sub-scopes if necessary (by legal entity or line of business), but keep consistent taxonomy and approval.

Mistake 5: Scope defined by what’s easy to document

Fix: Define scope based on obligations and operational impact. If the boundary is driven by resourcing constraints, document that as a risk and prioritize expansion rather than masking it as “out of scope.”

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this guidance focuses on audit and operational risk.

Risk implications of weak scope:

• False assurance: leadership believes continuity capabilities exist where they do not.
• Contractual exposure: customer requirements may assume continuity coverage for services you excluded.
• Third-party blind spots: critical outsourced dependencies remain unmanaged in continuity planning.
• Certification/audit issues: inconsistent boundaries across BIA, plans, and exercises create nonconformities against the requirement to establish clear boundaries and applicability. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign scope owner and approver; set document control location.
• Build the inventory of products/services and map high-level dependencies.
• Draft scope statement with inclusions, exclusions, and known interfaces.
• Hold a validation workshop with operations, IT, facilities, procurement/third-party risk, and business leads.

Days 31–60 (Near-term)

• Finalize scope rationale tied to interested parties and requirements. ¹
• Obtain formal approval; publish scope as a controlled document.
• Align BCMS work products to scope: confirm BIA population and plan ownership lists match.
• Define scope change triggers and log format.

Days 61–90 (Operationalize)

• Run a targeted “scope coherence” check: sample in-scope services and confirm BIAs, dependency maps, and recovery plans exist and reference the same boundary.
• Socialize the scope with internal audit and compliance monitoring so future reviews test against the published boundary.
• If using Daydream, implement a structured scope record with links to in-scope services, critical systems, and third parties, plus an approval workflow and scope-change history.

Frequently Asked Questions

Do we need one BCMS scope for the whole company, or can we scope it to a business unit?

ISO 22301 requires you to determine boundaries and applicability; it does not mandate enterprise-wide coverage. You can scope to a business unit or legal entity, but you must document exclusions and interfaces so the scope remains credible. ¹

Can we exclude third parties from scope if they are “owned by Procurement”?

You can exclude management ownership, but you cannot ignore dependencies. If a third party supports an in-scope service, document the interface and continuity expectations (for example, continuity clauses, escalation, and testing participation). ¹

What’s the minimum acceptable content of a scope statement?

At minimum, name included services/activities, organizational units, and locations, plus explicit exclusions and boundary interfaces. The test is whether you can use it to build a BIA population and plan inventory without guessing. ¹

How do we handle shared IT platforms used by both in-scope and out-of-scope teams?

Document the shared platform as a dependency and decide whether to include the platform operations in scope or manage it through an interface control (OLA/SLA, recovery requirements, and coordinated testing). The scope must describe that boundary clearly. ¹

How often should we review BCMS scope?

ISO 22301 requires you to determine scope; it does not prescribe a review frequency. Define review triggers tied to meaningful change (reorgs, new services, major outsourcing, technology migrations) and keep evidence of each review outcome. ¹

We are mid-merger. Should we expand scope now or wait?

Decide based on continuity risk to in-scope services during integration. If the merger introduces new dependencies that can disrupt in-scope services, update scope or document interim interfaces and risks so BIAs and plans remain valid. ¹

Footnotes

1. ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements