金融机构做业务连续性管理，最容易形式化的一环就是演练。不少企业的演练记录只有一次消防疏散，或者一份没有时间线的会议纪要，审核时无法证明关键业务能在目标时间内恢复。
ISO 22301关注的是中断发生后的恢复能力。演练记录要能说明演了什么、谁参与、结果如何、改进了什么。下面按场景、脚本、结果和跟踪四部分展开。
演练场景要与业务影响分析中的关键业务和恢复目标对应，覆盖设施、系统、人员、供应商和网络攻击等主要中断原因，并留下可验证的时间线和改进闭环。
下表列出金融企业常见的演练场景类型和审核关注点，银行、保险、支付机构都可参照。
| 场景类型 | 常见示例 | 应验证内容 | 常见缺口 |
|---|---|---|---|
| 设施中断 | 办公楼不可用、区域停电 | 备用场地、人员集结、关键岗位到位 | 只演疏散，不演业务迁移 |
| 系统故障 | 核心系统宕机、数据库损坏 | 切换时间、数据恢复点、手工替代 | 没有恢复时间记录 |
| 人员短缺 | 关键岗位集体缺勤 | 岗位备份、授权代行、通讯链路 | 只通知不实操 |
| 供应商中断 | 云服务、外包客服、清算通道中断 | 替代方案、合同约定、联络机制 | 未把供应商纳入演练 |
| 网络攻击 | 勒索软件、数据泄露 | 隔离、取证、对外沟通、业务降级 | 只做技术处置，不做业务决策 |
场景不必每次全部覆盖，但一个认证周期内应能体现主要中断原因都演练过，具体频次以企业程序和审核计划为准。
先看业务影响分析：哪些业务不能停、最长可容忍中断时间是多少、恢复时间目标是多少。演练场景要围绕这些结论设计，而不是围绕部门方便设计。
例如支付清算业务依赖数据中心、网络和第三方通道，演练就应包含系统切换和供应商联动，而不只是人员疏散。
计划要写明目标、范围、假设、时间、地点和参与部门。脚本要有注入事件、预期动作和决策点，避免参演人员提前知道全部剧情。
角色要分清指挥、业务、技术、通讯和观察员。观察员负责记录时间线和偏差，控制员负责推进节奏，两者不能由同一人兼任。
结果记录至少包括实际恢复时间、是否达到恢复目标、遇到的问题和临时应对。关键业务恢复时间要与业务影响分析的目标对照。
发现的问题要形成整改清单，写清责任人、期限和验证方式。只写“演练成功”而没有问题，反而会让审核员怀疑记录的真实性。
演练结果应进入管理评审，作为资源投入、预案修订和下次演练安排的输入。上次演练的问题，要在下次演练或跟踪记录中体现关闭情况。
同创云在辅导金融客户时，通常建议把演练问题清单与风险登记册关联，避免同样的问题连续两年重复出现。
频次由企业根据业务风险、法规和体系文件确定。审核关注的是演练是否按计划执行、是否覆盖关键业务，而不是单纯比次数。
可以算，但要能验证决策、通讯和角色分工。关键业务长期只做桌面演练，通常还需要配合实操或技术切换演练。
如实记录偏差，分析原因并制定改进措施。未达成并不必然导致不符合，关键是是否有分析、整改和后续验证。
企业应掌握关键供应商的连续性安排和联络机制。是否保存其原始记录，取决于合同约定和风险等级。
业务连续性演练不是给审核员看的表演，而是检验预案能否用的压力测试。记录越接近真实过程，越能暴露问题，也越能支撑改进。
具体认证要求、审核安排和证书状态，以认证机构及国家认监委（CNCA）官方最新通知为准。业务影响分析的写法可参考这篇文章，监督审核频次差异见另一篇说明；更多问答见体系认证常见问题。
本文由同创云体系认证研究中心整理，内容参考相关管理体系标准与认证认可通用规则；具体政策以认证机构和监管部门官方最新通知为准。