「以防万一」全部留着,是大多数公司的默认做法,在隐私法下却是负担。本文讲法律依据、保留政策的七个部分、一张把含个人数据的事件和长期汇总分开的示例时间表,以及一个产品把原始事件保留期从 4.5 年降到 13 个月后发生了什么。
读完你会知道
- GDPR 要求个人数据保存不得超过必要期限
- 每类数据都要定期限、目的、负责人和到期处理
- 汇总留长,事件级个人数据留短
- 自动删除,导出文件和备份也要覆盖
- 在隐私声明里公布保留期
什么是数据保留政策?
数据保留政策(Data Retention Policy)是一套成文的规则,针对组织持有的每一类数据,规定保存多久、为什么、存在哪里,以及到期后怎么删除或匿名化。它覆盖客户记录、统计事件、日志、备份、邮件和文件。
保留政策出于两个相反的原因:有些数据必须保存一个最短期限(税务记录、合同),而个人数据又不能保存得比必要的时间更长。好的政策两头都满足,而且是自动执行的,不只是写在纸上。
为什么重要:法律依据
| 法律 | 关于保留的规定 |
|---|---|
| GDPR 第 5 条第 1 款 (e) 项,存储限制 | 能识别个人的数据,保存时间不得超过收集目的所必需的时间 |
| GDPR 第 13、14 条 | 必须告诉用户数据保存多久,或者用什么标准来决定 |
| GDPR 第 17 条,删除权 | 数据不再必要时,用户可以要求删除 |
| 加州(经 CPRA 修订的 CCPA) | 企业要披露每类个人信息保存多久,且保存时间不得超过合理必要的期限 |
| 税务和会计法规 | 发票和财务记录有最短保存期,按国家不同常见 6 到 10 年 |
监管机构专门因为数据保存过久而罚过款。罚款之外,个人数据每多存一个月,就多一份要保护的东西、处理数据主体请求时多一份要查的东西,一旦泄露也多一份损失。
保留政策包含什么
- 范围: 覆盖的系统和数据类别(生产数据库、统计、日志、备份、SaaS 工具、表格)。
- 保留时间表: 一张表,列出数据类别、保留期、法律依据或目的、负责人,以及到期后的处理(删除、匿名化、归档)。
- 起算点: 从什么时候开始计时:采集日期、最后活跃、合同结束、撤回同意。
- 删除方式: 自动任务、匿名化还是人工处理;备份怎么过期。
- 例外: 诉讼保全怎么审批、怎么解除。
- 角色: 每类数据谁负责、谁审批变更、谁审计。
- 复审周期: 至少每年一次,新增系统或用途时也要复审。
统计数据的保留时间表示例
某 SaaS 公司统计及相关数据的时间表(示例政策,请按自己的目的和适用法律调整):
| 数据类别 | 保留期 | 原因 |
|---|---|---|
| 带假名 ID 的原始统计事件 | 13 个月 | 同比需要 12 个月再留余量 |
| 自动采集的点击和表单交互 | 90 天 | 只用于近期的体验排查 |
| 每日汇总(不含个人数据) | 长期 | 不是个人数据;长期趋势需要 |
| 实名用户档案 | 最后活跃后 24 个月 | 召回和客服历史 |
| 同意记录 | 失效后 24 个月 | 被质疑时证明取得了同意 |
| 带 IP 的服务器访问日志 | 30 天 | 安全调查窗口 |
| 数据导出和临时 CSV | 7 天 | 副本是最常见的泄露来源 |
| 发票和付款记录 | 按税法(常见 6–10 年) | 法定义务,不属于统计 |
关键的设计是把事件级数据(含个人数据,保留短)和汇总数据(不含个人数据,保留长)分开。这样能保住长期趋势,却不必一直留着人的数据。
| 法律 | 保留规则 |
|---|---|
| GDPR 第 5 条 1(e) | 不超过必要期限 |
| GDPR 第 13–14 条 | 告知保存期限 |
| GDPR 第 17 条 | 不再需要时删除 |
| CCPA / CPRA | 按类别披露期限 |
| 税法 | 财务记录有最短期限 |
不构成法律意见,请核对适用于你的法律。
计算示例:把「永不删除」改成 13 个月会怎样
某产品每天发送 12 万个事件,上线 4.5 年来所有原始事件都留着(示例数字):
- 存储的行数: 约 1.97 亿。改成 13 个月后约 4,700 万,少了 76%。
- 存有历史的实名用户: 41 万,其中 29 万已超过两年没活跃。执行政策(最后活跃 24 个月后删除档案)后剩 12 万。
- 数据主体请求的查找范围: 以前一次删除请求要查全部 1.97 亿行,外加共享盘里翻出来的四份临时 CSV 导出;现在只查 4,700 万行,导出文件 7 天后过期。
- 受影响的报表: 日常看板一个都没有。三年以上的长期图表改从每日汇总读取,汇总里没有个人数据。
公司的数仓存储费用也降了,但更大的收益是泄露时影响更小、合规更简单。
存储行数
−76%
▼
保留的档案
−71%
▼
坏掉的报表
0
保留期调整 · 永不删除 → 13 个月
每天 12 万个事件| 调整前 | 调整后 | |
|---|---|---|
| 原始事件行数 | 约 1.97 亿 | 约 4,700 万 |
| 实名用户档案 | 410,000 | 120,000 |
| 翻出的临时 CSV 导出 | 4 份 | 7 天后过期 |
| 受影响的看板 | — | 没有 |
示例数字。长期图表改读不含个人数据的每日汇总。
怎么制定数据保留政策
- 盘点数据: 列出所有存储个人数据的系统,包括 SaaS 工具、日志和导出文件。
- 给每类数据定目的,再定满足这个目的的最短期限。「可能有用」不算目的。
- 和法务或财务确认法定最短期限,比如财务、雇佣和合同记录。
- 决定到期处理方式: 删除、匿名化或汇总。
- 自动执行。 定时任务、产品里的保留设置、存储的生命周期规则。靠人工执行的政策通常没人遵守。
- 处理备份: 按固定周期过期;不要把已删除的个人数据恢复回生产环境。
- 在隐私声明里公布保留期,这是第 13、14 条的要求。
- 每年复审并记录变更。
常见错误
- 默认「全部保留」。 最常见、代价也最大的错误。
- 所有数据一个期限。 不同类别服务不同目的。
- 忘了副本: 导出文件、表格、BI 抽取和测试数据库。
- 删掉了还要用的汇总。 先汇总,再删事件级数据。
- 没有负责人。 没人负责的政策,会随着新工具的加入而走样。
TapCub 里的保留设置
在配置 › 隐私中心 › 数据最小化与保留里,TapCub 分别设置四个期限:事件行(默认 365 日)、自动采集(90 天)、用户档案(730 天)和同意记录(730 天),由定时任务删除过期的行。实际的事件保留期不能超过所用套餐的上限。每日汇总不含个人数据,不受这些计时影响,所以长期趋势会保留下来。分层衰减可以在到期前清空较早事件里属性、来源网址、标题这类高基数字段,同时让趋势和漏斗照常可用。IP 地址在采集时截断,不存在事件里。见 IP 截断和保留期、数据导出和删除和处理数据主体请求。更整体的做法见隐私设计。
参考资料
- European Union. GDPR Article 5: principles relating to processing of personal data (storage limitation).
- UK Information Commissioner's Office. Principle (e): storage limitation.
- California Civil Code §1798.100 (CCPA/CPRA retention disclosure).
这篇文章对你有帮助吗?
我们会根据反馈修改和补充这篇内容。
提交没有成功,请稍后再试。
谢谢你的反馈,我们会据此改进这篇内容。你已经反馈过这篇了,谢谢。



