A BCMS scope defines where the management system applies and, equally important, makes exclusions and interfaces transparent. A defensible scope follows business outcomes and dependencies rather than being chosen only around convenient organizational boundaries.
Start with products and services
Identify the products, services and public or contractual outcomes whose disruption matters to customers, regulators and organizational objectives. Map the organizational units, locations, technologies, information, people and third parties that enable those outcomes. This prevents a scope statement that includes a headquarters function while excluding a supplier or platform on which the service actually depends.
Document boundaries and interfaces
For each boundary, state what is inside the BCMS, what is outside, and how the interface is controlled. Shared corporate functions such as IT, HR, facilities, procurement and communications may sit outside the formal scope but remain critical dependencies. Their responsibilities, service commitments and assurance mechanisms must still be clear.
Challenge exclusions
An exclusion is defensible only when it does not undermine the organization’s ability to deliver the scoped products and services. Record the rationale and evidence. Excluding a location because it is outsourced, for example, is weak if that location hosts the only team able to perform a critical activity.
Consider context and obligations
- Legal and regulatory continuity requirements.
- Customer and contractual commitments.
- Corporate structure and delegated authority.
- Geographic and jurisdictional constraints.
- Critical suppliers and intra-group services.
- Technology and data-hosting boundaries.
- Material changes planned during the certification or governance period.
Write a usable scope statement
The statement should name the products/services, relevant organizational or geographic boundaries and significant exclusions without becoming a long inventory. Supporting records can carry the detailed mapping. A reader should be able to determine which business outcomes are governed by the BCMS and who is accountable for them.
Validate against real disruption scenarios
Walk through scenarios such as loss of a major site, identity platform, telecommunications provider or key supplier. If effective response repeatedly depends on entities declared “out of scope,” confirm that their interface is governed or reconsider the boundary. Scope should survive operational reality, not only an audit diagram.
Change triggers
Review scope after acquisitions, divestments, major outsourcing, new regulated services, facility moves, platform transformations and significant organizational restructuring. Do not wait for the annual review when the operating model has materially changed.
Evidence to retain
Keep the approved scope statement, service and dependency mapping, exclusion rationale, applicable obligations, interface responsibilities, leadership approval and change-review history. This creates traceability from organizational context to the actual boundaries of the BCMS.
Translate organizational boundaries into service boundaries
A useful BCMS scope names the products and services whose continuity is being managed and then maps the organizational units, sites, technology and suppliers needed to deliver them. Legal-entity or department names alone are rarely sufficient because customer outcomes cross internal boundaries. Use service ownership and dependency mapping to show why each major component is inside the scope or governed through an interface.
Treat exclusions as risk decisions
Every material exclusion should have a rationale, an accountable approver and evidence that it does not undermine continuity outcomes or applicable obligations. If an excluded platform, facility or supplier is required to meet an in-scope service tolerance, the dependency cannot simply disappear from the BCMS. Define the interface, assurance requirement and escalation route, or expand the boundary.
Connect scope to BIA and continuity strategy
Check that all in-scope services can be traced to BIA coverage, recovery objectives, strategies, plans, exercises and improvement actions. Conversely, investigate important BIA records or recovery plans that sit outside the approved scope; they may indicate scope drift or unclear ownership. This traceability prevents the scope statement from becoming a document disconnected from operational resilience work.
Use measurable coverage indicators
Management review can track the percentage of in-scope priority services with current BIAs, approved strategies, exercised plans and assessed critical suppliers. Coverage gaps should identify the affected service and owner rather than being hidden inside an aggregate percentage. These measures help leadership understand whether the declared boundary is actually governed.
Define interfaces at the edge of scope
For every dependency that crosses the BCMS boundary, identify the supplying organization, service owner, continuity expectation, evidence source and escalation route. This is especially important for shared corporate technology, centralized facilities, outsourced operations and group-level crisis functions. An interface register makes it possible to demonstrate how an in-scope service remains recoverable even when part of its delivery chain is governed elsewhere.
Use change triggers to prevent silent scope drift
Require a scope review when products are launched or retired, legal entities change, major suppliers are replaced, operating sites move, technology platforms are consolidated, or regulation changes the continuity obligation. The review should ask whether service boundaries, dependencies, BIA coverage and plan ownership still match the approved statement rather than merely renewing the previous wording.
Test scope completeness from both directions
Start with each priority product or service and trace downward to activities, resources, suppliers and plans. Then start with major shared dependencies and trace upward to the services they support. Differences between the two views often expose orphaned applications, suppliers or facilities that were omitted because the original scope was drawn from an organization chart instead of the service-delivery model.
Scope acceptance criteria
Before approval, sample priority services and verify that every material activity, site, technology dependency and critical supplier can be traced to an accountable continuity owner and an applicable analysis or plan. Separately sample major shared dependencies and confirm that all supported priority services are represented. Document exclusions with a business rationale, authority and review date. A scope statement is not complete when an excluded dependency can still cause an in-scope service to breach its approved continuity tolerance.
Related BCM.Center resources: Interested Parties for BCM · ISO 22301 Clause 5 Leadership.