BCMS scope and interfaces
4 min read
Lesson objectives
- Use bcms scope and interfaces to justify a decision, result, and evidence limit in the case.
Scoping a business continuity management system does not mean drawing a circle around buildings the organization owns. The scope tells a reader which products, services, processes, locations, and parties inform continuity decisions and what assumptions limit the result. A distributor may own its warehouse but not its carrier, electricity network, or cloud platform. It cannot make a credible delivery recommendation while ignoring those interfaces. Distinguish what the organization can manage directly from external dependencies it must monitor, contract for, or provide alternatives to. An honest scope does not claim control over a supplier, but it still records the supplier's effect.
Start at the outcome a recipient experiences and trace delivery backward. For an urgent order, the chain may be order acceptance, stock confirmation, allocation priority, picking, storage-condition check, carrier handoff, proof of receipt, and exception handling. For each step, record the owner, site, information required, and assets or suppliers on which it depends. This map joins scoping to later impact analysis. Listing the ordering platform alone misses a cold-storage failure. Listing every company asset without discrimination dilutes evidence gathering and funding. Include an element because it contributes demonstrably to the service outcome or to a decision about protecting it.
There are four practical dimensions to a boundary. The service boundary names customers or order types in the engagement; exclusion does not mean other services are unimportant. The location boundary names normal and alternate sites and routes, including shared hazards. The time boundary distinguishes ordinary hours, night shifts, holidays, and peaks: a midday transfer capability may disappear when only one person is on duty. The authority boundary distinguishes a procedure the organization may change from a supplier or third-party arrangement that needs separate approval. Add a data-access boundary if records are spread across systems or jurisdictions; technical need alone does not grant cross-party access rights.
Build an interface register rather than a list of supplier names. For each interface, describe the service it supports, evidence of dependence, relationship owner, interruption period after which impact becomes material, feasible alternative, and verification status. A carrier contract may specify response under ordinary conditions without assuring fleet availability in a regional incident. Two warehouses may not be independent if both face the same flood plain or share power and staff. Such correlated failure can defeat alternatives that appear diverse on paper. Ask for the real route and performance evidence, not the slogan “we have two suppliers.”
Compare two possible scopes by asking what conclusion each permits. A scope limited to online ordering may support a conclusion about order capture and perhaps data availability, but not about delivery of temperature-controlled goods. A scope reaching hospital receipt permits analysis of supplier gaps, but it still cannot establish an alternate's capacity before a test. Record each boundary decision in a three-column log: element, inclusion or exclusion rationale, and effect on the conclusion. A material exclusion needs sponsor acceptance with its consequences understood. Calling a critical, unverified dependency an “assumption” does not remove the problem.
Close with a reviewable scope statement: named service and minimum outcome, sites and operating periods, critical dependencies, interface owners, delegated decisions, and uncertainties to be resolved by impact analysis and solution testing. ISO's public description presents a management system that is implemented, operated, monitored, and improved; a static boundary diagram alone cannot show continuing capability. Revisit boundaries when a service, supplier, site, or central assumption changes, rather than treating a calendar review as proof of accuracy. The consultant states how the change affects the old conclusion before recommending the next investment.
Lesson summary
Scoping a business continuity management system does not mean drawing a circle around buildings the organization owns.