数据安全法规定了数据的收集、处理和使用的规范

你多半是在这样的场景里被卡住：业务要上一个新功能，法务问「收集这步的授权和最小必要做了没有」，技术问「处理阶段日志留多久」，没人能给出一份能对得上条文的清单。这篇不重述法条原文，而是把收集、处理、使用三段分别要落什么动作、留什么证据、按什么顺序自查讲清楚，末尾给一份可以逐条打勾的表。

你多半是在这种场景里被卡住：业务方要上一个新功能，法务追着问「收集这步的授权和最小必要做了没有」，技术又问「处理阶段日志留多久、放哪、谁能查」，两边都在等你给句话，可你手上只有一堆法条原文，对不上具体的动作。这篇不重述条文，而是把收集、处理、使用三段分别要落什么动作、留什么证据、按什么顺序自查讲清楚，末尾给一份能逐条打勾的排查表。

先说清一件事：这三段不是三个部门，而是同一份数据的三段生命期。同一批数据在收集阶段合规，不代表处理阶段就没事；处理阶段做得再严，使用阶段随手导出一样会翻车。所以排查的思路是逐段过，而不是找一个总负责人签个字了事。

先分清三个阶段：同一个动作在不同阶段要求不一样

判断一个动作属于哪一段，不看动作本身好看不好看，而看它对数据做了什么事。决定数据能不能进来，是收集；进来之后怎么存、怎么算、怎么传，是处理；算完了给谁看、给谁用、能不能再拿去干别的，是使用。三段要回答的问题不一样，要留的资料也不一样，混在一起谈就会变成「什么都重要，什么都没做」。

收集

回答能不能收、收多少、凭什么叫用户同意，举证重点是用途说明与授权凭证

处理

回答存多久、谁能碰、出不出生产库，举证重点是分级规则与操作记录

使用

回答给谁看、能不能对外、能否二次利用，举证重点是共享审批与输出字段清单

一个特别常见的误判，是把「我们没主动采集」当成安全区。通过第三方间接拿到、用户在表单里顺手填的、系统日志被动落下来的痕迹，其实都落在收集环节里，一样要进清单。判断标准很简单：数据第一次进入你能控制的存储，这个动作就是收集，不管是你写代码去拉的，还是别人送过来的。

• 项目立项表里直接分三列：收集、处理、使用，各写一行要做的事，别等内容上线再回头补
• 每列写清负责人和判断依据，写「按合规要求处理」这种话等于没写
• 评审时先过收集列，收集没定不要往下走处理和使用的细项
• 上线前复查一次，功能改过的项目尤其要看用途是否变了

收集环节：用途先定、范围先砍、告知与同意要能举证

顺序别搞反。很多人是先接了埋点、跑起来了，再回头补一份用途说明，这时候已经晚了，因为你没法证明当初就打算这么用。正确做法是先写「用途说明书」，一句话说清这条数据拿来干什么，再一句话说清不干什么，最后写清多久不用就删。用途写不清的字段，直接不采，别犹豫。

1. 第一步：写用途说明书每个字段写三件事：支持哪个功能、不用于什么、不用时怎么退场。写不出来的字段先搁置
2. 第二步：过最小必要判定判断标准是「缺了它这个功能是不是真的做不了」，做不了才采；凡是「以后可能有用」「先存着再说」的一律先不采
3. 第三步：确认告知与同意要能拿出用户当时看到的那一版文本和同意的时间点，不是拿现在的最新版去解释当时的授权
4. 第四步：判断旧同意是否覆盖新用途产品改版后新增了用途，旧同意往往盖不住，拿不准就重新征求，别默认沿用

什么情况下收集环节可以松一点？纯匿名、不可复原、且做过复原风险评估并有结论的数据集，可以少走一部分同意类的流程。但前提是那份评估真的做了、有结论、有版本，不是嘴上说「我们脱敏了」。

处理环节：分级、留存、脱敏、访问控制四件事定死

处理环节最容易变成一笔糊涂账，因为技术细节多、责任又散。抓四个点就够了：分级、留存、脱敏、访问控制。这四件事里任何一件没有明确规则，都会在后面审计时被反复追问。尤其是分级，它决定了后面三件事怎么落，规则要写进制度，不能留在某个老员工的脑子里。

去标识化、脱敏、加密这三样，经常被当成同义词用，其实各自解决不同的问题，不能互相替代。选哪种、用在哪个环节、边界在哪，建议到 数据脱敏怎么做（/guides/data-masking-howto） 对着自己的场景看一遍，别抄别人的方案。

