Determining the scope — General

To meet ISO 22301 Clause 4.3.1, you must define and document the boundaries and applicability of your Business Continuity Management System (BCMS) based on your internal/external context and the needs of interested parties. Operationally, this means producing a defensible BCMS scope statement, mapping it to business units, locations, services, and third parties, and keeping evidence that exclusions are justified. ¹

Key takeaways:

• Your BCMS scope must be tied directly to your context (Clause 4.1) and interested party requirements (Clause 4.2). ¹
• Scope must define boundaries (what’s in/out) and applicability (where requirements apply), with clear rationale for any exclusions. ¹
• Auditors will test scope “truthfulness” by sampling operations, sites, and third parties against your scope statement and BIA/continuity plans.

“Determining the scope” is the make-or-break step that turns a BCMS from a slide deck into an auditable management system. ISO 22301 expects you to set clear boundaries around what the BCMS covers and to explain why those boundaries make sense for your organization’s operating context and stakeholder demands. ¹

For a Compliance Officer, CCO, or GRC lead, the practical goal is straightforward: produce a scope statement that is specific enough to drive execution, broad enough to cover real operational risk, and stable enough that it does not change every time the org chart changes. The scope should be testable against how the business actually runs: where critical work happens, which products and services you deliver, which sites and technologies support them, and which third parties you depend on.

This page shows how to translate Clause 4.3.1 into immediate, repeatable actions: scoping workshops, boundary decisions, documenting exclusions, integrating third-party dependencies, and assembling the evidence pack an auditor or certifying body will expect. ¹

Regulatory text

ISO 22301:2019 Clause 4.3.1 states: “The organization shall determine the boundaries and applicability of the BCMS, considering external and internal issues and interested party requirements.” ¹

Operator interpretation (requirement-level)

You must do three things, and you must be able to prove each one:

1. Determine boundaries: define what parts of the organization, which locations, which products/services, and which supporting resources are included in the BCMS.
2. Determine applicability: specify where the BCMS requirements apply in practice (for example, whether certain processes, sites, or support functions follow the BCMS controls, governance, and lifecycle).
3. Base it on documented inputs: your scope cannot be arbitrary. It must reflect:
   • Internal and external issues captured under organizational context (Clause 4.1), and
   • Interested party requirements identified under stakeholder needs (Clause 4.2).
     ¹

Plain-English interpretation

A compliant BCMS scope answers: “What exactly are we committing to run under this BCMS, and why?” If you cannot connect the scope to your real operating model and stakeholder expectations, the scope reads like wishful thinking and becomes hard to audit.

Expect auditors to pressure-test scope by asking:

• Do the critical services your customers rely on fall inside the scope?
• Do the sites and teams that deliver those services follow BCMS governance?
• Are key third-party dependencies treated as part of the continuity picture (even if they’re not “inside” your org boundary)?

Who it applies to

Entity types

This applies to any organization implementing or certifying an ISO 22301 BCMS, including private sector, public sector, and nonprofits. ¹

Operational context (where this requirement bites)

You’ll feel Clause 4.3.1 most in these scenarios:

• Multi-site operations: deciding which sites are in scope and ensuring “out of scope” sites do not quietly deliver in-scope services.
• Shared services (IT, HR, Finance): deciding whether they are included as full BCMS participants or treated as supporting dependencies with defined continuity obligations.
• Outsourced delivery: where third parties run critical infrastructure, customer support, payroll, logistics, or cloud platforms.
• M&A / restructuring: scope must be controlled as the organization changes; uncontrolled scope drift causes audit findings.

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

Step 1: Assemble your scoping inputs (don’t start with the scope statement)

Pull the artifacts that Clause 4.3.1 explicitly depends on:

• Internal/external issues from your Clause 4.1 context work (market, operational model, technology, regulatory environment, geographic risk, etc.). ¹
• Interested parties and requirements from Clause 4.2 (customers, regulators, employees, insurers, critical suppliers, etc.). ¹

If these inputs are weak, your scope will be weak. Fix the inputs first.

Step 2: Define scope dimensions explicitly

Run a working session with business, IT, facilities, and procurement/third-party owners. Capture decisions across these dimensions:

• Organizational boundary: legal entity/entities included; business units and functions.
• Physical boundary: sites, branches, data centers, warehouses, plants, and remote work considerations.
• Service boundary: products/services delivered, including customer-facing and internal critical services.
• Technology boundary: key applications/platforms that enable in-scope services.
• Third-party dependency boundary: critical outsourced processes and suppliers that materially affect your ability to deliver in-scope services.

Write each boundary as a list that can be sampled in an audit.

Step 3: Decide “in scope” vs “out of scope” using a defensible rule

Create a scoping rule you can repeat, for example:

• Include any service that has contractual availability requirements, material customer impact, or regulatory sensitivity.
• Include any site or team that materially supports delivery of included services.
• Treat third parties that deliver critical steps as continuity dependencies with defined obligations, monitoring, and testing expectations.

Document your rule and apply it consistently.

Step 4: Draft the BCMS Scope Statement (auditor-friendly format)

A usable scope statement typically contains:

• What’s covered: list of included services/functions, locations, and organizational units.
• What’s excluded: explicit exclusions.
• Rationale: tie inclusions/exclusions back to internal/external issues and interested party requirements. ¹
• Interfaces and dependencies: especially shared services and third-party services that affect in-scope operations.

Keep it specific. “All operations worldwide” is hard to evidence unless you can prove governance and lifecycle coverage everywhere.

Step 5: Validate the scope against operational reality

Before you finalize, run three checks:

