一、ISO 22301:2019 4.3 标准原文
条款要求：组织应考虑 4.1 和 4.2 的内容，确定业务连续性管理体系的边界和适用性，明确其范围，并将范围形成文件化信息。
二、标准条款解读说明
2.1 范围界定核心要素表
| 要素 | 要回答的问题 | 典型体现 |
|---|---|---|
| 组织边界 | 覆盖哪些部门、职能、站点和法人实体 | 总部、分支机构、共享中心、数据中心 |
| 业务边界 | 覆盖哪些关键产品、服务和活动 | 核心交付流程、关键客户服务、关键运营活动 |
| 依赖边界 | 关键外包、供应链、IT平台是否被纳入考虑 | 云服务、物流、客服外包、关键原料供应 |
| 声明方式 | 范围如何被清楚写明并可审核 | 范围说明、适用性边界、排除理由 |
2.2 核心理解
4.3条款要求组织回答一个核心问题：BCMS 到底保护哪些业务和哪些边界内的活动。范围过大，组织容易在资源和复杂度上失控；范围过小，则可能把真正关键的连续性风险排除在外，导致体系名义上存在、实际上保护不了关键业务。
业务连续性管理体系的范围尤其不能只按组织结构来划。很多真正关键的连续性对象是跨部门、跨站点、跨供应链的。例如一个在线支付服务可能涉及前台交易、清结算、身份认证、客服、云资源和第三方通道。如果范围只写“信息技术部”，就无法真实反映连续性管理对象，也很难支撑后续 BIA 和恢复方案。
本条与 4.1、4.2 紧密关联。环境问题决定哪些风险场景不能忽略，相关方要求决定哪些业务必须被保护，二者共同约束范围界定。也就是说，范围不是凭主观选择，而是基于风险、恢复义务和组织实际运行边界做出的管理判断。
成熟组织在4.3上的做法，通常会把“关键业务活动、关键支持活动、关键资源与关键外部依赖”一起纳入说明，而不是简单写几句部门或地址。只有这样，审核员、管理层和内部团队才能真正理解 BCMS 的保护对象。
三、实施要点
3.1 以关键业务为中心界定范围
- 优先围绕关键产品、关键服务、关键活动和关键时段来界定，而不是只按组织结构划线。
- 对高影响业务应同步纳入其必要支持活动，如客服、IT平台、数据处理、供应链协同等。
3.2 明确空间、组织和依赖边界
- 写清楚覆盖哪些站点、法人、区域和外包接口。
- 对未纳入范围但又存在关键依赖关系的外部方，应说明如何在体系中被管理。
3.3 说明排除逻辑而非简单排除
- 若某些活动暂未纳入，应有清晰理由，如业务影响低、独立运营、后续分阶段纳入等。
- 避免为了降低实施难度而排除真正关键的业务或依赖。
3.4 保持范围动态更新
- 新业务上线、站点调整、重大外包变化、并购重组后，应复核 BCMS 范围。
- 范围说明应能随业务现实变化而更新，而不是认证时写一次后长期不动。
四、常用工具与实施方法
| 工具/方法 | 用途 | 典型输出 |
|---|---|---|
| 关键业务清单 | 识别范围核心对象 | 关键业务和活动列表 |
| 流程边界图 | 呈现跨部门和跨站点业务链路 | 边界和接口图 |
| 依赖关系分析 | 识别外包和关键支持资源 | 依赖关系台账 |
| 范围声明模板 | 规范范围描述方式 | 文件化范围说明 |
| 范围复核机制 | 应对业务变化后的更新 | 范围更新记录 |
五、典型案例
案例一：范围只写总部，关键运营却在区域中心
某企业最初将 BCMS 范围写成“总部管理职能”，但真正支撑收入的订单处理和客服运营都在异地共享中心。后来在4.3复核中发现这一失真，组织重新按关键业务链条定义范围，把区域运营中心和关键外包接口纳入体系，BCMS 才真正具备保护关键业务的能力。
案例二：范围过大导致体系推进失控
某集团试图一次性把所有分子公司、全部站点和所有辅助业务纳入范围，结果资源严重分散，关键业务反而没有被优先分析。随后依据4.3调整为“先覆盖关键收入业务和关键支撑链路，再分阶段扩展”，体系反而更可执行。
案例三：外包边界未写清导致恢复责任不清
某服务型企业将客服外包和云平台依赖视为合同问题，没有在范围中明确说明其与关键业务的关系。一次中断后，各方都认为恢复不完全属于自己。重做4.3后，组织在范围声明中明确关键外部依赖及管理方式，后续策略与计划也更清晰。
从审核角度看，4.3 最怕出现的情况是范围声明写得很完整，但抽样一看，关键业务活动并未真正被纳入分析或演练。也就是说，范围不是写给审核员看的说明书，而是后续所有条款都必须遵守的边界设定。一旦边界与实际运行脱节，整个体系就会产生结构性偏差。
范围界定其实也是一种资源分配判断。组织不可能在任何阶段对所有业务活动使用同样强度的连续性控制，因此4.3要求管理层明确哪些业务必须优先保护、哪些依赖必须被拉进来、哪些活动可在后续阶段逐步纳入。范围说清楚了，后面的 BIA 和演练资源才不会被分散。
对多站点、多法人、集团化或平台化组织而言，范围条款尤其重要。因为这类组织最容易出现总部觉得已建体系、分支却认为不适用于自身的情况。只有范围声明把组织边界、业务边界和依赖边界都说清楚，并且在文件和运行中保持一致，体系才不会在执行层产生理解分裂。
成熟组织在4.3上的一个明显特征，是范围调整机制清晰。新增关键业务、重要外包切换、重大系统迁移、并购整合发生时，管理层知道 BCMS 范围必须随之复核，而不是等到下一次认证周期再处理。这种动态调整能力，正是范围条款从“写一次”走向“管起来”的标志。
因此，范围条款真正守住的，是体系资源不被分散、关键对象不被遗漏这两件事。只要这两点能同时做到，BCMS 才更有机会在现实中真正发挥作用。
也正因为如此，4.3 既是边界说明条款，也是优先级条款。范围一旦明确，后续分析、策略、计划和演练的力量就能集中到最重要的连续性对象上。
换句话说，4.3 做得越准，后面每一分连续性投入就越容易投到真正关键的位置，而不会被无边界扩张或错误排除所稀释。
这也是范围条款虽然简短，却会深刻影响整个体系有效性的原因。范围一旦真实、清晰、可更新，BCMS 的后续动作才更容易保持聚焦。
这会直接决定体系是否真正“护住了关键业务”。
这一点非常现实。
必须重视。
六、成文信息管理要求
- 保留正式的 BCMS 范围声明，明确覆盖对象、站点、业务活动和适用边界。
- 保留范围确定的依据，如环境分析、相关方要求、关键业务识别和依赖分析结果。
- 保留范围调整记录，证明体系会随业务变化及时更新。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 范围只按部门划分 | 忽略跨部门关键业务链条 | 按关键业务活动和支撑链路界定 |
| 为求简单排除关键对象 | 最重要的站点或外包未纳入 | 围绕影响和恢复义务设定范围 |
| 范围写得过大过泛 | 体系落地困难，重点不清 | 分阶段覆盖，优先关键业务 |
| 范围长期不更新 | 并购、外包、迁移后仍用旧描述 | 建立触发式复核和更新机制 |