底稿一：处理活动记录
按业务线记录处理目的、字段范围、合法性基础、保存期限、共享对象与安全措施。这份记录是审计的主线，缺它就只能靠访谈拼凑，结论也难以复核，更无法在业务变化时判断哪些环节需要重新评估。怎么维护：按处理活动记，变化时更新。
底稿二：同意与告知证据
保留告知页面版本、勾选记录、单独同意的取得方式与时间。常见问题是页面改版后旧版本未存档，无法证明当时的告知内容，争议时说不清，也难以说明用户是否知道自己的数据会被如何使用边界在于告知证据要按版本归档。
底稿三：请求处理记录
查阅、更正、删除、撤回同意的请求要有工单编号、处理时限与结果。审计时抽样核对是否在承诺时限内完成，未完成的要说明原因与补救，否则无法判断是流程问题还是个别遗漏，也无法区分流程缺陷与个人疏忽。怎么留：工单要带时限字段，结果可导出统计。
方法：文档审阅加抽样
先审文档看制度是否齐备，再抽样看执行是否到位，两者结合才能发现制度齐全但执行缺位的情况。抽样按业务线与风险等级分层，样本量写进方案，避免结论随意，也便于下一期横向比较。怎么抽：先把分层写进方案，再固定样本量与复核人。
输出：问题分级与整改
问题按高、中、低分级，高危项限期整改并复查，中低危纳入计划。审计报告要写清范围、方法、发现与责任人，作为下一次审计的对照基线，避免每期都从零开始，问题反复出现，整改才有方向。边界在于分级决定整改谁先动。
适用与不适用
适合谁
- 准备接受个人信息保护合规审计的企业
- 需要向客户证明数据合规的服务商
- 集团内需要统一审计口径的总部团队
不适合谁
- 尚未开展个人信息处理活动的团队
- 只想买一份审计报告模板的企业，也不做抽样
典型场景
某电商平台在年度审计前整理处理活动记录，把告知页面各版本、同意勾选日志与删除请求工单归档，审计组按业务线抽样核对时限与结果，把未在期限内完成的请求列为高危项，限期整改并在三个月后复查关闭情况。
可执行步骤
- 按业务线整理处理活动记录，补齐字段与期限，缺字段的当场补齐，并按处理活动分组
- 归档告知页面版本与同意记录，注明生效时间，改版前的旧页面也要保留
- 导出请求处理工单，核对时限与结果并标注异常，超期项单独列出，注明导出时间
- 按业务线与风险分层抽样，样本量写进方案，抽样单由复核人签字，结论可交叉验证
- 问题分级、限期整改，并在下一期复查关闭情况，未关闭的升级到管理层，形成整改闭环
常见坑
- 处理活动记录靠访谈补写，与实际系统不符，审计结论站不住，整改方向也跟着偏，投入难以收敛，检查时无法说明
- 告知页面改版未存档，事后无法证明当时的内容与勾选方式，争议时只能被动解释，处理周期拉长
- 请求工单无时限字段，无法判断是否超期，也分不清个案还是普遍问题，复查缺少依据，整改易走偏
- 问题不分级，高危项与低危项一起排队，资源被低危项占用，真正该改的一直没动，复查没有重点，资源被浪费
自检与验收清单
- 处理活动记录是否覆盖主要业务线，是否含处理目的
- 告知与同意证据是否可按时间检索，旧版本是否存档
- 请求处理是否有工单与时限字段，是否可导出统计
- 抽样方法与样本量是否写入方案，是否分层抽样
- 高危问题是否限期复查并记录结论，是否注明期限
常见问题
审计必须请外部机构吗？
取决于监管要求与企业自身安排。内部审计也能发现问题，但独立性较弱；外部机构在方法与本位判断上更中立。无论哪种，底稿质量决定审计价值，材料不全会让审计变成访谈记录。
处理活动记录要多细？
到业务线与字段类别即可，不必逐条列每个字段，但要能说明目的、范围、基础与期限。过细难以维护，过粗无法支撑判断，建议按处理活动为单位记录，并在业务变化时更新，不要只写原则。
发现超期未处理请求怎么办？
立即补处理并记录原因，评估是否属于系统性问题，修订流程与时限提醒机制。审计报告应如实反映，掩盖问题会在下一次审计或监管检查中放大，也会削弱整改的可信度。