3、数据生命周期管理：从采集、存储、使用、共享到删除，全链路合规要点

数据合规这件事，说白了就是管好数据的“一生”。从它被生出来（采集），到它被销毁（删除），中间每一个环节都可能踩雷。我见过太多团队只盯着“存储加密”和“传输加密”，结果在采集和共享环节翻了车。

今天我们就按数据流动的顺序，把每个阶段的合规要点捋一遍。你想想看，一条数据从用户手机到你服务器，再到第三方 SDK，最后被删除，中间有多少双眼睛盯着它？

3.1 采集阶段：合规的起点，也是最容易翻车的地方

数据采集是合规的“第一道防线”。我个人习惯把采集合规拆成三个问题：为什么采？采什么？怎么采？

• 为什么采 —— 必须有明确、合法的目的。不能“先采了再说，以后可能用得上”。
• 采什么 —— 遵循“最小必要”原则。能采设备型号就别采 IMEI，能采粗略位置就别采精确 GPS。
• 怎么采 —— 必须告知用户并获得同意。默认不采集，用户主动授权后才开始。

这里有个实操要点：采集行为必须与隐私政策描述一致。你隐私政策里写“仅用于地图导航时采集位置”，结果 App 一启动就弹窗要位置权限，这叫“超范围采集”。

3.2 存储阶段：加密是底线，分级是能力

数据存下来之后，合规压力并没有消失。我见过不少团队把用户数据往云上一丢就不管了，结果被拖库后才发现连基本加密都没做。

存储阶段的合规要点，我总结为“三件套”：

3.3 使用阶段：内部管控是核心

数据被内部员工或系统使用时，合规风险往往来自“内部人”。你想想看，一个运营人员能不能随意导出全量用户手机号？一个算法工程师能不能直接查看用户明文地址？

使用阶段的合规要点：

• 访问控制 —— 基于角色的权限管理（RBAC），最小权限原则。能看脱敏数据的，就不给看明文。
• 操作审计 —— 谁在什么时间、通过什么接口、访问了哪些数据，全部记录日志。
• 目的限制 —— 数据只能用于采集时告知的目的。不能拿“优化推荐”的名义采集的数据去做征信评估。

嗯，这里要注意：内部使用不等于可以随意使用。我曾经遇到一个案例，产品经理为了做用户画像，直接在生产库上跑 SQL 查询全量用户行为数据。这既违反访问控制，又违反目的限制。

3.4 共享阶段：第三方是最大的黑盒

数据共享给第三方（SDK、合作伙伴、关联公司），是合规重灾区。为什么？因为数据一旦出去，你就很难控制对方怎么用了。

共享阶段的合规要求：

1. 事前评估 —— 对接收方进行数据安全能力评估，不能“谁要都给”。
2. 签署协议 —— 明确约定数据用途、安全措施、违约责任。
3. 告知同意 —— 在隐私政策中披露接收方类型、共享目的、数据范围。
4. 最小共享 —— 只共享必要字段，能传脱敏数据就不传明文。

3.5 删除阶段：不是“删了就行”，而是“彻底消失”

删除是数据生命周期的终点，但很多人对“删除”的理解太浅了。你以为点了“删除用户”按钮就完事了？备份数据里还有、日志里还有、CDN 缓存里还有……

合规意义上的删除，要求：

• 不可恢复 —— 覆盖写、物理销毁或加密后丢弃密钥。
• 全量删除 —— 主库、备库、缓存、备份、日志，一个都不能漏。
• 删除确认 —— 用户发起删除请求后，应在承诺期限内完成，并通知用户。
• 保留删除日志 —— 删除操作本身需要记录，用于合规审计。

3.6 全链路合规检查清单

最后，我整理了一份自检清单。每次上线新功能或接入新 SDK 时，对着过一遍，能挡住 90% 的合规风险。

数据生命周期管理，说白了就是“从生到死”都要管。每个阶段都有独立的合规义务，但更重要的是全链路视角——上一个阶段的合规缺陷，会像病毒一样传染给下一个阶段。采集违规，后续所有处理都违法；删除不彻底，存储和使用阶段就一直在违规。

我个人习惯在项目启动阶段就把这张生命周期图贴在墙上，每个迭代都对照检查一遍。养成习惯后，合规就不再是负担，而是工程质量的组成部分。