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

二、条款解读说明

如果说 5.4.1.2 负责让组织看见风险，那么 5.4.1.3 负责让组织把看见的风险转化成控制方案。它沿用了 ISO/IEC 27001:2013 6.1.3 的风险处置框架，但在 PIMS 中加上了三个非常关键的要求：第一，控制选择不能只看 27001 附录A，还要与 27701 附录A和/或附录B进行比较；第二，控制适用性判断时，必须同时考虑信息安全风险、PII 处理风险和 PII 主体风险；第三，组织要通过适用性声明把控制采用和排除的理由写清楚，且理由需要体现其角色定位。

这三个要求之所以重要，是因为 PIMS 的控制集本来就不是单一来源。27001 附录A更多提供基础信息安全控制，27701 附录A则针对 PII 控制者场景补充或修订隐私相关控制，附录B则针对 PII 处理者场景补充或修订控制。如果组织只沿用原有 ISMS 的控制清单，很容易出现“安全控制不少，但隐私控制没进来”的情况。例如，主体请求、共享透明度、处理范围边界、返还删除、分包商限制、代表客户处理数据的义务等，都可能因为不在传统安全清单核心位置而被漏掉。

标准要求把已确定的控制与这些附录进行比较，目的并不是强迫组织“全选控制”，而是确保不会因为视角过窄而漏掉必要控制。换句话说，比对是一种完整性检查。组织仍然可以在风险评估和法律要求的背景下判断某些控制不适用，但这种排除必须是经过分析后的排除，而不是因为从未进入视野。对于审核者来说，能否证明组织做过这种完整性比对，往往是判断 PIMS 是否认真建设的重要依据。

5.4.1.3还有一个很强的角色化要求。标准明确提到，根据组织的角色，应说明排除附录A和/或附录B以及 27001 附录A 控制的理由。这意味着组织首先要搞清楚自己在具体处理活动中到底是控制者、处理者，还是两种角色并存。角色判断不清，控制排除理由就很容易失真。比如一个既提供平台服务、又在部分场景自行决定处理目的的组织，如果简单把自己全部归类为处理者，就可能错误排除控制者场景下应建立的透明度和主体权利控制。

适用性声明在这一条中的地位也被显著抬高。很多组织以前把 SoA 当成认证交付件，列一列控制编号和是否适用就结束了。但在 27701 语境下，SoA 不再只是形式清单，它是风险处置逻辑的可审查表达。标准要求其中至少包含必要控制、采用理由、实施状态，以及排除控制的明确理由。也就是说，SoA 应该回答“组织为什么认为这些控制足够、为什么认为那些控制不需要”。如果 SoA 写得含混笼统，例如统一写“业务不适用”，却说不清是基于什么角色、什么风险结论或什么法律背景排除，审核时往往很难站得住。

在控制适用性判断中，标准特别提出要同时考虑信息安全风险、处理 PII 的风险以及 PII 主体的风险。这一点再次说明，风险处置不能只围绕组织自身视角优化成本。有些控制看似增加流程复杂度，但如果能显著降低主体受损风险，组织就不能仅凭实施麻烦就将其排除。反过来，也有些控制在组织当前角色和处理范围下确实不适用，这时就应通过清晰理由说明“为什么不适用”，而不是机械照搬。

从实务看，5.4.1.3 的难点通常不在于“有没有控制”，而在于“有没有经过角色化、风险化、可追溯的控制选择过程”。组织常见的失败不是少做了一张表，而是控制清单与风险评估脱节、SoA 与角色判断脱节、附录比对与实际处理活动脱节。只要这些关系没打通，风险处置就还只是形式动作。

三、实施要点

• 在风险处置阶段同时比对27001附录A和27701附录A/B，确认没有遗漏任何与角色和风险相关的必要控制。
• 将控制适用性判断建立在三类风险基础上：信息安全风险、PII处理风险、PII主体风险。
• 把组织在具体场景中的角色写清楚，再决定控制采用或排除逻辑，避免角色判断模糊。
• 将适用性声明写成“可解释文件”，而不是只填“适用/不适用”的勾选表。
• 5.4.1.3的关键成果是形成一套经得起追问的控制选择依据链。

四、常用工具与实施方法

比较成熟的做法，是先根据风险评估结果列出“理论上需要的控制能力”，再映射到具体附录控制，而不是先拿附录做机械勾选。这样组织更容易看清自己到底是在解决哪类风险，也更容易向管理层解释为什么某些控制必须投入资源。

在 SoA 编写上，建议为每个被排除的关键控制都至少写明三件事：排除依据、角色背景、替代或补充安排。这样即使未来业务变化，也能快速判断原先的排除理由是否仍然成立，不会让 SoA 变成一份无人维护的静态文件。

五、典型案例

1. 只保留原ISMS SoA，遗漏隐私控制：某服务商在建设 PIMS 时直接复用原有 27001 适用性声明，只加了一列“已考虑27701”。审核时发现其中没有体现分包控制、返还删除和客户指令边界等处理者控制。问题不在 SoA 文件本身，而在 5.4.1.3 要求的附录比对根本没有真正发生。
2. 排除理由写得太空：某组织将多个控制统一标为“不适用，业务无相关场景”，但无法说明是因为当前角色不是控制者、当前处理范围不涉及该活动，还是已有其他控制等效覆盖。后来重写 SoA，把角色、风险结论和法律背景全部补入，控制排除才真正具备可解释性。

这两个案例说明，风险处置的质量不取决于表格是否漂亮，而取决于组织能否把风险评估、角色判断和控制选择串成一条完整证据链。只要这条链断掉，SoA 再完整也只是表面文章。

从文章质量角度看，5.4.1.3最值得写透的是“为什么适用性声明在27701里比在普通ISMS里更重要”。答案就在于：它不仅解释安全控制，还解释隐私控制；不仅解释是否采用，还解释角色化排除；不仅面对认证审核，还常常直接关系到客户信任和外部尽调。

六、成文信息管理要求

对于高风险或高敏感场景，建议把“排除某控制的理由”写得比普通场景更充分，因为这些地方最容易在审核、客户审查或事件复盘中被追问。只要排除理由能追溯到风险评估、角色判断和法律背景，组织的解释就会更稳。

七、常见误区及踩坑提醒