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

二、条款解读说明

5.2.3是27701:2019中非常具有操作性的条款，因为它直接把“PIMS到底覆盖什么”这个问题拉到了台面上。很多组织原本已有 ISO/IEC 27001 管理体系范围，可能写的是若干组织单元、业务系统、办公场所或数据中心。当这些组织开始建设 PIMS 时，最常见的误判就是认为只要沿用原有 ISMS 范围即可。27701 通过 5.2.3 明确指出，这种想法并不一定成立。只要 PII 处理活动的实际边界与原有信息安全范围不完全一致，组织就必须重新审视并可能修改原有范围。

“将 PII 的处理纳入其中”这句话看似简单，实际意味着范围界定必须从“管理哪些资产和系统”进一步扩展为“管理哪些 PII 处理活动、涉及哪些角色、覆盖哪些系统和流程、适用于哪些合同与法域”。隐私体系的对象不是抽象的组织架构，而是组织在不同业务场景中具体收集、使用、共享、传输、保留、删除和披露 PII 的行为。范围一旦写不到这一层，就很难解释清楚哪些条款适用、哪些记录应保留、哪些审计样本应抽查。

条款中的注释非常关键，它指出因为 5.1 对“信息安全”做了扩展解释，所以 PIMS 的范围可能需要修改原有 ISMS 的范围。这个提醒实际上是在防止一种很常见的“假升级”：组织沿用旧的安全范围文本，只在标题或引言里加一句“兼顾隐私”，却没有真正把 PII 处理活动纳入边界。例如，原本 ISMS 只覆盖总部核心信息系统，但企业实际还通过营销平台、客服工具、HR 外包、人脸门禁、访客登记和第三方 SaaS 处理大量 PII。如果这些活动没被纳入范围，即使组织后面写了很多隐私制度，PIMS 仍然是不完整的。

5.2.3还要求组织在范围精确和范围可执行之间取得平衡。范围写得过宽，文件可能看起来宏大，但实际控制落不下去；范围写得过窄，则容易只覆盖“最好做的部分”，把高风险处理活动排除在外。条款并没有要求所有组织一步到位覆盖所有 PII 处理，但它要求当前范围是真实的、清楚的，并能够说明纳入和排除的逻辑。只有这样，PIMS 才能被理解为可审计的管理体系，而不是一份表态性文件。

从项目实施顺序看，5.2.3通常是 5.2.1 和 5.2.2 的汇总输出。组织先识别角色和环境，再看相关方和要求，最后才能真正画出边界。因此，范围文件最好不是孤立写出来的，而是能够追溯到角色识别、相关方分析和业务场景盘点的结果。这样的范围才经得住审核追问，也经得住后续变更。

对于大型集团或跨区域组织来说，5.2.3还有一个现实难点，就是范围通常不可能一夜之间覆盖所有处理活动。更成熟的做法不是含糊地宣称“全集团适用”，而是明确当前阶段先覆盖哪些高风险或高重要性场景、哪些区域和流程后续纳入、为什么这样安排。只要边界真实且可解释，阶段性范围同样可以是合格的；真正危险的是范围文件写得很大，实际谁也说不清到底管到了哪里。

三、实施要点

• 以 PII 处理活动为核心来界定范围，而不是仅按组织架构、地点或主系统划线。
• 检查原有 ISMS 范围与实际 PII 处理边界是否一致，如不一致，应明确扩展或重述。
• 在范围文件中说明角色场景、纳入活动、主要系统和排除逻辑，避免只写一句空泛声明。
• 将新SaaS引入、分包调整、跨境变化和重大业务变更设为范围复核触发条件。
• 5.2.3的关键词是“PII处理活动”，缺少这一层，范围通常就是不完整的。

四、常用工具与实施方法

实践中，把范围写成“组织单元+处理活动+主要系统+角色场景+排除说明”的组合结构通常最有效。这样既便于管理层理解，也方便审核员抽样验证，更适合在组织扩展业务时逐步更新。

五、典型案例

1. 只按部门写范围的失效案例：某企业在范围文件中写明“本体系适用于总部信息技术部和客服中心”，但没有说明这些部门具体处理哪些 PII，也没有纳入营销自动化工具和访客管理平台。审核时一旦抽到这些场景，组织很难解释为何不在范围内。重做 5.2.3 后，企业改为按处理活动和系统表述范围，边界才真正清楚。
2. 多角色企业的统一范围问题：某组织既处理自有员工和会员数据，又受客户委托托管终端用户数据。开始时只写了一份统一范围，导致合同、主体义务和分包义务全混在一起。通过 5.2.3 重构后，组织在同一份范围中区分了控制者场景与处理者场景，后续控制设计顺畅很多。

这些案例说明，5.2.3的价值并不在于让组织写出更长的范围声明，而在于让边界与真实 PII 处理现实一致。边界准确，后续条款才有抓手；边界模糊，后续再多制度也会悬空。

六、成文信息管理要求

这些文件最好保持版本化管理，并与重大变更评审和管理评审联动。只要 PII 处理现实变了，范围就有可能需要调整；如果范围长期不变，通常意味着它已经脱离实际业务。

七、常见误区及踩坑提醒