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

二、条款解读说明

5.2.2在27701:2019中的意义，远不止是扩充一张相关方清单。它把 ISO/IEC 27001:2013 第4.2 原本较为通用的相关方分析，明确拉进了隐私处理语境之中。最值得关注的一点，是条款明确要求将 PII 主体纳入相关方范围。这一要求直接改变了很多组织对管理体系的理解方式：PIMS 不再只是为了响应监管机构或客户审计，也不是只服务于组织自身风险控制，它必须同时回应 PII 主体作为受影响对象所提出或应受到尊重的期待。

这一变化会对后续条款产生很强的牵引作用。只要 PII 主体被纳入相关方，组织就不能只按合同视角理解隐私治理。即使某个主体从未直接与组织签约，也不意味着其需求可以不进入体系。主体可能关心自己是否被适当告知、能否访问和更正信息、是否能撤回同意、是否能反对特定处理、是否会受到自动化决策影响，以及一旦发生事件是否会被适当通知。5.2.2把这些需求前置到相关方识别阶段，是为了确保 PIMS 后续流程不会只围着监管或客户打转。

条款中的注释也很值得重视。它明确提出相关方要求的来源可能是法律法规、合同义务和组织自行设定的目标，而 ISO/IEC 29100 中的隐私原则可为 PII 处理提供指导。这意味着相关方分析不能只是“把人列出来”，还要进一步回答这些要求来自哪里、对体系意味着什么、组织准备用哪些条款和流程去回应。没有这一层分析，相关方识别就很容易变成形式化表格，既指导不了制度设计，也支撑不了审核问答。

5.2.2还具有明显的角色差异意义。在控制者场景下，组织通常需要更直接地面对 PII 主体和监管要求；在处理者场景下，客户和上游控制者的合同要求、尽调要求和审计支持要求则会更突出。但不管角色如何变化，条款都提醒组织不要遗漏与 PII 处理有关的任何关键相关方。尤其在多层供应链和分包链条中，如果组织只识别自己最熟悉的客户关系，而忽视监管方、主体和上游下游处理链，后续很多通知和记录义务都会在接口处出问题。

从体系建设看，5.2.2的输出直接决定后续范围、目标、沟通和审核重点。如果相关方识别只停留在“客户、员工、监管、供应商”这种宽泛分类，而没有把 PII 处理场景与需求拆清楚，PIMS 很快就会变成“谁声音大就先回应谁”的临时治理模式。条款的真正价值，就在于把这些需求系统化、条款化、可追踪化。

审核实践也反复证明，相关方分析做得越具体，后续体系越容易回答追问。因为审核员往往不会满足于看一张名单，而会继续问“你们为什么认为这个主体是相关方”“它的要求由谁承接”“如果要求变化，体系怎么更新”。5.2.2写得实，正是为了让这些问题在体系设计阶段就有答案。

这也是为什么 5.2.2 不应只由合规或法务团队单独完成。很多相关方期待其实分散在客服投诉、客户尽调、供应商协作、审计发现和产品交付场景里，只有跨部门共同梳理，组织才能真正把“外部声音”转成可执行的体系要求，而不是停留在原则层面。

三、实施要点

• 先围绕 PII 处理活动梳理相关方，而不是从传统组织关系表中直接抄名册。
• 把 PII 主体作为独立相关方分析，不要简单并入“客户”或“公众”。
• 对每类相关方识别其需求来源，是法律、合同、监管要求还是组织承诺。
• 明确哪些需求由 PIMS 承接，哪些由其他管理机制承接，避免体系边界含混。
• 5.2.2的重点不是列名单，而是让需求真正进入体系。

四、常用工具与实施方法

实际操作中，建议把相关方分析做成“对象+要求+来源+承接方式”四列表，而不是只列对象名称。这样一来，5.2.2的输出就能直接接入 5.2.3 范围、5.4 风险规划和后续运行控制，而不是停留在项目资料里。

五、典型案例

1. 只看客户不看主体的企业：某组织在PIMS建设初期把相关方主要定义为客户和监管机构，对 PII 主体需求几乎没有单独分析。结果体系文件很重合同和审计，却对主体权利响应、告知质量和投诉管理缺乏投入。补做 5.2.2 后，组织才真正把主体需求纳入体系。
2. 处理者场景下忽略供应链伙伴：某云服务商一直把“客户”视为唯一关键相关方，没有把上游平台、下游分包方和监管接口纳入分析。后来在分包变更和数据返还时频繁出现边界冲突。回到 5.2.2 重新识别相关方后，合同与流程才被梳理清楚。

这些案例说明，相关方分析不是一份可有可无的前置文件，而是后续体系有效性的根源。只要相关方看窄了，后面的控制就很难真正回应外部期待。

六、成文信息管理要求

这些材料的价值，不只是满足审核员要看文件，而是帮助组织在面对新的合同模板、监管解释、投诉热点或业务变化时，快速判断是否需要调整 PIMS 的条款承接和流程设计。

七、常见误区及踩坑提醒