1. Service reality check: Ask business owners whether any revenue-generating or customer-critical service sits outside the scope. If yes, either bring it in or document why exclusion is acceptable.
2. Org chart check: Confirm teams delivering in-scope services are actually included (watch for matrix teams and offshore support).
3. Third-party dependency check: Identify where third parties are single points of failure for in-scope services, then ensure your BCMS planning accounts for those dependencies.

Step 6: Approve, publish, and bind it to governance

Make the scope official:

• Obtain approval through your BCMS governance path (often top management or a steering committee).
• Publish the scope internally so process owners know whether BCMS obligations apply.
• Bind the scope to downstream work: BIA, risk assessment, strategies, plans, exercises, supplier continuity requirements, and metrics. ¹

Step 7: Put scope change control in place

Scope changes are normal. Uncontrolled changes are audit problems.

• Define triggers: acquisitions, new sites, new customer contracts, major outsourcing changes, major product launches.
• Require a scope impact review before operational go-live.
• Maintain version history and rationale for changes.

Practical tooling note: Many teams manage scope in scattered documents. If you use Daydream, treat the scope statement as the “source of truth” object, then link it to services, sites, critical processes, and third parties so changes propagate into BIAs, exercises, and due diligence workflows without manual rework.

Required evidence and artifacts to retain

Keep an auditor-ready pack that shows inputs → decisions → approved scope:

• BCMS Scope Statement (current version) with effective date and approval record. ¹
• Documented internal/external issues (Clause 4.1 output) referenced by scope rationale. ¹
• Interested parties and requirements register (Clause 4.2 output) referenced by scope rationale. ¹
• Boundary mapping artifact: a table mapping in-scope services to:
  • owning business unit
  • delivery sites
  • core enabling applications/infrastructure
  • critical third parties
• Exclusions log: each exclusion with explicit justification and risk acceptance owner.
• Scope change log: versions, what changed, who approved, and why.

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me how you considered interested party requirements.” Auditors look for traceability from stakeholder requirements into scope rationale. ¹
• “Why is this site/team excluded?” If excluded teams still support in-scope services, you’ll get pushed.
• “Which third parties are critical to in-scope services?” If you can’t answer, your boundary definition is incomplete.
• “Prove the scope is implemented.” They will sample whether in-scope teams participate in BIA, plans, training, exercises, and corrective actions.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Writing a scope that’s aspirational

Symptom: Scope claims broad coverage but you only run BC activities in one department.
Fix: Narrow scope to what governance can реально cover, then expand through controlled scope changes.

Mistake 2: Excluding shared services without addressing dependencies

Symptom: IT is “out of scope,” but every in-scope service depends on IT systems.
Fix: Either include shared services or define explicit continuity obligations, interfaces, and escalation paths tied to in-scope services.

Mistake 3: Treating third parties as “outside the BCMS”

Symptom: Outsourced operations are ignored in continuity strategies and exercises.
Fix: You can’t put a third party “in scope” as an internal function, but you can define dependency management: contracts, SLAs, testing expectations, and contingency arrangements that support your in-scope services.

Mistake 4: No justification trail from Clause 4.1 and 4.2

Symptom: Scope exists, but no one can show why it’s defined that way.
Fix: Add a “Scope Rationale” section that references your context issues and interested party requirements. ¹

Enforcement context and risk implications

ISO 22301 is a standard, not a regulator. The practical “enforcement” is contractual, customer-driven, and certification-driven: if your scope is misleading or not implemented, you can fail certification audits, lose customer trust, or create misalignment between promised resilience and real capability. Poor scope decisions also create operational risk: critical services can fall outside BIA, planning, and exercising, which increases outage impact and slows recovery.

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Gather Clause 4.1 and 4.2 outputs and confirm they are current enough to support scope decisions. ¹
• Inventory candidate in-scope services, sites, enabling systems, and key third parties.
• Draft scoping rules and an initial scope statement outline.

Days 31–60 (Near-term)

• Run scoping workshops with business/service owners, IT, facilities, and third-party/procurement leads.
• Finalize boundary lists (org, sites, services, technology, third parties) and exclusions with written rationale.
• Establish scope change control triggers and approval workflow.

Days 61–90 (Operationalize and prepare for audit)

• Obtain formal approval and publish the BCMS scope statement.
• Build the traceability map from scope → services → sites/systems → third parties.
• Align downstream BCMS activities (BIA, risk assessment, continuity strategies, plans, exercising) to the approved scope so audit sampling matches your documentation. ¹

Frequently Asked Questions

Does ISO 22301 require the BCMS scope to cover the entire organization?

Clause 4.3.1 requires you to define boundaries and applicability, not to include everything by default. The scope must be defensible based on internal/external issues and interested party requirements. ¹

Can we exclude a newly acquired business unit?

You can, if you document the exclusion rationale and manage the risk, but auditors will expect a plan and change control approach for bringing it into scope or managing dependencies. Keep the acquisition as a defined scope-change trigger.

How detailed does the scope statement need to be?

Detailed enough that an auditor can sample and verify coverage across services, sites, and teams. If someone can read it and still ask “what’s actually included,” it’s too vague.

Are third parties “in scope” for the BCMS?

Third parties aren’t part of your internal management system boundary, but dependencies on them must be reflected in your scope boundaries and continuity planning for in-scope services. Treat them as critical dependencies with defined requirements and evidence.

What’s the difference between “boundaries” and “applicability”?

Boundaries define what parts of the organization and operations are included. Applicability explains where BCMS requirements apply in practice, especially across shared services, sites, and supporting functions. ¹

What will an auditor challenge first?

Misaligned exclusions: any “out of scope” function, site, or third party that still materially supports in-scope services. Expect sampling that follows the service delivery chain end-to-end.

Footnotes

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