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

二、条款解读说明

5.6.2是风险评估方法进入运行阶段后的延伸条款。前面的 5.4.1.2 解决的是评估对象、评估逻辑和影响分析方式，而这一条解决的是时间性问题。也就是说，组织不仅要会评估，还必须知道何时重新评估。对 PIMS 而言，这一点尤其关键，因为隐私风险很少长期保持不变。业务目的会扩展，数据字段会增加，供应链会变化，技术架构会迁移，自动化能力会增强，处理角色也可能发生切换。如果风险评估只在体系建立时做一次，就等于默认这些变化都不会改变隐私后果，这显然不现实。

2019版在这里沿用了 27001 第8.2，但通过 5.1 扩展解释把运行期风险评估对象扩展到了 PII 处理场景。换句话说，运行期重评不只是看传统的保密性、完整性和可用性风险，还要重新审视处理活动对 PII 主体和组织造成的不利后果是否发生变化。组织若只保留技术层面的重评，而不把用途变化、共享边界变化、保留策略变化或主体影响变化纳入视野，那么它只是做了半套评估。

运行期重评最常见的误区，是只把“重大变更”理解成大项目上线。实际上，许多影响很大的隐私变化看上去并不宏大。例如营销活动临时增加一个可识别字段、测试环境接入了一份真实样本、日志保留时间从 30 天改到 180 天、客服系统新增外包接入、原本人工审核的决策开始由模型辅助筛选，这些都可能显著改变风险状况。若组织没有明确触发标准，很多团队会本能地把这些变化理解成“普通调整”，从而绕开重评。

5.6.2还要求风险评估继续使用既定的准则。这一点非常重要，因为运行期常有不同团队、不同阶段参与评估，若没有统一准则，结果就会失去可比性。今天某项处理活动被判断为中风险，明天类似活动却被另一个团队判断为低风险，组织既无法比较，也无法向管理层解释资源为什么这样分配。只有保持方法和准则一致，运行期重评才具备治理价值。

与 5.4.1.2 相比，5.6.2 更强调“动态性”。它不再主要讨论怎样识别信息安全风险和隐私风险，而是要求组织把这种识别动作做成一个持续机制。成熟组织通常会把重评嵌入项目立项、架构评审、采购准入、重大变更审批和事件复盘流程，让风险评估随变化自动触发。反之，若风险评估永远只能靠隐私团队单独推动，它就很难跟上业务速度。

因此，5.6.2的实务重点并不是表格设计得多复杂，而是组织是否建立了按周期、按变化、按异常进行重评的节奏。只要这种节奏存在，PIMS 的风险认知就不会迅速过期；如果没有，再完善的初始评估也会很快失去现实意义。

三、实施要点

• 区分计划性重评和触发式重评，让风险评估既有固定节奏，也能响应重大变化。
• 明确“重大变更”判断标准，不要把触发条件交给个人主观感受。
• 将5.4.1.2确定的方法和准则延续到运行期，保持结果可比较、可解释。
• 把事件、投诉和审计发现也视为重要重评触发源，而不只是看正式项目变更。
• 5.6.2的本质是让风险评估跟着现实变化走，而不是停在体系建立那一刻。

四、常用工具与实施方法

实践中，组织不一定需要对所有变化都做同等深度的评估。更可行的方法是先做快速筛查，判断是否达到重大变更门槛；只有达到门槛的场景再进入更深入重评。这样既能保证效率，也能防止高风险事项被轻易放过。

对于变更频繁的产品型组织，把重评触发逻辑嵌入需求和变更系统会比单独发邮件更有效。流程自动触发，通常比依赖人工记忆更稳定。

五、典型案例

1. 新增用途未触发重评：某平台原本只用用户信息提供服务，后续增加营销画像用途，但内部认为“数据还是同一批数据”，没有重评。上线后才发现主体影响明显变化。若按 5.6.2 建立用途变更触发规则，这类风险本可在运行前识别。
2. 外包切换后风险等级失真：某处理者更换了客服外包商，业务觉得只是执行团队变了，不需要重评。结果新的外包方式引入了更多跨境访问和人工导出环节，风险显著上升。问题并不在原评估错误，而在运行期没有及时重评。

这类案例说明，运行期风险评估的价值不是重复劳动，而是确保风险认知始终贴着当前现实。只要业务现实变了，风险评估就不能还停留在旧版本。

六、成文信息管理要求

这些文件能帮助组织证明：重评并不是偶然发生，而是被计划和被触发地发生。对审核而言，这种规律性证据通常比单次高质量评估更能说明体系成熟度。

七、常见误区及踩坑提醒