一、ISO/IEC 27701:2019 5.4.2 标准原文
原文摘要：ISO/IEC 27001:2013 第6.2中陈述的要求，以及本标准第5.1条对这些要求的扩展解释，均适用于 PIMS。也就是说，组织应在相关层级设定目标，并规划如何实现这些目标，只是在 27701 语境下，目标的内容与评价方式应体现隐私和 PII 处理治理要求。
二、条款解读说明
5.4.2延用了 ISO/IEC 27001:2013 6.2 的目标管理逻辑，但因为 5.1 已经明确所有相关要求都应在隐私语境下重新解释，因此这里的“信息安全目标”不能再被理解为传统的漏洞数量、设备合规率或可用性指标那一类单纯安全目标。对 PIMS 而言，目标应围绕组织在处理 PII 时希望稳定达到的治理结果展开，例如主体请求的响应质量、处理活动透明度、分包商控制覆盖、保留删除执行率、关键高风险活动的复评闭环率，以及与角色职责相对应的管理绩效。
这条之所以重要，是因为很多组织在做隐私治理时并不缺原则，也不缺制度，真正缺的是“可管理的结果”。如果没有目标，管理层就很难判断体系是否进步，各部门也不知道自己该把哪些事项当作硬约束来推进。标准通过 5.4.2 要求组织设定目标并规划实现路径，本质上是要让 PIMS 从“有理念”变成“有结果”。
| 目标管理要素 | 在PIMS中的体现 | 实务重点 |
|---|---|---|
| 目标内容 | 围绕PII处理控制、主体影响和治理绩效 | 不能只用传统安全指标代替 |
| 目标分解 | 在相关职能和层级上落实责任 | 让业务、法务、采购、技术都能对应目标 |
| 实现规划 | 明确资源、责任人、时限和评价方式 | 避免目标停留在口号 |
| 动态更新 | 根据风险变化和业务变化调整目标 | 保持目标与现实问题同步 |
在 2019 版中，这一条没有像 2025 版那样单独把“隐私目标”写成一个显性标题，但这并不意味着目标可以不体现隐私内容。恰恰相反，由于 2019 版是通过“扩展解释”的方式把 27001 目标条款引入 PIMS，实施者更需要主动完成语义转换。换言之，组织若只保留原 ISMS 目标体系，却没有任何目标反映主体请求、处理边界、共享控制、分包管理或保留删除等内容，就很难说明自己真正按照 27701 的要求做了扩展。
5.4.2还有一个经常被忽略的重点，即目标不是越多越好，而是要与风险和角色现实相匹配。控制者和处理者的目标重点不会完全相同。控制者可能更重视告知完整度、主体请求闭环、高风险活动评审和共享透明度；处理者则更关注客户指令落实、分包限制、事件通知时效、返还删除执行和处理范围边界。若组织不区分角色，目标就很容易失去针对性，最终成为泛泛而谈的管理口号。
从实施角度看，目标实现规划与风险评估的关系必须写透。目标不是凭感觉选定的，也不应只由管理层偏好决定，而应当回应 5.4.1 识别出的重要风险和机会。比如某组织发现高风险主要集中在主体请求超时、分包链透明度不足和保留策略执行不一致，那么目标就不应还停留在“提升意识”“加强管理”这类空泛表述，而应转化为可以追踪和评价的改进方向。只有这样，目标才会真正成为风险治理的延伸，而不是另一套平行文件。
写这一条时，还应该提醒读者注意“实现规划”四个字。目标写出来只是起点，真正决定成败的是实现路径是否明确。谁负责推进，什么时候完成，如何评估进展，偏差出现后如何调整，这些都是目标管理的核心内容。很多组织不是不会定目标，而是目标一定下来就失去管理支持，没有资源，没有例会，没有指标，没有升级机制。那样的目标再漂亮，也无法证明 5.4.2 有效。
因此，5.4.2 的文章不能只重复目标管理常识，而应把它与 PIMS 真实运行联系起来。读者最需要理解的是：为什么在27701里，即便条文仍沿用“信息安全目标”措辞，组织也必须把它解释成隐私治理目标；为什么这些目标一定要与风险、角色和处理场景绑定；以及为什么目标实现规划最终会直接决定 PIMS 是否能稳定运行。
三、实施要点
- 在现有ISMS目标体系中显式加入 PIMS 目标，不要默认原安全目标会自然覆盖隐私治理需求。
- 让目标直接回应5.4.1识别出的高风险和关键机会，形成“风险驱动目标”的管理逻辑。
- 根据控制者、处理者或混合角色差异，设置具有针对性的目标内容和评价方式。
- 为每项目标明确责任人、资源、时间表和复盘机制，避免目标只有名称没有执行路径。
- 5.4.2的重点是把 PIMS 要求转化成能够被跟踪和问责的治理结果。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| PIMS目标矩阵 | 把风险、方针和角色要求转成目标 | 目标清单 |
| 目标行动计划表 | 落实资源、负责人和完成节点 | 实施计划 |
| 绩效看板 | 定期跟踪目标完成情况和偏差 | 月度或季度报表 |
| 管理评审复盘机制 | 根据运行结果更新目标 | 调整记录 |
在实践中，组织可以把目标分成两类。第一类是“底线型目标”，用于保证关键义务不掉线，例如高风险处理活动评审覆盖率、主体请求按期完成率、重大事件通报时效等。第二类是“提升型目标”，用于推动治理成熟度上升，例如分包评审模板标准化、自动化删除比例、记录留痕完整度等。这样既能守住最低要求，也能推动持续改进。
如果组织担心目标过多难以管理，建议优先选取最能反映当前高风险问题的少数关键目标，而不是把所有想做的事情都写成目标。目标一旦失去聚焦，执行资源就会被稀释，管理层也难以持续关注。
五、典型案例
- 只有制度没有目标：某企业已经建立隐私制度、流程和模板，但管理评审时无法回答“今年 PIMS 到底改善了什么”。原因就是从未把隐私治理要求写成目标。后来组织在 5.4.2 下建立主体请求、供应商治理和高风险处理评审三类目标，部门才开始围绕结果协同。
- 目标沿用原ISMS模板：另一家组织的年度目标只有漏洞修复率、终端合规率和可用性指标，看起来体系很完整，但完全无法反映分包控制、返还删除或透明度问题。补做 PIMS 目标后，管理层才第一次看见这些隐私治理事项的进展和偏差。
这些案例说明，5.4.2的真正价值不是生成一份目标表，而是让 PIMS 进入管理节奏。只要目标能被看见、被跟踪、被调整，隐私治理就会从抽象要求变成持续发生的管理动作。
从发布质量角度看，这一条最值得点破的，是“2019版虽然没有单独写出隐私目标四个字，但你不能因此把目标做回普通ISMS”。这恰好是实施中最常见、也最隐蔽的偏差。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| PIMS目标清单 | 目标内容、层级、对应风险和角色说明 |
| 目标实施计划 | 资源、责任人、时间节点和评价方式 |
| 目标监视记录 | 进度、偏差、原因和纠正措施 |
| 目标调整记录 | 基于管理评审或业务变化的更新依据 |
这类文件应尽量与 5.4.1 的风险结果和 9.1/9.3 的监视评审活动连在一起。只有能看见“风险如何转成目标、目标如何被评价、偏差如何被纠正”，5.4.2 才不至于沦为孤立文书。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 沿用原安全目标，不做隐私扩展 | PIMS目标缺少主体请求、分包、保留等内容 | 把5.1扩展解释落实到目标体系中 |
| 目标只写方向，不写实现路径 | 责任、资源、时限都不明确 | 同步制定实现规划和跟踪机制 |
| 目标与风险脱节 | 管理资源投入不到真正高风险问题 | 让目标来源于5.4.1的评估结论 |