consent-mechanism-checker

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年
• 同意记录可作为执法检查时的合规证明

第四步：检查撤回同意机制

检查项	合规做法	常见违规
撤回渠道	设置页面 / 隐私中心 / 功能开关	仅能通过客服电话
撤回便捷度	与给予同意同等便捷	需拨打客服+邮件+提交表单
撤回影响告知	明确告知撤回后的影响	误导用户撤回会无法使用
撤回后处理	停止处理并删除（除非另有合法基础）	继续处理