一、ISO/IEC 27001:2022 6.1.3 标准原文

二、条款解读说明

2.1 风险处置不是默认“全部整改”

很多组织在看到高风险后，第一反应是“把控制补上”。这当然常常是正确方向，但标准要求的风险处置并不只有一种路径。常见处置选项包括降低风险、规避风险、转移风险和接受风险。在信息安全场景下，可能对应实施新控制、调整业务模式、引入保险或外部服务、在明确边界下接受残余风险。关键不在于是否“全做”，而在于是否经过充分评估并由正确层级批准。

风险处置最大的管理价值，在于把抽象风险变成可执行动作。评估阶段只是在识别和排序，处置阶段才真正涉及控制设计、责任安排、预算、时限和效果验证。因此，6.1.3是风险管理从“认识问题”走向“解决问题”的核心条款。

2.2 条款关键输出拆解

2.3 如何正确理解附录A和适用性声明

附录A不是一张必须全部勾选“适用”的控制菜单，而是一份控制参考目录。组织应根据自身风险情况、业务场景和管理要求选择控制，并解释为什么适用或不适用。适用性声明的价值也不只是审核用途，它实际上是一份“控制决策说明书”，帮助组织解释自己为什么选这些控制、为什么不选那些控制，以及这些控制如何对接风险处置逻辑。

三、实施要点

3.1 先确定处置策略，再谈控制设计

• 对每个需处理风险明确是降低、规避、转移还是接受，不要直接跳到具体整改动作。
• 对高风险和高成本事项要比较多个处置选项，说明为何选择当前方案。
• 处置策略需与风险接受准则和业务现实相匹配。

3.2 把控制措施写成可执行动作

• 控制措施应明确责任人、时限、资源、依赖条件和验证方式。
• 避免只写“加强管理”“完善流程”这类抽象表述。
• 技术控制、管理控制和组织控制应结合使用。

3.3 做好附录A对照分析

• 对照附录A时关注风险是否已被充分覆盖，而不是只追求“表格填满”。
• 若某项控制不适用，应写清不适用原因和边界。
• 如果组织采用了附录A之外的控制，也应在处置逻辑中说明。

3.4 形成高质量适用性声明

• SoA中应至少包括控制清单、适用性结论、选择理由和实施状态。
• SoA应与风险评估、控制实施和审核抽样保持一致。
• 每次重大风险、控制或范围变化后，都要考虑是否更新SoA。

3.5 明确残余风险接受机制

• 控制做完后仍可能存在残余风险，应由适当层级的风险所有者进行接受。
• 接受前应说明残余风险水平、补救计划和复核时点。
• 不要让安全部门代替业务或管理层默许风险。

四、常用工具与实施方法

五、典型案例

案例一：企业用SoA纠正“控制想当然”问题

1. 背景：企业风险评估后补了大量控制，但多年没人梳理其选择依据。
2. 问题：审核时无法解释为什么某些控制缺失、某些控制又重复建设。
3. 6.1.3动作：重做附录A对照和SoA，逐项解释适用性和当前实施状态。
4. 结果：控制体系更清晰，后续审计和改进更有抓手。
5. 启示：SoA不是附件，而是控制决策地图。

案例二：制造企业明确残余风险接受责任

1. 背景：某些老旧设备无法在短期内完成全面加固。
2. 问题：安全团队长期背负风险，但业务继续运行。
3. 6.1.3动作：建立由业务负责人、设备负责人和管理层共同参与的残余风险接受机制，并设定阶段性补偿控制。
4. 结果：风险责任回到业务链条，同时改造计划更可执行。
5. 启示：接受风险不是放弃管理，而是明确承担边界。

案例三：SaaS企业把供应链风险处置做成组合方案

1. 背景：企业多个第三方服务商涉及日志、监控和支付环节。
2. 问题：原计划只要求供应商签保密协议，处置力度不足。
3. 6.1.3动作：组合采用合同加严、访问控制、定期审查和监控补强等多种措施。
4. 结果：供应链风险下降，客户审计更易通过。
5. 启示：风险处置常常是控制组合，而不是单一动作。

六、成文信息管理要求

6.1.3涉及多项明确输出，尤其是风险处置计划和适用性声明，因此审核时通常会重点检查文档逻辑是否完整、版本是否一致、记录是否能支撑当前控制状态。

七、常见误区及踩坑提醒