什么是 同意凭证？
同意凭证帮助组织证明并审计同意，而不是依赖简单的“consent = true”数据库取值或同意横幅的截图。
在 GDPR 下，当处理以同意为基础时，组织必须能够证明该个人已经作出同意。因此，有效的同意记录应当保存诸如谁作出了同意、同意是何时给予的、当事人被告知了什么，以及同意是如何取得的等信息。
在印度，DPDP Act 同样规定，当同意是处理的基础且同意的有效性受到质疑时，Data Fiduciary 必须能够证明已经依照该法及适用规则给予了所要求的告知并取得了同意。
通俗理解同意凭证
可以把同意凭证理解为一项同意决定的数字化证明。
例如，一位访问者打开某个网站并作出以下选择：
- 分析类 Cookie已允许
- 广告类 Cookie已拒绝
- 个性化广告已拒绝
- 功能类 Cookie已允许
一份有用的同意凭证可以把该决定连同重建该决定所需的上下文一并保存下来，例如：
- 同意凭证或交易 ID
- 日期与时间
- 用户标识符或假名化标识符
- 同意类别或处理目的
- 所涵盖的服务、供应商或处理活动
- 每一项目的的同意状态
- 隐私告知或同意告知的版本
- 收集同意所采用的方式或渠道
- 相关法域或监管背景
- 后续撤回或变更的时间戳
- 把该决定与适用告知相关联的证据
确切的字段取决于具体实现、法域和使用场景。
同意凭证为何重要？
同意横幅只能展示呈现给用户的界面。它并不必然能够证明某位特定用户在某一特定时刻作出了什么选择。
同意凭证为单次同意交易提供了可供审计的呈现形式。
当组织需要回答以下问题时，这一点尤为重要：
- 这位用户同意了什么？
- 他们是何时作出同意的？
- 他们看到的是哪一份隐私告知？
- 涵盖了哪些处理目的？
- 他们后来是否撤回了同意？
- 处理发生时生效的是哪种同意状态？
因此，强健的同意管理系统应当保存足够的证据，以便重建相关的同意事件。
ICO 的指引建议保持有效的审计轨迹，并记录谁作出了同意、他们是何时同意的、他们被告知了什么，以及同意是如何取得的。
同意凭证与同意记录的对比
同意凭证与同意记录这两个术语密切相关，但不应当自动被视为完全相同。
同意记录
同意记录是组织或同意管理系统所维护的底层证据。
它可能包含关于以下方面的详细技术信息：
- 同意事件
- 用户标识符
- 时间戳
- 告知版本
- 处理目的
- 供应商或服务
- 同意状态
- 收集方式
- 撤回情况
- 偏好设置的更改
- 法域
- 技术元数据
同意凭证
同意凭证是对该同意交易的一种呈现形式，可以提供给个人或供其获取，并用作该决定的证据。
Kantara 同意凭证规范把同意凭证描述为个人授予控制者处理个人信息之授权的一项记录，并定义了一种同时可以用 JSON 表示的、人类可读的呈现形式。
这一区分为何重要
数据库中可能包含成千上万条内部同意事件，而面向用户的同意凭证则可以清晰地呈现某一位特定个人的同意决定。
同意凭证应当包含哪些内容？
并不存在一份适用于每个组织每一次同意交易的通用字段清单。
然而，一份稳健的同意凭证应当包含足以确立该决定之背景与实质内容的信息。
同意标识符
唯一标识符使组织能够定位并引用某一次特定的同意交易。
时间戳
凭证应当记录同意决定发生的时间，理想情况下还应包含适当的时区或 UTC 信息。
用户或主体标识符
记录应当以适度的方式标识相关的个人或设备。
视具体实现而定，这可以是账户标识符、假名化标识符、会话标识符或其他适当的引用信息。
同意状态
凭证应当显示某一特定目的、类别或处理活动处于何种状态：
- 已给予
- 已拒绝
- 已撤回
- 已更改
精细化的记录通常比单一的总体“已接受”取值更为有用。
处理目的
凭证应当标明该同意所涵盖的内容。
例如：
- 分析
- 个性化广告
- 营销通信
- 个性化
- 数据共享
- 特定的产品功能
同意不应被呈现得比其实际取得时所针对的目的更为宽泛。
告知或政策版本
组织应当能够确定在取得同意时所展示的隐私告知、同意告知或其他信息。
当告知随时间发生变化时，这一点尤为重要。
一条写着“用户已同意”的记录，远弱于能够确立以下链条的记录：
用户 → 同意事件 → 处理目的 → 告知版本 → 时间戳。
收集方式
凭证可以记录同意是如何取得的，例如：
- 网站同意横幅
- 偏好设置中心
- 移动应用程序
- 账户设置
- Consent Manager
- 书面表格
- 其他受支持的渠道
服务或供应商
在相关的情况下，凭证可以标明与该决定相关联的服务、供应商、Cookie、标签或处理活动。
这对于 Cookie 同意和广告技术环境尤为有用。
撤回或后续变更
同意并不必然是一项永久性的决定。
因此，同意管理系统应当能够把后续的偏好变更或撤回与原始的同意历史关联起来。
GDPR 要求必须有同意凭证吗？
当同意被用作处理的合法性基础时，GDPR 要求同意必须可以被证明，但它并不是在每一种情形下都径直强制要求一份名为“同意凭证”的文件。
第 7 条第 1 款要求控制者能够证明数据主体已经同意该处理。其实际含义是，组织需要具备可靠的同意证据。
同意凭证可以成为呈现该证据的一种有效方式，但组织应当区分：
- 证明同意这一法律要求；以及
- 用于记录或呈现该证据的某一特定技术实现。
这一区分对于准确的 GDPR 合规内容而言非常重要。
同意凭证与 GDPR 同意
要使同意能够作为 GDPR 的合法性基础发挥作用，底层的同意必须满足适用的各项要求。
同意凭证并不能把无效的同意变为有效。
例如，凭证无法弥补以下同意机制的缺陷：
- 在需要肯定性行为的场合使用预先勾选的选项
- 把互不相关的目的捆绑在一起
- 没有提供充分的信息
- 使撤回变得不必要地困难
- 在记录同意时没有保存相关的上下文
- 把拒绝错误地呈现为同意
凭证证明的是实际发生的决定。它并不能取代首先要收集有效同意这一要求。
GDPR 要求你就同意记录哪些内容？
ICO 建议保存能够证明以下内容的记录：
- 谁作出了同意
- 他们是何时同意的
- 他们被告知了什么
- 同意是如何取得的
只要组织仍以同意作为处理的基础，它就应当保留足以证明该同意决定的信息。
这使得告知的版本管理尤为重要。
例如：
- 同意日期
- 2026 年 9 月 10 日
- 告知版本
- 隐私告知 v4.2
- 处理目的
- 分析
- 决定
- 已给予
- 收集方式
- 网站 CMP
- 凭证 ID
- CR-XXXXXXXX
- 状态
- 有效
具体的实现方式可以有所不同，但证据应当具有实质意义并且可以被重建。
印度 DPDP Act 下的同意凭证
Digital Personal Data Protection Act, 2023（DPDP Act）使用 Data Principal 和 Data Fiduciary 这样的术语，而非 GDPR 所用的“数据主体”和“控制者”。
第 6 条规定，同意必须是自由作出、具体、知情、无条件且无歧义的，通过明确的肯定性行为给予，并且限于为特定目的所必需的个人数据。
重要的是，当同意是处理的基础且其有效性受到质疑时，Data Fiduciary 必须证明已经依照该法及适用规则给予了所要求的告知并取得了同意。
最终版 DPDP 规则还对已注册的 Consent Manager 规定了具体要求。Consent Manager 必须保存关于所给予、拒绝或撤回的同意，同意请求之前或随附的告知，以及特定个人数据共享情况的记录。该规则还规定了 Data Principal 对这些记录的访问、应请求以机器可读形式提供，以及特定的留存要求。
这使得同意证据与 ConsentX 面向印度的合规内容尤为相关。
同意凭证与同意横幅的对比
两者并不是一回事。
| 同意横幅 | 同意凭证 |
|---|---|
| 用于收集决定的用户界面 | 对该决定的记录或呈现 |
| 出现在同意之前或同意过程中 | 由同意事件生成 |
| 展示可供选择的选项 | 记录实际作出的选择 |
| 侧重于用户交互 | 侧重于证据与可审计性 |
| 可能随网站设计的变化而变化 | 应当保存历史性的同意上下文 |
| 其本身并不能证明某位个人的选择 | 可以提供该个人所作决定的证据 |
同意横幅的截图可以显示网站当时的样子。
同意凭证则应当有助于证明某一位特定个人作出了什么决定。
同意凭证与 Cookie 同意的对比
Cookie 同意是同意管理的一个具体使用场景。
网站可能就以下内容收集同意：
- 分析类 Cookie
- 广告类 Cookie
- 个性化
- 社交媒体技术
- 其他非必要追踪器
同意凭证可以保存由此产生的各项选择。
例如：
- 分析已给予
- 广告已拒绝
- 功能已给予
底层的同意系统还应当保存相关的时间戳、告知版本以及解读该决定所需的其他证据。
同意凭证与同意管理平台的对比
同意管理平台（CMP）是用于收集、管理、执行并且通常还用于记录同意偏好的技术。
同意凭证则是某一次特定同意交易的证据或呈现形式。
简单来说：
管理同意的系统。
由该系统存储的证据。
对某项同意决定的呈现。
因此，CMP 可以在其更广泛的同意管理功能中生成或维护同意凭证。
什么是可防篡改的同意凭证？
可防篡改的同意凭证在设计上能够让针对证据的未授权更改被检测出来。
这可能涉及以下技术手段：
- 加密哈希
- 哈希链
- 数字签名
- 不可变或仅可追加的存储
- 带版本的记录
- 安全时间戳
- 审计日志
其目的并不是让同意记录神奇地变成“法律证明”，而是提升证据的完整性与可审计性。
例如，哈希链可以把先后产生的同意记录串联起来，从而使对较早记录的未授权修改能够被检测出来。
ConsentX 使用可防篡改的同意记录，并将其实现描述为采用 SHA-256 哈希链。当前的 ConsentX 术语表页面明确把这一点定位为一种使同意证据可被独立验证、且难以被倒填日期的机制。
截图足以证明同意吗？
通常情况下，仅凭截图属于薄弱的证据。
截图可以表明同意界面在某一特定时点的样子，但它一般无法确立某位特定个人作出了某一特定选择。
更有力的证据可以把以下要素关联起来：
个人或标识符 + 时间戳 + 同意决定 + 处理目的 + 告知版本 + 收集方式。
这正是同意记录与同意凭证对审计准备工作如此重要的原因。
当用户撤回同意时会发生什么？
撤回应当被视为同意生命周期的一部分。
有用的同意系统应当保存：
- 原始的同意决定
- 同意的日期与时间
- 所涵盖的处理目的
- 后续的撤回或偏好变更
- 撤回的日期与时间
- 由此产生的同意状态
- 在必要时表明下游处理或相关技术已被更新的证据
例如：
- 9 月 10 日给予分析类同意
- 9 月 18 日撤回分析类同意
- 9 月 18 日同意状态变更为已拒绝
相比于直接覆盖原始取值，这会形成一条清晰得多的审计轨迹。
什么是同意证据？
同意证据是指组织为证明同意已被有效取得并得到妥善管理而保存的更广泛的一整套信息。
它可能包括：
- 同意凭证
- 同意记录
- 告知版本
- 同意日志
- 偏好设置的更改
- 撤回记录
- CMP 配置
- 审计日志
- 时间戳信息
- 供应商或处理相关信息
- 显示执行情况的技术记录
因此，同意凭证可以成为更广泛的同意证据与审计体系中的一个组成部分。
同意凭证与审计准备
成熟的同意管理流程应当使组织无需手工重建历史事件，就能回答审计师或监管机构的问题。
对于每一次相关的同意事件，组织理想情况下应当能够确定：
- 是谁作出了该决定？
- 决定是何时作出的？
- 他们同意了什么？
- 他们拒绝了什么？
- 当时展示了哪些信息？
- 适用的是哪一版本的告知？
- 同意是如何取得的？
- 同意后来是否被撤回？
- 处理发生时生效的是哪种同意状态？
- 该记录能否以人类可读的形式展示？
- 其完整性能否得到验证？
这正是同意凭证的实际价值所在。
同意凭证如何运作
典型的同意凭证工作流如下：
展示告知
组织展示相关的隐私信息或同意信息。
收集用户的选择
用户就一项或多项处理目的作出明确的选择。
创建同意记录
系统记录该决定以及相关的上下文信息。
生成凭证
系统生成该同意事件的人类可读呈现形式。
保存证据
组织安全地存储同意记录及相关联的元数据。
执行该决定
在适用的情况下，用户的选择被应用于相关的 Cookie、追踪器、处理活动或其他技术。
记录后续变更
如果用户更改或撤回同意，系统会记录该后续事件。
在需要时提供证据
组织可以为审计、合规审查、数据权利请求、争议或监管问询调取相关记录。
什么样的同意凭证才是好的？
强健的实现应当具备以下特性：
具体
它应当标明该决定所涵盖的处理目的与处理活动。
带时间戳
组织应当知道该决定是何时发生的。
可追溯
凭证应当与相关的用户、会话或其他适当的标识符相关联。
带版本
组织应当能够确定当时所展示的告知或政策版本。
精细
当同意是按处理目的分别收集时，证据应当保存这些各自独立的选择。
安全
同意证据应当受到保护，防止未授权的访问与更改。
可审计
组织应当能够调取并解读历史记录。
注重隐私
同意证据本身可能包含个人信息，因此应当得到妥善处理。
同意凭证与隐私设计
同意证据不应当带来不必要的隐私风险。
同意凭证可能包含标识符、时间戳、偏好设置，以及关于个人与某项服务交互情况的信息。
因此，组织应当考虑：
- 数据最小化
- 访问控制
- 加密
- 留存期限
- 假名化
- 安全删除
- 审计日志记录
- 适当的用户访问权限
目标是在不收集超出必要范围的个人信息的前提下，形成可靠的证据。
常见的同意凭证误区
只存储“consent = true”
布尔取值并不能说明该个人同意了什么、何时同意，或者被告知了什么。
不对告知做版本管理
如果隐私告知发生变更，组织可能难以确定取得同意时展示的是哪一个版本。
只记录接受
拒绝与撤回可能与肯定性的同意决定同样重要。
覆盖历史同意
用新的取值替换旧的同意状态，可能会破坏有用的审计历史。
把凭证本身当作有效同意的证明
凭证记录的是一次同意事件。它并不能使本身无效的同意机制变得合规。
忽视下游执行
如果组织仍然基于该同意继续发送营销通信，那么仅仅记录“营销同意已撤回”是不够的。
把横幅截图当作同意记录
界面与用户个人的决定并不是一回事。
忽视同意证据的安全
同意记录可能包含个人信息，应当相应地加以保护。
同意凭证与 ConsentX
ConsentX 旨在帮助组织在各类隐私与同意工作流中收集、管理、执行并证明同意。
在同意证据方面，ConsentX 提供同意记录与审计证据功能，使组织能够维护一份关于同意决定及其支撑上下文的结构化记录。
当前的 ConsentX 实现还描述了采用 SHA-256 哈希链的可防篡改同意记录，旨在使未授权的更改更容易被检测出来，并提供更强的可审计性。
这可以帮助组织从：
转变为：
“这里是记录，显示用户同意了什么、何时同意，以及是在何种同意上下文之下同意的。”
同意凭证：要点总结
- 同意凭证是对用户同意决定的结构化呈现。
- 同意记录是组织或同意系统所维护的底层证据。
- GDPR 要求依赖同意的组织能够证明同意已经取得。
- 凭证并不能使本身无效的同意机制在法律上变得有效。
- 良好的同意证据应当保存谁作出了同意、何时同意、被告知了什么，以及同意是如何取得的。
- 告知与政策的版本对于重建历史同意非常重要。
- 撤回与偏好变更应当构成同意历史的一部分。
- 同意凭证对于审计、合规审查、争议和证据请求都很有用。
- 印度的 DPDP 框架就同意与 Consent Manager 规定了具体的举证与记录保存要求。
- 哈希等技术完整性措施可以增强可审计性，但不应被呈现为合法同意的替代品。