一、ISO 22301:2019 7.4 标准原文
条款要求：组织应确定与业务连续性管理体系相关的内部和外部沟通，包括沟通什么、何时沟通、与谁沟通、如何沟通以及由谁负责沟通。
二、标准条款解读说明
2.1 连续性沟通要素表
| 沟通要素 | 应明确的内容 | 关键风险 |
|---|---|---|
| 沟通对象 | 员工、管理层、客户、监管机构、供应商、媒体、合作伙伴 | 对象遗漏导致信息链断裂 |
| 沟通内容 | 事件状态、影响范围、应对措施、恢复安排、行动要求 | 内容不清导致误判和混乱 |
| 沟通时点 | 预警、事件确认、升级、恢复、复盘等关键节点 | 延迟沟通导致窗口错失 |
| 沟通方式与责任 | 电话、短信、邮件、系统通知、会议、公告及责任人 | 渠道失效或多人同时发声 |
2.2 核心理解
7.4 的核心不是“会发通知”，而是让组织在平时和危机时都具备可控的信息传递能力。业务连续性场景中的沟通往往跨越业务、技术、管理、客户、监管和供应商多方，一旦没有预先策划，最容易出现的就是信息延误、版本不一致、内部外部口径冲突，以及关键岗位根本收不到该收的信息。
本条特别强调“五个问题”必须事先想清楚：沟通什么、何时沟通、与谁沟通、如何沟通、由谁沟通。这五个问题看起来基础，但现实里恰恰最容易被忽视。例如系统中断时，技术团队以为业务部门会通知客户，业务部门又以为客服已经收到口径；监管要求一定时限内通报，但内部没人明确谁负责；短信平台在故障期间不可用，却没有替代渠道。7.4 要防的正是这些看似琐碎、实则高风险的断点。
连续性沟通与一般行政通知最大的区别，在于其内容往往直接影响外部信任和内部响应节奏。客户何时知道影响范围，监管何时收到报告，员工何时知道是否启动备用办公，供应商何时进入支援状态，这些都与恢复效率和声誉损失直接相关。因此，沟通机制本身就是连续性能力的一部分，而不是附属动作。
从治理角度看，7.4 也是危机控制力的重要体现。沟通一旦无序，组织即使技术恢复较快，也可能因为错误表述、重复承诺、信息泄露或对外沉默而放大损失。成熟组织会把沟通责任、审批和模板前置准备好，让危机中的表达既快又稳。
三、实施要点
3.1 建立分对象沟通清单
- 明确内部各层级、客户、监管、供应商、合作方和公众沟通需求。
- 不同对象应使用不同内容深度和不同审批规则。
3.2 设计关键节点和升级规则
- 明确何时启动初报、何时升级、何时复报、何时发布恢复通知。
- 避免事件确认和对外通报长期卡在责任模糊环节。
3.3 同时准备主渠道和替代渠道
- 考虑电话、短信、邮件、IM、广播、门户公告等多种方式。
- 对于关键联系人和关键通知，不能只依赖单一渠道。
3.4 用演练验证沟通链条
- 不仅测试技术恢复，也测试联系人是否准确、消息模板是否可用、审批是否顺畅。
- 关注跨部门和外部接口是否存在卡点。
四、常用工具与实施方法
| 工具/方法 | 用途 | 典型输出 |
|---|---|---|
| 沟通矩阵 | 明确对象、内容、时点、渠道和责任人 | 沟通责任表 |
| 联系人清单 | 维护关键内部外部联系方式 | 联络清单及更新记录 |
| 消息模板库 | 提高危机沟通速度和一致性 | 初报、复报、恢复模板 |
| 通报审批机制 | 控制对外口径和授权 | 审批流程和责任分配 |
| 沟通链演练 | 验证触达效率与协同效果 | 测试结果和改进项 |
五、典型案例
案例一：技术恢复了，客户却因为信息缺失持续投诉
某平台企业在一次系统中断后较快完成技术恢复，但客户在数小时内没有收到明确通知，外部舆情迅速升温。复盘发现，组织缺少分对象沟通安排。依据7.4整改后，客户、内部、监管和媒体口径被分层管理，后续事件中的外部反应明显更平稳。
案例二：联系人失效让升级链条断掉
某集团保留了一份多年未更新的联系人表，演练时发现多个关键负责人已离岗，部分号码失效。通过7.4建立定期校验和责任更新机制后，沟通链条的可靠性明显提升。
案例三：供应商未被及时拉入应急响应
某制造企业在设施异常时内部沟通启动较快，但因未预设供应商通报规则，关键外部维修资源迟迟未到。后续依据7.4补建供应商沟通触发机制和责任分工，使外部支援效率得到改善。
在连续性场景中，沟通失误的成本往往被低估。一次错误的对外表述可能引发不必要的恐慌，一次延迟上报可能错失监管时限，一次内部通知不清可能导致错误动作被大量复制。因此，沟通条款本质上是在帮助组织管理“信息造成的次生风险”。
很多组织会在技术演练中投入大量精力，却很少真正测试沟通链路。结果就是技术团队知道怎么切换系统，但管理层不知道何时发声，客户团队不知道怎么解释，供应商不知道何时到位。7.4 提醒组织，危机中的恢复不仅是系统恢复，也是信息秩序的恢复。
本条还特别适合与7.3意识、8.4计划和8.5演练形成联动。意识决定大家是否知道要按规则沟通，计划规定沟通角色和模板，演练验证沟通是否可行。三者打通后，沟通才不会停留在联系人表层面。
审核检查7.4时，通常会追问的不只是“有没有沟通程序”，更包括最近一次计划更新、演练或事件中沟通是如何执行的，联系人是否有效，对外通报是否有授权机制。这些问题都指向一个核心：沟通是否真正受控。
因此，7.4 的深层价值，是让组织在压力和不确定性最高的时候，仍能维持清晰、及时、一致的信息流。信息流稳，组织控制感才稳。
值得补充的是，沟通还涉及保密与透明之间的平衡。对外过度沉默可能损害信任，过度披露又可能引发误读、监管风险或安全问题。7.4 的成熟实施，不是让组织“说得越多越好”，而是让组织在合适时间以合适粒度说正确的话。
对于跨地域和多语言环境的组织，沟通策划还应考虑时区、语言和渠道习惯差异。否则总部已经发布了关键信息，现场却因为语言或时间差未能及时接收，仍然会形成实质性沟通失效。
最终，7.4 管的是组织在不确定情境下维持信息秩序的能力。谁知道什么、谁何时发声、谁来确认口径，如果这些都被提前设计清楚，危机中的很多次生损失本来就是可以避免的。
一套成熟的沟通机制，往往能让组织在外部看来更稳定、在内部看来更可控。因为当信息流稳定时，人员更容易保持判断一致，客户和监管也更容易感受到组织仍处于受控状态。
这也是为什么许多真实事件复盘最后都会回到沟通机制本身。技术故障可以修复，但如果没有提前设计沟通规则，组织很难在最紧张的时刻同时兼顾效率、准确性与一致性。
六、成文信息管理要求
- 保留沟通矩阵、联系人清单、职责分工和沟通渠道安排。
- 保留消息模板、审批规则、监管或客户通报要求及更新记录。
- 保留沟通演练、抽查、真实事件通报和复盘证据。
七、常见误区及踩坑提醒
| 误区 | 表现 | 正确做法 |
|---|---|---|
| 把沟通理解为发通知 | 只考虑渠道，不考虑时点和责任 | 系统设计对象、内容、时点、渠道和责任人 |
| 只准备单一渠道 | 主渠道故障时通知失效 | 建立替代沟通方式 |
| 联系人长期不更新 | 关键时刻找不到人 | 设定定期维护和抽查机制 |
| 对外口径无人审批 | 信息冲突或过度承诺 | 明确授权和审核机制 |