个人信息保护合规审计哪个必须做

很多合规负责人卡在同一个问题上：审计到底是我们想做才做，还是不做就违规。法规里既有按规模触发的硬门槛，也有按风险事件触发的软要求，两者判断方式完全不同。这篇把强制触发的情形分门别类列出来，给出逐条自查的对照方法，也说清哪些情况其实不适用，让你能拿着结论去跟老板和外部机构对话。

很多合规负责人卡在同一个问题上：审计到底是我们想做才做，还是不做就违规。法规里既有按规模触发的硬门槛，也有按风险事件触发的软要求，两者判断方式完全不同。硬门槛看的是你手里攒了多少个人信息，软要求看的是你有没有踩到某类事件，一个是长期状态判断，一个是即时动作判断。

这篇把强制触发的情形分门别类列出来，给出逐条自查的对照方法，也说清哪些情况其实不适用。目标不是让你背条文，而是让你拿到一份能跟老板、外部审计机构对话的判断记录。具体门槛数值和条文原文，到站内的法规解读页面核对当时的数字，别靠记忆和转述。

先分清两类触发：按规模定时做，还是按事件随时做

判断自己是不是必须做，第一步不是翻条文找数字，而是先把触发类型定位清楚。按规模触发属于周期性义务，你达到门槛就一直背着；按事件触发属于偶发性义务，平时没有，一旦发生就被激活。两种义务的起算点、时间窗口、能不能委托外部机构做，都不一样。

• 先定位自己属于哪一类，再去看那一类的具体要求，混着看最容易误判
• 规模触发看的是长期状态，事件触发看的是某个时点发生了什么
• 两类义务可能同时存在，比如已经过线又刚好出了安全事件
• 判断结论要写下来，包括为什么这么判断，别只留在某个人脑子里
• 组织架构或业务模式变化后重新走一遍这个定位动作

按规模触发的自查：先数清你处理的是哪类个人信息

按规模触发的核心是统计口径，口径错了后面全错。统计范围要覆盖全部业务线，包括主App、小程序、公众号、客服会话系统、内部办公与人事系统里的存量数据，不能只算用户侧的主产品。很多团队漏掉的就是客服工单和办公系统里沉淀的联系人信息。具体门槛数值到站内的法规解读页面核对，不要用某个群里转发的口径当依据。

1. 做一次敏感个人信息识别先把身份证号、生物识别、金融账户、行踪轨迹、不满十四周岁未成年人信息等类别挑出来，敏感信息的数量门槛通常低于一般个人信息，分开统计比合并统计更稳妥
2. 按业务线分头导出数量每条业务线各自导出用户量、设备量或记录量，注明导出时间点和负责团队，避免各团队口径打架
3. 处理注销与删除数据用户注销、主动删除、超期清理后是否从统计中扣除，内部定一个一致口径并留下计算过程，同一份报告里不要两种算法混用
4. 记录临界值判断规模处在门槛附近时，建议按触发处理，把这个判断和理由写进合规台账，注明复核频次

统计结果建议做成一张表，每个业务线一行，列清数据类别、数量级、数据来源系统、统计时间、负责人。这张表比任何文字说明都有用，将来被问到口径时可以直接调出来复现同样的数字。数量级在报告里可以写区间，不必精确到个位，但计算过程要能追溯到原始导出。

按事件触发：这几类情况一发生就绕不开

按事件触发不看你的数据规模有多大，只看有没有发生特定情形。这类触发最容易被忽略，因为发生前大家都觉得自己不在范围内。合规负责人要做的不是等事件发生再反应，而是提前把这些情形列成清单，指定每个情形的发现渠道和上报路径，出事当天就知道该找谁。

• 发生个人信息泄露、篡改、丢失等安全事件，达到对外报送标准即触发后续审计动作，报送本身就意味着留痕
• 监管部门以书面形式要求开展审计或提交审计报告，属于被动强制，时间要求按监管文件执行，不接受内部排期拖延
• 开展高风险处理活动，例如大规模自动化决策、对外提供敏感个人信息、跨境传输个人信息，处理活动本身就可能带出审计义务
• 收购、合并、业务线剥离、系统迁移等主体或架构变动，接手方需要重新评估审计义务是否随之落下来
• 新产品上线前做过隐私影响评估的，评估中识别出的高风险项如果落地执行，也可能转成审计触发点

把上面这些情形做成一张触发清单，每条写清发现渠道：泄露事件来自安全监测和客服上报，监管要求来自法务收文，高风险处理活动来自产品变更评审，主体变动来自投融资或组织调整通知。清单之外的情况，判断为不触发也要简单记录理由，这条习惯能省掉很多事后解释。

谁必须做：处理者、受托方还是两边都有责任

