📚 课程目录第4章隐私政策与告知同意文本的合规性审查

4. 隐私政策与告知同意文本的合规性审查

审查对象与判定基准

本次审查对象为某健康管理App的隐私政策文本（v3.2，共9节）及其注册页告知同意流程。判定基准采用“双轨对照”：一轨是《个人信息保护法》第17条告知事项与第14条同意有效性要求，另一轨是App实际收集的个人信息清单（从抓包与SDK清单获得）。审查的核心不是看政策“写没写”，而是看文本告知项、实际收集行为、用户同意动作三者是否一致。

审查基准三要素：

① 告知完整性——处理者身份、处理目的、处理方式、信息种类、保存期限、行使权利方式、投诉渠道，缺一即违规；

② 同意有效性——必须由用户主动作出，默认勾选、捆绑同意、继续使用即同意均不构成有效同意；

③ 最小必要一致——政策声明的收集范围不得小于实际SDK/接口采集范围。

逐条审查发现与违规点

将政策9节内容与基准逐项比对后，共识别出6处违规点，其中3处属于“告知缺失”，2处属于“同意机制缺陷”，1处属于“文本与实际行为不一致”。下表给出审查结论与修改建议。

编号	审查项	现状	违规类型	修改建议
F1	保存期限	仅写“法律法规要求的期限”，未给出具体年限	告知缺失	按信息类别分别列明：账号信息注销后30天删除、健康数据保存3年、日志6个月
F2	投诉渠道	只留客服邮箱，无个人信息保护负责人联系方式	告知缺失	补充DPO邮箱与受理时限（15个工作日）
F3	第三方共享清单	笼统写“可能与合作方共享”，未列接收方名称与目的	告知缺失	以表格列出SDK名称、公司、共享字段、目的、隐私政策链接
F4	注册页同意框	“我已阅读并同意”复选框默认勾选	同意缺陷	改为默认不勾选，用户主动点击方可注册
F5	同意粒度	一个勾选框同时覆盖隐私政策与营销推送	同意缺陷	拆分为“必要信息处理”与“营销推送”两个独立选项
F6	实际收集一致性	政策未提及设备IMEI，但启动时SDK读取IMEI	文本与行为不一致	要么停止采集IMEI，要么在政策中补充并说明目的

告知同意链路与违规定位

下图把“用户进入注册页→勾选同意→SDK采集→数据入库”的实际链路与合规判定点叠加呈现，红色标记处即为本次审查发现的违规位置，便于定位修改点。

修改建议与验证方法

针对6项违规，按优先级给出可落地的修改动作，并说明修改后如何验证是否闭环。

F4 默认勾选：将注册页复选框的 checked 属性移除，改为用户手动点击。验证：清空缓存重新进入注册页，确认复选框初始为未选中状态，未勾选时注册按钮不可提交。
F5 捆绑同意：拆分为两个独立复选框——“同意必要信息处理”与“同意接收营销推送”，后者不勾选不影响注册。验证：仅勾选第一项时能正常注册，且不收到营销短信。
F1 保存期限：在政策第5节增加分类保存期限表。验证：逐项核对表中类别是否覆盖实际收集的全部信息类型。
F2 投诉渠道：在政策末尾增加DPO邮箱与受理时限。验证：向该邮箱发送测试邮件，确认15个工作日内有回复记录。
F3 第三方共享：以表格列出所有SDK的接收方、字段、目的。验证：将表格与抓包得到的SDK清单比对，确认无遗漏。
F6 IMEI采集：与开发确认IMEI用途，若确无必要则移除采集代码；若必要则在政策中补充。验证：抓包确认启动时不再读取IMEI，或政策中已出现对应条目。

审查完成后，建议将上述6项整改结果回填至同一张审查表，形成“发现—整改—验证”闭环记录，作为下次政策版本迭代的基线。