一、ISO/IEC 27701:2019 7.3.7 标准原文
原文摘要：标准要求组织通知共享 PII 的第三方有关共享 PII 的任何修改、撤回或异议，并实施适当的政策、流程和或机制。实施指南指出，组织应采取技术和组织措施通知第三方相关变更，确定并保持积极沟通渠道，并监控第三方收到信息的确认；相关变更可能包括修改或撤回准许、更正请求、删除、处理限制或主体提出的其他异议。
二、条款解读说明
7.3.7 是 7.3 章节里最容易被低估的一条。很多组织对主体请求的关注主要停留在自有系统，例如更新账户资料、关闭营销订阅、删除主库记录，却忽视相同 PII 可能已经被共享给多个第三方，包括外包服务商、合作伙伴、营销平台、支付机构或合规审计接收方。标准因此专门提出，控制者应通知第三方关于共享 PII 的任何修改、撤回或异议，并建立相应机制。
这条控制的意义在于把主体权利延伸到外部处理链。否则，组织对外宣称已满足更正、删除或撤回准许，但主体在第三方渠道上仍会继续遭遇旧状态处理，整个请求就变成了“局部有效”。尤其在共享路径复杂、接收方数量多、合同关系分层的场景下，控制者若没有主动通知机制，第三方通常不会自动知道主体权利已经发生变化。
| 同步触发类型 | 为什么要通知第三方 | 未通知的后果 |
|---|---|---|
| 更正 | 第三方继续使用旧数据会导致结果失真 | 不同渠道信息不一致 |
| 删除 | 第三方仍保留可识别PII会削弱删除效果 | 主体误以为已删除 |
| 撤回准许 | 共享基础或使用边界发生变化 | 外部营销或分析仍继续 |
| 反对或限制处理 | 第三方必须知道哪些行为应停止 | 控制者内外口径断裂 |
标准同时强调应保持积极沟通渠道并确认第三方已收到信息。这表明通知并不等于发出一封邮件就完成。控制者需要考虑通知方式是否可追踪、对方是否有明确接收责任、是否需要确认已执行、如果对方未响应应如何升级。换句话说，7.3.7 要求组织管理的是“传达和确认”而不仅是“发送动作”。
因此，7.3.7 的本质是把主体义务真正延伸到共享链条的末端。只有当第三方也收到、理解并执行变更，控制者对主体作出的承诺才算站得住。
从审核视角看，7.3.7 的难点首先在于组织是否真正知道自己的 PII 共享链条。只有当控制者掌握了哪些第三方收过哪些数据、以什么方式收、是否仍在持续处理、联系窗口是谁，它才有可能在主体请求发生后做出准确通知。若共享台账本身就不完整，后续通知第三方几乎只能依赖人工回忆和零散合同，结果必然不稳。
本条还要求控制者关注通知是否被真正接收和执行。对主体来说，请求不只是在控制者系统里完成更新，而是要尽可能沿整个共享链生效。也正因为如此，组织不应满足于“我们已经发了邮件”，还应设计回执、确认、失败重试和升级机制，必要时要求第三方反馈执行结果。没有这一步，第三方通知就很容易变成单向抄送，而不是受控动作。
三、实施要点
- 维护共享PII的第三方清单，明确每类主体请求涉及哪些接收方。
- 为更正、删除、撤回准许和反对处理等场景建立标准通知模板和时限。
- 要求第三方确认收到并在必要时反馈执行结果，而不是默认其会自动处理。
- 将未响应或拒绝配合的第三方纳入升级处置和合同复审范围。
- 7.3.7的核心是让主体请求的效果贯穿整个共享链，而不是停留在控制者自己的边界之内。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 第三方共享台账 | 识别PII接收方、共享内容和联络方式 | 接收方清单、联系人、合同编号 |
| 通知模板库 | 统一更正、删除、撤回和限制处理通知 | 标准消息模板和字段要求 |
| 确认回执机制 | 证明第三方收到并理解通知 | 回执、工单记录、接口确认 |
| 升级与复审机制 | 处理第三方不响应或执行不足的情况 | 升级记录和合同整改事项 |
最有效的做法，是把第三方通知要求前置写入合同和操作规程。这样当主体请求发生时，组织不必临时协商“对方是否需要配合”，而是直接按既定责任执行。
在实施方法上，组织最好建立一张“第三方变更通知矩阵”，把不同请求类型与相应接收方、通知时限、确认方式和升级责任对应起来。例如更正请求通知哪些伙伴、撤回准许通知哪些营销平台、删除请求通知哪些外包处理者。这样一来，主体权利变更不会因为第三方数量增加而迅速失控。
五、典型案例
- 删除只删自家库：某教育平台在家长提出删除请求后清除了自有账号数据，但没有通知外部消息服务商，后续仍发送与该学生相关的提醒信息。
- 第三方收到通知但无人跟：另一家企业向合作营销平台发出了撤回准许通知，却没有确认是否执行，几周后主体仍收到定向广告，组织无法说明哪个环节失效。
这些案例说明，7.3.7 失败的原因经常不是组织完全没通知，而是缺少共享清单、确认机制和后续跟踪。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 第三方共享台账 | 接收方名称、共享目的、PII类别和联络方式 |
| 通知与回执记录 | 通知时间、内容、接收人和确认结果 |
| 执行跟踪记录 | 第三方是否完成更正、删除或限制处理 |
| 升级处置和合同条款 | 未响应情形的处理规则和追责依据 |
这些记录可以帮助组织证明，其对主体请求的处理已经延伸到了共享链条，而不是只对内部系统进行了局部调整。
成文信息管理上，7.3.7 除了保存通知本身，还应保存通知依据、发送对象、发送时间、接收确认、未响应处理和最终关闭情况。因为争议往往发生在“有没有真正同步到位”而不是“是否发出过一条消息”。没有执行层证据，控制者很难证明自己已经尽到合理通知责任。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 第三方通知靠记忆完成 | 容易遗漏接收方或联系人 | 维护共享台账和固定联络机制 |
| 发出通知就视为结束 | 执行结果无人确认 | 要求回执并跟踪关闭 |
| 合同里不写配合义务 | 对方拒绝或拖延时缺少抓手 | 在合同和流程中前置约定责任 |
本条在真实项目中最容易失效的原因，是组织把主体请求只做成内部闭环，自有系统改了，外部合作方却仍按旧状态继续处理。共享链条越长、合作方越多，这种断层越危险，因为主体往往最晚才知道外部副本并没有跟着停止或更正。
就 7.3 这一组控制而言，真正决定成败的通常不是政策文本是否齐全，而是前台入口、后台系统、第三方协作和时限管理能否一起工作。很多组织在文案和制度上已经写明主体权利，但请求一旦进入真实渠道，就会在身份核验、内部流转、权限限制和系统同步处卡住。也正因为如此，这组条款最终拼的是运营闭环，而不是文字完整度。
进一步说，7.3 组条款真正要建立的是一种可压测的主体权利运营能力。请求量增加、渠道增多、系统变更或第三方参与时，这套能力是否还能稳定工作，才是检验控制是否成熟的关键。很多组织在低请求量阶段依靠人工记忆还能勉强运转，一旦规模上来就暴露出入口不统一、SLA 不可见和后台不同步的问题，因此持续演练和指标化运营对这组条款尤其重要。