一、ISO/IEC 27701:2019 5.2.4 标准原文
原文摘要：ISO/IEC 27001:2013 第4.4的补充要求是：组织应根据本标准第5章扩充后的 ISO/IEC 27001:2013 第4章至第10章要求，建立、实施、维护并持续改进 PIMS。
二、条款解读说明
5.2.4是在 5.2.1、5.2.2 和 5.2.3 的基础上，把“角色、相关方、范围”这些前置输入正式收束为管理体系要求。也就是说，前面三条是把现实看清楚，这一条则要求组织把这些现实输入组织成一套可以持续运行、持续验证、持续改进的 PIMS。它与 27001 第4.4的关系非常直接：27701并没有另造一个新的管理体系定义，而是要求组织按照经第5章扩充后的 ISO/IEC 27001 第4章至第10章来建立 PIMS。这意味着 PIMS 不是平行于 ISMS 的第二套体系，而是建立在 ISMS 逻辑上的隐私扩展体系。
这一条最容易被误读成“体系要持续改进”这样的管理套话。实际上，它有非常具体的管理含义。第一，组织要有明确的 PIMS 过程设计，包括环境识别、相关方识别、范围、风险、运行、审核、管理评审和改进之间的连接关系。第二，这些过程不能只存在于文档上，还要进入真实业务活动，例如合同评审、系统变更、供应商引入、主体请求处理、事件响应和数据返还处置。第三，组织要能够通过记录、审核、评审和纠正措施证明 PIMS 是活的系统，而不是为了认证搭建的一套资料架子。
| 5.2.4关键词 | 在PIMS中的含义 | 常见失效表现 |
|---|---|---|
| 建立 | 基于扩展后的27001条款设计PIMS结构和过程 | 只有制度清单，没有体系架构 |
| 实施 | 把隐私要求嵌入日常处理活动和支持流程 | 文件齐全但现场流程不按其运行 |
| 维护 | 通过记录、职责和复核让体系持续运转 | 项目结束后长期无人维护 |
| 持续改进 | 根据风险、投诉、事件、审核和变化不断调整 | 每次只在审核前集中补材料 |
5.2.4还有一个关键含义，就是它要求组织按“扩展后的第4章至第10章”来理解整个体系。这意味着 PIMS 不是只从 5.2 开始，后面 5.3 至 5.8 的领导、规划、支持、运行、绩效评价和改进都会进入体系定义。很多组织在实施时，过度把目光集中在角色控制和附录条款上，却没有把这些控制接入管理评审、内部审核、能力建设和纠正措施流程。结果制度看起来很隐私，体系却不稳定。5.2.4存在的意义，就是防止这种“隐私控制很热闹、管理体系很薄弱”的状态。
从治理成熟度看，5.2.4也是“专项项目”和“长期能力”的分界线。项目化思维通常会把隐私治理理解为一次性差距整改：补政策、补合同、补台账、补同意文本。体系化思维则会追问：新业务出现时谁来判断角色？新分包方启用时谁来更新记录？主体请求量增加时谁来评审流程负荷？监管要求变化时谁来调整控制？如果这些问题在组织内都能找到固定过程和责任人，PIMS 才算真正建立。
对已有 ISMS 的组织来说，5.2.4 的最佳实践通常不是另起炉灶，而是在现有管理体系流程中增加隐私输入、隐私输出和隐私验证点。例如在管理评审中增加 PII 处理绩效、在内部审核中增加角色适用性检查、在变更管理中加入 PII 影响评估、在供应商管理中加入分包和返还要求。这样做既能复用现有体系，又能确保隐私不是漂浮在体系之外的附加议题。
也正因为如此，5.2.4常常是审核中最容易暴露“形式化建设”问题的条款。制度写得再漂亮，如果无法说明这些制度如何进入流程、谁负责维护、出现偏差后如何被纠正，就很难证明 PIMS 已被真正建立。把体系做成可运行、可解释、可追溯的组织能力，才是本条最核心的要求。
三、实施要点
- 先画出 PIMS 主流程，明确环境、范围、风险、运行、审核和改进的接口关系。
- 不要把隐私制度单独挂在合规部门名下，而要让其进入合同、变更、开发、采购、客服和事件管理等真实流程。
- 在现有 ISMS 机制中嵌入隐私输入和证据要求，而不是复制一套完全平行的体系。
- 为 PIMS 明确维护责任人和跨部门协调机制，避免项目收尾后体系失去推动者。
- 5.2.4的关键不是“有多少文件”，而是“这些文件是否组成了一个会运转的体系”。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| PIMS过程图 | 识别体系过程及其相互作用 | 体系流程图 |
| 条款-流程承接矩阵 | 确认扩展后的27001条款由哪些流程承接 | 承接关系矩阵 |
| 职责分配表 | 明确各部门在PIMS中的职责和接口 | RACI或职责清单 |
| 运行证据目录 | 证明PIMS不是停留在制度层 | 审核和评审用证据索引 |
实践中，最有效的做法往往不是先写大量制度，而是先确认“哪几个核心流程必须先跑起来”。通常包括角色识别、风险评估、主体请求处理、事件响应、供应商评审和管理评审。只要这些核心过程成形，后续制度和证据就更容易稳定积累。
五、典型案例
- 制度很多但体系不运行：某企业为准备隐私认证编写了十多份隐私制度，但没有把这些制度与现有 ISMS 的审核、评审和纠正措施流程连接起来。结果文件齐全，现场却很难说明由谁维护、何时更新、如何验证。依据 5.2.4 重整后，企业先建立 PIMS 主流程，再把原有制度纳入流程管理，体系才真正运行起来。
- ISMS升级为PIMS的成功案例：另一家组织已有成熟 ISMS，起初担心建立 PIMS 需要完全另做一套体系。通过 5.2.4 梳理发现，其实更可行的路径是复用原有管理评审、内部审核和纠正措施框架，再叠加角色识别、主体请求、合同与分包控制等隐私输入，最终以较低成本完成体系升级。
这些案例说明，5.2.4最重要的不是多建一套文件结构，而是把扩展后的条款真正嵌入组织已有治理机制。只有这样，PIMS 才会是长期能力，而不是一次性整改项目。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| PIMS过程说明 | 主要过程、接口关系和责任分工 |
| 条款承接矩阵 | 扩展后的27001条款如何落到流程、制度和记录 |
| 运行记录目录 | 风险、事件、请求、审核、评审和改进证据 |
| 体系维护机制文件 | 更新周期、责任安排和持续改进要求 |
这些文件应能共同证明一件事：PIMS 不只是“写出来”，而是“运行着”。对审核员来说，最有说服力的通常不是制度目录，而是能否拿出过程图、样本记录和闭环证据，说明体系真的在组织中运转。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 把PIMS等同于制度汇编 | 文件很多，流程之间没有连接 | 按扩展后的27001条款建立体系过程 |
| 只做项目化整改 | 审核前集中补资料，之后无人维护 | 建立持续维护和持续改进机制 |
| 完全平行建设第二套体系 | 与现有ISMS割裂，职责冲突 | 优先在既有ISMS骨架上嵌入隐私要求 |