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

二、条款解读说明

5.4.1.2是 27701:2019 最能体现其“隐私扩展标准”身份的条款之一。它没有简单地说“沿用 27001 的风险评估即可”，而是明确要求在 PIMS 范围内，同时应用信息安全风险评估流程和隐私风险评估流程。这个表述背后包含两层意思。第一，传统的信息安全风险评估依然必要，因为 PII 处理依赖的信息系统、接口、终端、备份、日志和访问控制仍然面临保密性、完整性和可用性方面的威胁。第二，单靠这类评估并不足以覆盖 PII 处理本身带来的风险，例如过度收集、目的漂移、共享边界模糊、保留过长、主体权利无法实现、分包失控或缺乏透明度等。

也正因为如此，标准没有把“隐私风险”视为安全风险的一个注脚，而是把它明确写成需要独立识别的对象。很多组织以前做 27001 风险评估时，喜欢围绕资产、威胁和脆弱性展开，重点放在系统是否被攻破、数据是否丢失、服务是否中断等方面。这种方法当然重要，但到了 PIMS 里，如果仍然只沿用这套框架，就会看不见大量并非由攻击造成、却同样可能严重影响 PII 主体的风险。比如在没有任何安全事故的情况下，组织也可能因为处理目的超出预期、共享对象界定不清、权利请求流程失效或删除机制无效，而对个人造成明显不利影响。

标准特别强调，组织应在整个风险评估过程中确保信息安全与 PII 保护之间的关系得到适当管理。这句话很重要，因为现实中的很多高风险场景，恰恰不是“纯安全”或“纯隐私”问题，而是两者叠加。例如，一个权限设计失当的问题，既是信息安全控制缺陷，也可能导致无授权披露；一项保留策略过长的安排，本身是处理治理问题，但也会在发生泄露时显著放大受影响范围；一套主体请求流程如果身份核验薄弱，同样会把隐私响应变成新的安全暴露点。标准要求管理两者关系，本质上是在提醒组织避免分头评估、彼此脱节。

2019版在这里给出了一个非常务实的注释：组织既可以应用整合的信息安全和隐私风险评估流程，也可以使用两个独立流程。标准并不强制方法统一，但强制结果可管理。这意味着组织在方法设计上有灵活度，在治理责任上没有灵活度。大型组织如果已有成熟的安全风险体系，可以选择在此基础上增加隐私维度；而对处理活动复杂、法域要求多样或客户合同差异很大的组织，也可以建立更细颗粒度的隐私风险流程。关键不是流程数量，而是两类风险是否都被看到、相互影响是否被解释清楚、结果是否能进入后续处置。

另一个非常关键的新增要求，是当识别出的风险可能发生时，组织应评估其对组织和 PII 主体的潜在后果。这一点使 27701 的风险方法明显不同于只关注企业自身损失的传统管理思路。组织当然要评估自身面临的罚款、合同争议、声誉受损、运营中断或整改成本，但这还不够。它还必须思考，风险一旦实现，个人可能会遭遇什么。例如身份冒用、财务损失、骚扰、歧视、不公正对待、医疗或就业机会受影响、行踪暴露、重大不便或持续心理压力。只有把这些后果真正纳入分析，风险等级才有说服力。

实务中，5.4.1.2最容易出问题的地方有三个。第一，组织形式上做了“隐私风险评估”，但仍然只沿用原有安全评估项，导致隐私只是换了个名字。第二，组织虽然新增了隐私评估表，但没有解释它与信息安全风险评估如何衔接，最终出现两个结论彼此冲突、责任人也不同步。第三，组织会写“评估对组织和个人的影响”，但对个人影响只停留在笼统表述，没有进入实际分级标准。只要存在这些问题，评估的治理价值就会显著下降。

因此，5.4.1.2要写透，不能只强调“要做评估”，而要写清楚四件事：为什么必须同时看到两类风险，为什么两类风险之间要建立关系管理，为什么后果必须包含 PII 主体视角，以及为什么评估结果必须足够具体，才能支撑后续的风险处置和控制选择。对读者而言，这才是这一条真正的实务含义。

三、实施要点

• 在 PIMS 范围内同时识别信息安全风险和隐私风险，不要用其中一类替代另一类。
• 为两类风险建立统一的衔接规则，说明何时合并评估、何时分别评估、何时升级处理。
• 在风险后果分析中同时评价组织后果和 PII 主体后果，避免只看监管处罚或业务损失。
• 让风险分级标准能够解释“为什么这个场景对个人影响更高”，不要只给抽象分数。
• 5.4.1.2的核心突破是把主体影响正式纳入管理体系的风险评估逻辑中。

四、常用工具与实施方法

在方法设计上，比较成熟的组织通常会先问两个问题。第一，这个处理活动本身会不会因为目的、范围、共享、保留、透明度或主体响应设计不当而造成隐私风险。第二，即使处理设计本身合理，其支撑系统是否会因为认证、授权、传输、日志、备份、配置或第三方接口问题而引发安全风险。把这两个问题并列起来，很多复杂场景就会变得更容易分析。

如果组织选择使用一套整合方法，建议把“组织影响”和“主体影响”分开打分，再在最终风险等级中说明两者如何合成。这样既能避免只看其中一方，也能让后续处置更有针对性。如果选择双轨流程，则更要规定交叉触发条件，例如“高主体影响必需触发安全控制复审”“重大安全事件必须回看主体影响范围”。

五、典型案例

1. 只做安全评估，遗漏隐私高风险：某平台在上线推荐功能前做了安全评估，结论是访问控制和传输加密都没有问题，因此认为风险可接受。但后续发现该功能会基于历史行为进行高度个性化画像，且用户难以理解用途和退出方式。安全评估没有发现问题，并不代表隐私风险低。补做 5.4.1.2 要求的隐私风险评估后，组织才重新调整了透明度设计和默认设置。
2. 有隐私评估表，却没有关系管理：某医疗服务提供者分别由安全团队和法务团队做两类评估，前者认为风险较低，后者认为风险较高，但双方没有统一口径，也没有共同决定后续处置。直到审核时才暴露出评估脱节。后来组织建立联合评审会，把两类结论并入同一升级机制，风险处置才真正一致。

这些案例说明，5.4.1.2最怕的不是没有表格，而是看见了一半问题。对 PIMS 而言，只看系统安全不够，只看合规文字也不够，只有把处理行为、技术支撑和主体后果放在一起，评估结果才会成为可用的治理输入。

从发布质量角度看，这一条最应避免“概念堆砌”。读者真正需要的是明白：为什么 27701 明确要求同时做两类评估，为什么这不是重复劳动，而是为了看到不同性质的风险，为什么 PII 主体后果不能只在事故发生后才讨论。把这几层逻辑写明白，文章才算真正有价值。

六、成文信息管理要求

对于高风险处理活动，建议额外保留“后果分析说明”，把组织后果和主体后果分别展开记录。这样一来，即使数月后重新复评，团队也能看懂当初为什么做出某个等级判断，而不是只剩一个难以解释的分数。

七、常见误区及踩坑提醒