| name | consent-mechanism-checker |
| description | 同意机制合规审查——检查个人信息处理活动中同意机制的设计与实现 是否符合PIPL要求。适用情形：用户说"检查我们的同意弹窗"、 "同意机制是否合规"、"用户授权页面设计"、"撤回同意流程"、 "是否需要单独同意"、"未成年人同意怎么处理"。
|
| argument-hint | [同意机制描述 + 数据场景 + 用户群体] |
| legal_frame | cn-mainland |
| last_reviewed | 2026-06 |
| version | 1.0.0 |
| risk_level | high |
| escalation_triggers | ["涉及敏感个人信息处理未取得单独同意","涉及未成年人个人信息处理","同意机制存在\"捆绑同意\"或\"强制同意\"设计","用户投诉或监管关注"] |
| trigger_phrases | ["检查","数据合规","个人信息","PIPL","跨境"] |
/consent-mechanism-checker — China Mainland
法律背景与法规框架
PIPL第13条确立了个人信息处理的七类合法性基础，其中"取得个人同意"是适用范围最广的基础。第14条要求同意应当"自愿、明确"，并在充分知情的前提下作出。第15条赋予个人撤回同意的权利，且撤回同意不得影响撤回前已进行的处理。第16条禁止因拒绝同意而拒绝提供产品或服务（非必要场景）。第29条对敏感个人信息提出"单独同意"要求。第31条对未成年人信息需取得其父母或监护人同意。
PIPL实施后，CAC执法实践中"同意机制不合规"是最常见的处罚原因之一。常见违规场景包括：默认勾选同意、隐私政策与用户协议捆绑、撤回同意渠道隐蔽、单独同意与一般同意合并、未成年人识别和同意机制缺失等。《App违法违规收集使用个人信息行为认定方法》和GB/T 35273《个人信息安全规范》对同意机制的实现方式提供了具体指引。
工作流程
第一步：识别处理场景与合法性基础
确定当前数据处理场景，判断是否需要同意作为合法性基础：
| 场景 | 建议合法性基础 | 是否需要同意 |
|---|
| 直接提供服务所需（如账号注册） | 合同必要（第13条第二项） | 不需要（但须告知） |
| 履行法定义务（如税务报送） | 法律义务（第13条第三项） | 不需要 |
| 营销推送 | 同意（第13条第一项） | 必须 |
| 第三方数据共享 | 同意或单独同意 | 通常需要 |
| 敏感信息处理（健康/金融/位置） | 单独同意（第29条） | 必须单独同意 |
| 跨境传输 | 同意+出境路径 | 必须 |
第二步：检查同意获取界面
视觉设计检查清单：
□ 隐私政策/同意弹窗是否在首次使用/首次打开时展示
□ 是否提供了"同意"和"不同意/拒绝"两个明确选项
□ 拒绝的入口是否与同意同等显著（不得默认勾选）
□ 同意是否通过主动勾选或主动点击获取（不得默认同意）
□ 隐私政策文本是否易于访问（字号不小于正文大小）
□ 敏感信息是否单独弹窗/单独弹层获取同意
□ 未成年人模式是否识别并引导监护人同意流程
□ 撤回同意的入口是否在同等显著位置（如设置页面）
常见违规红线：
- ❌ 默认勾选"我已阅读并同意"
- ❌ 隐私政策与用户协议捆绑（必须同意全部才能使用）
- ❌ "不同意"按钮灰色/不可用/字号极小
- ❌ 拒绝后反复弹窗要求同意（骚扰式设计）
- ❌ 撤回同意找不到入口或需联系客服人工操作
第三步：检查同意记录与追溯能力
PIPL要求个人信息处理者对处理活动承担举证责任。同意机制须具备记录和追溯能力：
同意记录应包含：
- 用户标识（用户ID或设备ID）
- 同意时间（精确到秒的时间戳）
- 同意的具体内容（版本号/本次同意的项目列表）
- 同意的方式（明确主动操作证据）
- 同意版本历史（每次更新的时间线）
记录存储要求：
- 同意记录保存期限：从最后一次处理活动结束起不少于3年
- 同意记录可作为执法检查时的合规证明
第四步：检查撤回同意机制
| 检查项 | 合规做法 | 常见违规 |
|---|
| 撤回渠道 | 设置页面 / 隐私中心 / 功能开关 | 仅能通过客服电话 |
| 撤回便捷度 | 与给予同意同等便捷 | 需拨打客服+邮件+提交表单 |
| 撤回影响告知 | 明确告知撤回后的影响 | 误导用户撤回会无法使用 |
| 撤回后处理 | 停止处理并删除（除非另有合法基础） | 继续处理 |
