合规团队接到要做个人信息保护审计的任务,最常卡在第一步:范围到底划多大。划太窄,审完还是漏;划太宽,人力和时间都不够用。这篇给一份按块拆开的范围清单,告诉你每一块要核哪些材料、找谁要、怎么留证,以及什么情况下可以把某块降级处理。
接到个人信息保护合规审计的任务,很多团队第一步就卡住:范围划多大。划窄了,审完还是漏掉关键环节;划宽了,人力和时间都不够用。比较稳的做法是先把范围写成一张可勾选的清单,而不是一上来就翻制度文件。
这篇按块拆开讲:每一块核什么材料、找谁要、怎么留证,以及什么情况下可以把某块降级为不适用。范围一旦定下来让业务和法务各签一次字,后面所有争议都以那版为基准。
先定范围:按三层把项目圈出来
范围不是一个笼统的边界,而是三层叠出来的:主体、数据、环节。三层各写一版清单,任何一层改动都要回到另外两层重新对一遍,避免出现「主体加了、数据没加」这种半截范围。
| 层次 | 圈什么 | 落纸形式 |
|---|---|---|
| 主体范围 | 哪些法人、哪些业务线、哪些 App 或小程序算在内 | 名单+不在范围内的理由 |
| 数据范围 | 按系统、按字段列出收集了哪些个人信息,敏感项单独标 | 数据地图或字段清单 |
| 环节范围 | 收集、存储、使用、共享、传输、删除六段 | 逐段标注「查」或「不适用」 |
- 不在范围内的主体和数据要写清理由,避免开工后被要求临时加码
- 敏感个人信息在数据地图里单独标出来,后面留证和脱敏口径都不一样
- 六段环节里没做的不要直接跳过,标成不适用并写明依据
- 三层清单定稿后让业务与法务各签一次字,作为后续争议的基准版本
分块核查:每块看什么、找谁要
范围定完就开始分块核查。每一块都对应固定的对口人和固定材料,不要全压在法务一个人身上。下面这张对照表可以直接当派工单用。
| 核查块 | 看什么 | 找谁要 |
|---|---|---|
| 告知与同意 | 隐私政策与产品实际弹窗是否一致 | 产品、法务(要版本记录与更新日志) |
| 权限与采集 | 每个权限的申请时机、能否拒绝、拒绝后果 | 客户端开发 |
| 第三方共享 | SDK 与外部服务清单、是否写入告知、是否签数据处理协议 | 研发、采购 |
| 存储与出境 | 哪些数据在境内、哪些会传出去 | 运维、架构 |
| 删除与响应 | 删除、更正、注销入口能否走通 | 客服、运维(脱敏处理记录) |
存储与出境这一块判断依赖当时的监管口径,写结论时别抄旧文档,到站内出境与合规资料页核对当时的数字和路径。每一块的核查结论后面都要挂上证据编号。
证据怎么留:审计报告里能站住脚的东西
审计报告能不能站住脚,取决于证据而不是结论写得漂不漂亮。实操上有几条硬规矩,照做能省掉后面大量的返工。
- 结论挂证据每一块结论后面必须挂截图、配置导出文本、会议纪要之一,附上操作时间。缺证据的结论一律写成「待确认」,不要写成「已合规」。
- 证据集中存放所有证据放一个只读目录,按块编号,报告里只引用编号,不随手贴图。这样报告改版时证据不用重排。
- 留证前先脱敏敏感字段在留证前先脱敏,别为了证明合规反而造出一份高危文件。脱敏口径和字段范围可以到站内脱敏与数据安全页面核对当时的说明。
- 问题单独立表审计期间发现的问题单独开整改表,写清责任人和预计完成时点,不要混进结论段落里,否则报告会变成一锅粥。
什么情况下可以降级或不适用
不是每一块都要审到最深。下面这些情况可以降级或不适用,但理由必须落纸,不能口头说一句就跳过。
- 不面向自然人
- 业务只处理企业联系人信息的模块,说明理由后可缩小到基本项。
- 量小且不敏感
- 数据量很小、不涉及敏感个人信息、也没对外共享,第三方和出境两块可并成一次确认,结论仍要落纸。
- 新上线缺历史
- 刚上线的产品没有历史记录,用当前快照加一段观察期补证,不要硬编一份时间线。
- 范围被临时扩大
- 上级或客户临时加范围时,先回到第一层基准版本再谈,别直接在原计划上叠加。
降级判断本身也有边界:一旦某块降级后又被发现在实际业务里真实发生,之前的不适用结论要立刻作废并重审。这也是为什么降级理由必须写清适用范围。
下一步把上面三层范围清单和分块对照表复制成你们自己的勾选版,逐块填对口人和证据编号;出境、脱敏、数据安全这些具体口径随时会变,到站内资料库核对当时的数字再定稿。→常见问题
范围划小了会不会被认定漏审?
看有没有说明理由。把不涉及个人信息、业务已下线、数据已删除这几类情况逐条写明依据,通常比硬塞进来审一遍更站得住;反过来,什么都写不适用又拿不出依据,就容易被追问。
审计要覆盖多久的数据?
没有统一口径。常见做法是覆盖一个完整业务周期,再把期间发生过的重大变更单独拉出来看;周期长度和变更清单要在范围文档里写死,避免执行中被来回追问。