法务被业务问到「我们到底要不要做个人信息保护合规审计」,常见卡点是:法规里既有必须做的情况,也有鼓励做的情况,分不清自己属于哪一类。这篇不给结论式承诺,只给一套判断顺序——先看触发条件,再看数据和处理活动的规模与敏感度,最后看有没有替代手段。照着走一遍,能给管理层一个站得住脚的答复。
法务被业务问到「我们到底要不要做个人信息保护合规审计」,卡点通常不在法规难懂,而在于条文里既有必须做的情况,也有鼓励做的情况,分不清自己属于哪一类。先别急着下结论,按一套固定顺序走:先看触发条件,再看数据和处理活动的规模与敏感度,最后看有没有替代手段。走完一遍,你能给管理层一个站得住脚的答复,而不是一句「应该没事」。
下面这套判断不是法律意见,是一份自检路径。真正拿不准时,把条文原文和你自家的处理活动清单一起交给外部律师过一遍,比自己拍板稳妥。另外要提醒一句:本文不给任何结论式承诺,同样的业务形态换个行业、换个客户要求,答案就可能反过来。
先分清:哪些情形是被要求做,哪些只是被鼓励做
读条文时第一件事是圈词。出现「应当」「定期」这类表述的,通常对应强制或周期性义务,不做会有明确后果;出现「鼓励」「可以」的,属于倡导性条款,不做一般不直接构成违法。这三类表述的法律后果完全不同,混在一起看,就容易把鼓励当成必须,或者把必须当成建议。
| 表述类型 | 大概含义 | 法务动作 |
|---|---|---|
| 应当 / 定期 | 强制或周期性义务 | 排进计划,留出预算和人力 |
| 鼓励 / 可以 | 倡导性,非强制 | 记录判断理由,纳入观察 |
| 未提及 | 无直接要求 | 按业务风险自行决定 |
- 把自家情况对到三类里:处理敏感个人信息、处理规模较大、涉及自动化决策或对外提供,这些通常落进前两类。
- 拿不准就别自己下结论,把条文原文和处理活动清单一并交给外部律师。
- 圈词的时候顺手把条文出处和版本记下来,后面答复管理层要用。
判断适用性:从数据和处理活动两个维度自检
适用性判断可以拆成两个维度,分开看比笼统问「我们要不要做」清楚得多。数据维度回答「我们手里是什么」,活动维度回答「我们拿它做了什么」。两个维度都不碰高风险项的,通常不构成强制触发,但仍可能落在被鼓励的范围内,要看业务后续会不会变。
- 数据维度
- 看有没有敏感个人信息、有没有不满十四周岁未成年人的信息、数据量级是否到了需要单独关注的档。
- 活动维度
- 看有没有对外提供、跨境、委托处理、自动化决策这类高风险动作。
- 口径核对
- 术语边界容易各家理解不一,对着站内术语对照确认,别靠印象。
自检时建议逐条打勾,而不是凭整体印象。比如一家 5 人小团队做内部工具,只存员工通讯录,两个维度基本都不碰;但同一家团队如果开始给客户做数据分析,把客户数据接进来,活动维度立刻变了。
- 把数据处理活动按「收集—存储—使用—共享—删除」列一遍,每步标注是否涉及高风险动作。
- 对每一项数据标注敏感级别和量级档位,别写具体条数,写「是否需要单独关注」。
- 两个维度都无触发的,把判断依据和判断时点写下来存档。
- 口径拿不准的,到站内术语对照页面核对后再定。
真要做,审计范围怎么圈、由谁来做
如果判断下来确实要做,第一步是圈范围。圈范围的正确单位是「处理活动」,不是「部门」。按部门列容易漏掉跨部门流转的链路,按处理活动逐条列,才能看清数据从哪来到哪去、经过谁的手。处理目的、处理方式、存储与传输链路、共享对象,这四项都要落到纸面。
- 列出处理活动清单按业务实际的数据流逐条列,每项写明目的、方式、存储位置、对外共享对象。
- 确定执行主体内部团队做还是委托外部机构做,取决于你需要多强的独立性证明和证明力。
- 执行并留痕谁审的、依据什么、结论是什么、谁签字,四样缺一样,报告说服力就打折。
- 管理审计报告本身报告也是个人信息,怎么存、谁能看、留存多久,参考站内安全分区的其他条目,别只交一页结论。
什么情况下可以先不做,以及什么时候要回头补
业务只处理少量内部员工信息、没有对外提供和跨境、没有自动化决策的,通常可以先不做正式审计。但「先不做」的前提是留住判断依据:当时依据什么条款、由谁判断、判断时点是什么,都要写下来。不然过半年换个人接手,连当初为什么不做都说不清。
- 处理活动一变、数据量级一变、业务上线新功能,原来的适用性结论就作废,要重新判断。
- 把重新判断的责任挂到具体的上线流程或变更流程上,而不是挂在某个人的记忆里。
- 外部要求来时再补做,往往比按节奏做更被动,代价是临时凑材料、赶时间。
- 「先不做」不等于「不用管」,它只是一个有条件的临时结论。
| 变化信号 | 是否要重新判断 | 谁负责 |
|---|---|---|
| 新增对外提供或跨境 | 要 | 业务发起方 + 法务 |
| 数据量级明显上升 | 要 | 数据负责人 |
| 上线自动化决策功能 | 要 | 产品 + 法务 |
| 仅内部人员微调 | 一般不要 | 记录即可 |
给管理层和业务的答复模板
法务给管理层的答复,要求是能被复述、能被追责到人。开头先给一句话结论:我们属于哪一类,依据是哪几条表述,风险敞口在哪。接着给配套动作:要么排进计划,写明时间点和责任人;要么写明重新评估的触发条件和责任人。别用「应该没事」这类表述,它既不能被复述,也追不到人。
| 答复要素 | 写什么 | 避免写什么 |
|---|---|---|
| 结论 | 属于哪一类、依据哪条 | 应该没事、问题不大 |
| 敞口 | 风险点在哪、影响谁 | 笼统的「有一定风险」 |
| 动作 | 排计划或写触发条件 | 以后再说 |
| 时点 | 判断是何时做的 | 不写时间 |
| 责任人 | 挂到岗位或流程 | 挂到某个人名 |
最后提醒一句:答复里要附上判断时点,并注明后续影响判断的因素。别人拿着这份答复去决策,半年后情况变了,至少能看出当初的判断前提是什么,而不是觉得法务给了一个永远成立的保证。
下一步想先确认自家数据和处理活动到底算不算高风险,可以对照站内术语与安全分区的条目过一遍,把口径统一了再谈要不要做审计。→常见问题
不做会有什么后果?
后果取决于你属于哪一类情形。落在被要求做的那一类而没做,主要风险是在监管检查、客户尽调或事故追责时拿不出审计证据,处理活动的合规性要靠自己举证。落在被鼓励做的那一类,通常不构成直接违法,但一旦业务量级或处理方式变了,就要重新判断。具体条款口径以当时有效的法规为准。
小公司是不是就不用做?
规模小不等于自动豁免。判断看的是处理活动的性质,不是公司人数。一家 5 人小团队如果做的是收集大量用户敏感信息的产品,照样可能落进被要求做的那一类;反过来,几十人的公司只处理内部考勤信息,通常可以先不做。别拿公司规模当挡箭牌,拿处理活动清单说话。
审计应该多久做一次?
没有放之四海皆准的固定周期。更实用的做法是绑事件和绑周期:处理活动发生实质变化时重做,同时设一个常规复核节奏,具体节奏看行业惯例和监管口径,到站内 /safety 对照当期要求确认。只做一次就归档、之后再不过问,是最常见的失效方式。