• 留存期限写触发条件而不是写年数，触发条件到期就走删除或归档流程
• 处理环节要留的是操作记录，不是结果截图，谁在什么时候对哪批数据做了什么才是审计要的
• 测试环境默认用假数据，非要用真实数据必须单独审批并记录批次和用途
• 删除动作要能验证，删完留一份删除执行的记录，而不是「已经删了」的口头确认

使用环节：输出到哪里、给谁、能不能二次利用

使用环节最容易出事的不是内部看一眼，而是「给出去」和「再拿去做别的」。把内部使用和对外提供分开管：跨部门共享、导出报表、接第三方工具、上传到外部平台，这些都算对外提供，需要单独授权和记录。判断标准是数据有没有离开你的控制范围，离开了就算对外，不管接收方是兄弟部门还是合作方。

用于训练、建模、分析这类二次利用，是高风险动作，因为它和当初告知用户的用途往往对不上。这类动作用途变了、场景变了，要单独评估，不能沿用原来的授权。如果你是把数据喂给外部模型，供应商那边怎么留、留多久、能不能用来训练自己的模型，都是必须问清的。具体怎么问、看哪些项，可以参考 调用外部模型的数据留存期限怎么看（/guides/model-data-retention-timeline） 里的做法。

留证：出事时能证明你做了什么，比做得多漂亮更重要

留证这件事，重点不是你做得多好，而是能不能证明你做了。平时看着完整的一堆截图，真到被追问的时候往往顶不上用，因为截图上没有时间、没有版本、看不出是谁批的。要留四类东西：制度与流程版本、数据流向图、授权与同意凭证、操作与审批记录。缺哪类补哪类，优先补时间戳清晰的那类。

• 制度和流程改了要留版本号与生效时间，否则事后说不清当时适用的是哪一版
• 数据流向图要标清数据从哪来、经过哪些系统、最后到哪去，跨系统尤其要标
• 授权与同意凭证要能对应到具体字段和具体用途，泛泛的「已同意」没有意义
• 操作与审批记录要包含时间、操作人、对象、动作，缺一项都容易被质疑

留证本身也会带来新风险。有人为了证明自己留了记录，把原始数据里的敏感字段整段存进日志，这等于把问题从「没留证」变成「多留了不该留的」。日志里该出现什么、不该出现什么，建议对照 日志里不该出现什么（/guides/log-redaction-retention） 检查一遍，别让留证动作变成新的隐患。

还有一种情况要特别注意：涉及跨境或用了第三方的情况，证据链要延伸到对方。只有自己这边的记录，说明不了全流程。这时候合同条款、对方给的合规说明、数据处理协议都算证据链的一部分，要在选供应商时就要，别等出事再去补。

自查顺序：先定范围，再看环节，最后看证据

自查最怕一上来就翻细节，翻到最后发现漏了一整个系统。顺序应该是先定范围，再逐段过环节，最后反向验证证据。这个顺序的好处是每一步都有明确的结束标志，不会无限期拖下去，也不会因为抓小放大而漏掉大问题。

1. 第一步：拉数据资产清单按业务系统列，不按部门列，因为部门会调整、系统不会凭空消失。漏系统的自查一定不完整
2. 第二步：逐段过收集、处理、使用每发现一条问题就标注责任人和整改期限，不要停在「已知悉」，已知悉是最没用的结论
3. 第三步：反向验证证据问自己一句「如果监管今天来问，我能当场拿出什么」，拿不出的就是优先补的项
4. 第四步：比对制度与配置这步通常会暴露出技术配置和制度文本对不上，这个差距本身就是最该先修的地方

什么情况下这套顺序要调整？如果你的组织是按项目走的、没有统一的系统台账，那第一步可能要改成按项目拉清单，再从项目归集到系统。原则不变：先保证范围不漏，再谈细节。

哪些情况下这套清单不适用或要加码

这套清单是按一般场景写的，有几类情况要单独判断。第一类是纯匿名化且不可复原的数据集，收集与同意类的要求可以放宽，但前提是复原风险评估做过并有结论，没做过评估就不算数。第二类是涉及重要数据、核心数据，或者行业监管另有规定的，这套清单只是起点，要叠加行业要求和专门的评估流程，别指望一份通用清单打天下。

第三类是小团队。数据量极小、只做内部单机处理、完全不外传的场景，可以把清单压到最小集，但仍然要留用途说明和留存期限这两样，因为这两样是后面所有判断的基础。这里说的最小集不代表免做，而是把动作压到最少但保留举证能力。

还有一类容易被忽略：当你的业务形态发生变化，比如从只做内部工具变成对外提供服务，原来那套按最小集走的做法就不适用了，要按新场景重新过一遍三段。形态变了，清单跟着变，别拿旧结论套新业务。