一、ISO/IEC 27701:2019 7.3.2 标准原文
原文摘要：标准要求组织确定并记录需要向 PII 主体提供的信息，以及这些信息与其 PII 处理和提供时间的关系。实施指南列举的信息类型包括处理目的、联系方式、合法依据、PII 来源、是否必须提供、主体权利、如何撤回准许、传输、接收者类别、保留期、自动决策和投诉权利等，并指出如果处理目的发生变化，信息应及时更新。
二、条款解读说明
7.3.2 处理的是告知设计的上游问题。很多组织会直接跳到文案撰写，甚至把注意力放在语言是否优美、页面是否好看，但标准先问一个更本质的问题：到底应该告诉 PII 主体什么，以及这些信息应在何时提供。换句话说，本条是在建立“告知内容模型”和“告知时点模型”。如果这两个模型没有先被定义清楚，再漂亮的政策页面也只是在包装不完整的信息。
从标准列出的信息看，主体真正关心的并不只有处理目的。对组织而言，至少还要说清楚合法依据、是否必须提供、如果不提供会怎样、数据来自哪里、给了谁、保留多久、能否撤回准许、怎样行使访问更正删除权，以及是否存在自动决策和投诉路径。也就是说，7.3.2 要求控制者从主体决策视角审视信息，而不是仅从组织叙事角度写说明。
| 信息类别 | 主体为什么需要知道 | 组织常见遗漏 |
|---|---|---|
| 处理目的与合法依据 | 判断组织凭什么处理我的信息 | 只说目的，不说依据 |
| 来源与是否必须提供 | 理解信息来自哪里、拒绝提供会有什么后果 | 默认视为用户都能推断 |
| 接收者、传输和保留期 | 评估外部流转和长期影响 | 只写“可能共享”之类空泛表述 |
| 权利与投诉路径 | 知道如何改变选择或提出异议 | 只列权利名称，不给操作方式 |
| 自动决策信息 | 识别算法处理对主体的实质影响 | 完全不提自动化参与程度 |
7.3.2 还特别强调告知时点。某些信息必须在处理前提供，有些则要在请求后某个期限内补充，有些则要在处理目的扩展时更新。这意味着组织不能把一次性发布政策当作长期完成。本条真正要求的是动态告知管理：当处理方式、接收者、保留期或目的发生变化时，告知内容也必须同步演化，否则主体做选择时依据的仍是过期事实。
因此，7.3.2 的本质是把告知工作从“写文案”提升为“定义信息集合和时间规则”。只有先把主体需要知道的内容和看到这些内容的时机设计好，7.3.3 的具体提供方式才不会流于表面。
从审核视角看，7.3.2 最容易出问题的地方不在于完全漏项，而在于信息模型没有和实际决策时点绑定。组织也许在隐私政策里罗列了很多内容，但主体真正作出注册、授权、购买、开通定位或接受自动决策时，看到的却是被压缩过、删减过甚至与场景无关的告知。这样一来，告知内容虽然“某处存在”，却没有在正确时间帮助主体理解正在发生的处理。
这条控制还要求组织处理好多来源、多用途和多法域场景。数据可能来自主体直接提供、第三方合作方、设备自动采集或推断分析，告知内容也可能因不同国家要求而增减。如果组织只写一份通用说明，而不区分数据来源、处理路径和适用法域，就很难确保每个触点展示的信息既完整又相称，最终形成大量“总体看似没错，放到具体场景里却不够用”的问题。
三、实施要点
- 建立隐私告知信息目录，按处理活动整理应向主体提供的关键内容。
- 区分处理前告知、请求后补充告知、变更更新告知等不同时间节点。
- 对自动决策、跨境传输、接收者类别和保留期等高关注信息单独校核完整性。
- 在处理目的扩展、来源变化或共享路径变化时触发告知更新评审。
- 7.3.2的核心是先明确主体在何时应知道哪些事实，再决定用什么载体表达这些事实。
四、常用工具与实施方法
| 工具/方法 | 适用目的 | 关键输出 |
|---|---|---|
| 告知内容矩阵 | 梳理不同场景应说明的信息项 | 字段清单、适用页面、责任人 |
| 处理活动与告知映射表 | 让处理台账和告知材料一一对应 | 处理活动到告知触点的关系图 |
| 变更触发规则 | 控制何时需要更新主体信息 | 变更评审条件和更新时间要求 |
| 文案审核清单 | 检查是否遗漏关键内容 | 发布前复核记录 |
最实用的方法，是把 7.3.2 和 7.2 的处理活动记录打通。因为目的、依据、来源、接收者和保留期本来就来自处理活动本身，若两边分开维护，信息偏差几乎不可避免。
在实施方法上，最有效的做法通常是先建立统一的告知内容模型，再为注册、营销、画像、跨境传输、第三方来源和自动决策等不同场景配置差异化显示规则。这样每个触点都不是重新写一份文案，而是在同一内容模型下选择应展示的要素和时点，既能控制一致性，也更容易随着法规或业务变化集中更新。
五、典型案例
- 告知只覆盖目的，不覆盖后果：某服务在注册页写了“用于提升体验”，但没有告诉用户拒绝提供某项信息将导致哪些功能不可用，也没有说明是否存在自动化评分，结果用户决策基础明显不足。
- 业务扩展后告知未更新：另一家企业最初只在本地处理数据，后续接入境外云服务与外部分析工具，但原有告知页面仍停留在旧版本，主体对新流转路径毫无感知。
这类案例提醒组织，7.3.2 失效的后果通常不是“少写几行字”，而是让主体在关键决策时基于过期或不完整信息做出选择。
六、成文信息管理要求
| 建议保留文件 | 关键内容 |
|---|---|
| 告知内容目录 | 信息类别、适用场景、提供时点和维护责任 |
| 处理活动映射表 | 目的、依据、接收者、保留期与告知触点对应关系 |
| 变更更新记录 | 哪些事实变化触发了告知更新、何时更新 |
| 文案审核和发布记录 | 版本、审批、发布日期和回溯依据 |
这些材料能帮助组织证明，主体信息不是凭经验临时拼写，而是来自受控的内容模型和更新机制。
成文信息管理方面，7.3.2 不应只保存最终发布版隐私政策，还应保留告知内容模型、各触点适用清单、版本变化说明和更新触发条件。因为这条控制要证明的不是“组织写过一篇告知文案”，而是“组织知道在什么场景下应向主体说明哪些信息，并能随着目的和流程变化及时更新”。
七、常见误区及踩坑提醒
| 误区 | 问题表现 | 正确做法 |
|---|---|---|
| 隐私政策写得长就算完整 | 关键信息仍旧缺失或难以定位 | 围绕主体决策需求定义信息项 |
| 默认所有信息都一次性提供 | 时点错位，主体在关键节点看不到关键内容 | 按处理阶段设计告知节奏 |
| 处理变了但告知不变 | 主体依据旧事实做选择 | 把变更更新纳入正式评审 |
本条在真实项目里最容易失效的原因，是组织把所有告知义务都压缩进一份主隐私政策，以为这样最省事。结果一旦碰到第三方来源、跨境传输、自动决策或用途变更等复杂场景，主政策无法在具体触点及时承载足够信息，主体做决定时看不到真正关键的内容。
就 7.3 这一组控制而言，真正决定成败的通常不是政策文本是否齐全，而是前台入口、后台系统、第三方协作和时限管理能否一起工作。很多组织在文案和制度上已经写明主体权利，但请求一旦进入真实渠道，就会在身份核验、内部流转、权限限制和系统同步处卡住。也正因为如此，这组条款最终拼的是运营闭环，而不是文字完整度。