一、ISO/IEC 27701:2019 5.6.3 标准原文

二、条款解读说明

5.6.3是运行章节里最直接检验执行力的一条。前面的 5.4.1.3 已经帮助组织完成了控制选择、附录比对和适用性声明，这说明组织知道自己理论上应该实施什么控制。但理论正确并不等于风险已降下来。只有在运行期真正把这些控制落地、验证、调整并留下结果，风险处理才算成立。许多组织的风险管理断点就出现在这里：评估认真，处置计划也很完整，但后续推进靠人工催办，控制落地情况不明，残余风险没人明确接受，最终高风险事项在台账里待了很久，却没有真正改变现实。

2019版在这里继续沿用 27001 第8.3，同时通过 5.1 的扩展解释把运行期风险处理对象扩展到隐私场景。也就是说，风险处理不只是打补丁、改配置、补权限，还包括改流程、补合同、调角色、加通知、改模板、补记录、换供应链安排、缩短保留周期、暂停某类处理活动等。很多隐私风险的成因本来就横跨技术、业务和治理层面，因此处置方案常常也是组合性的。若组织仍把风险处理狭义理解为技术整改，很容易只处理表层症状。

运行期风险处理最需要避免的一种错觉，就是把“措施已设计”当成“风险已处理”。例如，组织决定为请求流程增加身份核验规则，但如果工单系统没有改、客服没有培训、升级路径没有测试，那么风险并没有因为制度上写了一条规则而降低。同样，组织决定补充供应商条款，如果合同更新没有签署、现有供应商没有覆盖、分包通知没有执行，风险也依然存在。5.6.3 强调的正是这种从设计到事实的跨越。

残余风险管理也是这一条的重要组成部分。并不是所有风险都能被完全消除，尤其在复杂处理场景、历史系统限制或合同现实约束下，组织常常只能把风险降到某一程度后接受剩余部分。但“接受”必须是明确的管理动作，而不是拖着不做。谁接受、接受依据是什么、接受多久、在什么条件下重新评审，这些都应清楚。否则所谓残余风险，往往只是对未完成整改的另一种说法。

5.6.3 与 5.6.2 也应形成紧密联动。运行期重评如果发现风险升高或新增风险，5.6.3 就必须及时启动新的处置；反过来，处置完成后也应通过复评来确认风险是否真的下降。没有这种往返关系，运行期风险管理就容易割裂成“两套台账”：一套写评估，一套写整改，彼此并不互相验证。

因此，这一条最值得写透的是“结果导向”。风险处理的价值，不在于表格里写了多少动作，而在于能否在运行中看到控制被实现、证据被保留、剩余风险被明确管理。把这层逻辑写明白，读者就会知道为什么 5.6.3 虽然只有短短一句转引，却是执行力最难伪装的条款之一。

三、实施要点

• 将风险处理计划拆成可执行任务，明确责任、时限、依赖项和关闭标准。
• 针对隐私风险采用组合性处置，不要把运行期风险处理狭义理解为技术整改。
• 处置完成后必须验证效果，防止“制度上线”被误认为“风险已降”。
• 对无法立即消除的风险设置明确残余风险接受机制和复审期限。
• 5.6.3的关键是让风险处理从计划状态进入已实施、可验证、可解释状态。

四、常用工具与实施方法

一个成熟做法是将风险处理分阶段管理，例如设计完成、实施完成、验证通过、转入常规运行。这样可以避免组织在中间状态就过早宣称风险已关闭，也更方便管理层理解真实进展。

若风险处理涉及多个部门，建议明确主责方和配合方，并把跨部门依赖前置识别出来。许多运行期处置拖延，并不是没人认领，而是协同依赖没有提前说清楚。

五、典型案例

1. 删除能力补丁式整改：某企业识别出删除请求执行不彻底的高风险后，先后发布了制度、培训和邮件提醒，但底层系统仍无法完整检索和删除关联数据。组织起初把这些动作都记为“已整改”，实际上风险并未降低。直到 5.6.3 层面把系统改造和复测纳入关闭标准，风险处理才真正成立。
2. 分包风险长期被“接受”：某处理者明知现有分包通知机制不充分，却因客户多、合同复杂而长期把问题标记为“暂时接受”。由于没有明确接受人和复审期限，问题被拖了很久。后来重做残余风险审批机制后，管理层才真正看见这个风险并推动解决。

这些案例说明，运行期风险处理最怕“看起来在推进，实际上没有改变”。只要没有明确定义何为落地、何为验证、何为关闭，风险处理就很容易陷入形式动作。

六、成文信息管理要求

这些记录可以帮助组织向审核者、客户或管理层证明：风险处理不是一个模糊过程，而是有计划、有实施、有验证、有结论的完整闭环。缺少其中任何一环，5.6.3 都很难被认为真正落实。

七、常见误区及踩坑提醒