义务主体通常是个人信息处理者，也就是决定处理目的和处理方式的那一方。受托处理方按合同约定配合，但配合不等于免责，受托方自己如果超出委托范围使用数据，也可能变成独立的处理者。判断自己是不是义务主体，看的是谁在决定为什么收集、收集来干什么，不是看系统部署在谁那里。

• 委托外部机构做审计时，主体责任仍在企业自身，报告署名和提交责任要在合同里写清楚
• 集团型组织按法人主体分别判断，子公司达到门槛不能靠母公司统一做一份糊过去
• 第三方SDK、外包客服、云服务商这类环节，要在采购合同里就把数据提供和审计配合写进去
• 判断主体资格看实质决策权，不看服务器在哪、系统谁运维
• 组织重组后重新确认一遍谁是新主体，别沿用旧判断

一个常见误区是认为把审计外包出去，责任也跟着外包了。实际上外部机构出的是专业意见，提交报告、落实整改、对外担责的还是企业自己。合同里要把工作范围、数据保密、报告归属、配合义务分条写清楚，特别是对方能不能拿你的数据做其他用途。

什么情况下不适用：别把自愿动作当强制义务

不少团队把各种检查都叫成审计，结果自己给自己加了一堆义务。内部自查、年度信息安全检查、等级保护测评，这些和法规意义上的个人信息保护合规审计不是一回事，不能互相替代，也不能因为做过其中一个就认为审计义务已经履行。判断适用不适用，要回到触发条件本身，而不是看动作名字像不像。具体口径到站内的法规解读页面确认，站内也整理了常见误判情形可以直接对照。

• 处理量明显低于门槛且未发生任何触发事件的小团队，通常不构成强制义务，这个结论要基于统计而不是感觉
• 客户或合作方在合同里单方要求你做审计，属于商业约定，不是法规强制，但违约后果要单独评估
• 已经做过一次审计不等于义务终止，触发条件再次满足时要重新开展，周期性义务尤其要注意
• 把等保测评报告直接当合规审计交上去，材料颗粒度和关注点都不匹配，很容易被退回
• 判断为不适用的，同样写一份简短说明归档，注明判断依据和复核时间

还有一种情况是行业主管部门或行业协会发了推荐性文件，鼓励开展审计。这类文件不构成强制义务，但如果你的客户集中在受监管行业，实际业务中很可能被要求提交，这时候按商业要求准备即可，不必写成法定义务。

落地动作：把判断过程留成可核查的记录

判断做完了不算完成，能复现才算完成。合规工作最怕的是换个人接手或者被监管问到时，没人说得清当初为什么得出这个结论。把触发情形做成对照表，逐条填是否满足、判断依据、数据来源、判断人、判断日期，这张表就是你的判断底稿。

1. 建表并逐条填空把规模和事件两类触发情形合并成一张表，逐条填，不合并条目，宁细勿粗
2. 保留计算过程数据口径的计算脚本或导出记录留着，别只留最终数字，不然复现不出来
3. 给不触发结论也留说明判断为不触发的，写三五句理由并归档，比事后口头解释有用得多
4. 设定复核节奏触发情形发生变化时更新记录，不要一年只在年初判断一次，业务变动、监管文件更新都是复核信号

记录不需要写得很长，但字段要齐。一个小团队用一张表加几份导出文件就能覆盖，关键是判断人、依据和时间三样都在。将来无论是内部治理复核还是外部问询，你都能拿这套记录说明当时的判断逻辑，而不是重新猜一遍。

确认为必须做之后，报告和材料怎么准备

确认为必须做之后，第一件事是明确这份审计给谁看。内部治理用的报告可以侧重问题和整改；提交监管的报告要求格式和颗粒度更严；合作方尽调用的通常只关心特定范围的合规状况。三种用途的材料不能一份到底，否则要么不够用，要么暴露不必要的信息。

• 证据链按处理活动逐项组织，覆盖告知同意、最小必要、对外提供、留存期限、安全措施等环节
• 审计发现的问题要有整改责任人和时间点，只有问题清单没有整改跟踪的报告通常过不了复核
• 涉及个人信息的证据材料本身也要做脱敏，别为了证明合规又造成一次泄露风险
• 留存年限和调阅权限按内部制度定好，谁能看、看多久提前约定
• 提交前确认报告的署名主体和提交渠道，别让外部机构以自己名义提交

材料准备阶段最耗时的往往不是写报告，而是找齐证据。建议平时就把处理活动清单、隐私政策版本、同意记录、对外提供合同这些材料按统一目录归档，审计启动时直接调取。审计机构的报价和工作量跟材料齐不齐关系很大，想比价和看机构类型的说明，可以到站内的机构与工具目录页面了解大致范围，具体数字以页面当时显示为准。