一个人的隐私工程：数据地图、最小化与删除权（10 篇）

隐私不是一份政策文档，是每个字段从进来到消失的整条路径。

这个系列解决什么问题

一个人做产品，数据是顺手收进来的：注册表单多一个字段、埋点多一个属性、日志多打一行、模型调用多带一段上下文。收的时候没有成本，删的时候才发现要改 9 张表、5 个外部接口和 2 个保留期。

这个系列把「数据怎么进来、怎么用、怎么出去」拆成十篇：先画一张能回答安全问卷的数据地图，再把没人读的字段删掉；然后处理四类目的与三类同意，核对政策与产品行为是否一致；接着处理三类数据主体请求、删除的级联与保留期；最后处理跨境、供应商与泄露响应，用十二项检查做季度验收。

它服务的是一个没有法务、没有安全团队、每月只能拿出三小时的人。 你能投入的不是一套合规体系，而是一张字段表、四个清理任务和一次两小时的演练。

核心主张：五条口径

• 说不清字段，就谈不上合规。 78 个字段各自从哪来、给谁、存多久，答不出来时，隐私政策只能靠猜。
• 最小化是删字段，不是改文案。 23 个从未被读取的字段留在库里，就是 23 个泄露面。
• 同意只覆盖该用同意的目的。 服务与计费靠合同履行；把同意当万能依据，会让撤回变成产品故障。
• 删除是流程，不是按钮。 主库 30 天、副本 60 天，法定保留另算；承诺写不清，等于没做。
• 隐私的价值在可交代。 能在两小时内说清一次数据流向、一次删除、一次泄露，比多写十页政策更有用。

10 篇速览

三条阅读路径

路径 A：产品刚上线，还没人问过数据。 先读 01 把 12 张表与 78 个字段列出来，再读 02 删掉 23 个零读取字段，最后用 10 的十二项检查做一次基线评分。这条路径的重点是「先知道有什么，再决定留什么」。

路径 B：收到第一封数据请求或客户 DPA。 先读 05 把 30 天流程与导出脚本跑通，再读 06 把删除级联与副本期限写清，用 04 核对政策与实际域名是否一致。这条路径的重点是「能在一周内交出一个可复查的答复」。

路径 C：要出海或接企业客户。 先读 08 把 7 个处理者、区域与传输评估列成表，再读 09 做一次泄露演练，最后用 10 的评分表排出季度预算。这条路径的重点是「把跨境与泄露从口头承诺变成可演练的流程」。

与其它专题的边界

站内已有合规、平台、资产、度量、运维与多租户内容，但都不处理「个人数据从收集到删除的整条生命周期」。下表说明本组不重复什么。

这十篇不承诺「照做就不会违规」，也不提供可直接使用的法律文本。可复算的部分全部用四则运算给出算式；不可复算的部分（法域、监管判断、供应商能力）明确指向官方文档。所有数字都是教学假设，代入前请换成自己的表、字段与请求量。

本组统一口径

全组共用一组教学假设，各篇引用时不换分母：

产品：一人 SaaS，与既有组同一产品；账号 344（付费 120 + 试用 18 + 暂停 2 + 免费/沉默 204）
数据库：34 张表；含个人信息的表 12 张、字段 78 个；平均 6.5 个/表
字段分类：身份 18 + 内容 24 + 行为 22 + 财务 14 = 78
零读取字段：23 个（6 个月日志证明）→ 78 − 23 = 55，删除比例 29.5%
处理目的：4 类（服务、计费、分析、营销）；字段×目的矩阵 78×4 = 312 格，允许 96 格 = 30.8%
同意：3 类（条款、营销、分析）；营销订阅 268 人 = 77.9%，未订阅 76 人 = 22.1%；年撤回 24 人 = 7.0%
数据流向：12 个域名 = 5 个自有 + 7 个外部服务（支付、邮件、对象存储、模型、分析、搜索、鉴权）
政策披露：9/12 → 3 个漏项（分析、模型、错误监控）= 25%；修复后 12/12
数据主体请求：12 件/年 = 访问 5 + 导出 4 + 删除 3；手工 2.5 h/件、脚本 0.5 h/件
导出包：主数据 97 行（58 KB）+ 文件 18 个（4.32 MB）+ 90 天事件 113 条（68 KB）≈ 4.45 MB
删除：9 张表级联 97 行；18 个文件；452 事件/账号/年；年删除 36 个账号 = 10.5%
删除副本：软删 30 天 + 备份 30 天 = 60 天；发票 7 年法定保留、只匿名化
保留期：账号主数据 30 天、应用日志 90 天、分析明细 90 天、备份 30 天、审计 90 天–36 个月、发票 7 年
清理任务：4 个 × 每日 = 120 次/月；失败 0.8% = 0.96 次/月
备份：0.9 GB/天 × 30 天 = 27 GB；一次漏跑 12 天 = 10.8 GB
跨境：主库 us-east-1、备份 eu-central-1；EU 用户 42 = 12.2%；7 个处理者（5 美国、2 欧盟）
传输评估：7 × 45 分钟 = 5.25 h；年度复核 7 × 30 分钟 = 3.5 h；子处理者变更 3 次/年
泄露：3 级；检测目标 24 h、监管通知 72 h（余量 48 h）、用户通知内部目标 7 天
演练：2 h + 3 个缺口 × 2 h = 8 h/年；4 份模板
验收：12 项四维；权重 0.30/0.25/0.25/0.20；现状 3.80、修后 4.18
季度预算：13 周 × 3 h = 39 h；五项 24 h = 61.5%

344 是账号总数，120 是付费数。 数据请求率、删除率、同意比例都按 344 算；收入与付费相关数字才用 120。

12 张个人信息表与 9 张级联删除表不是同一件事。 12 张里 9 张按 user_id 直接删，2 张按保留期清理，1 张（payments/发票）依法保留 7 年、只做匿名化。

保留期沿用既有组口径。 分析明细 90 天来自产品度量组，备份 30 天来自资产韧性组，审计按事件类型（登录失败 90 天、删除 36 个月、账单 7 年）来自多租户组；本组不另立一套。

所有法律时限都是教学引用。 GDPR 访问请求 1 个月、泄露通知 72 小时、CCPA 45 天、PIPL 及时处理，具体适用与判断以专业意见为准。

使用说明

先列字段，再写政策。 字段表列不出来时，政策只能抄模板；抄来的模板与实际数据流一定对不上。

把删除当成一条跨系统的流程。 主库、对象存储、5 个外部接口、90 天分析与 30 天备份，每一段都要有人负责、有验证方法。

每季度跑一次两小时的演练。 一次导出、一次删除、一次泄露桌面推演；发现问题就回到检查表，而不是写进备忘录。

不要为了「以后可能有用」保留字段。 保留一个字段的成本不是磁盘，是它出现在泄露、导出与问卷里的每一次。

本组的证据与使用方法

证据类型。 本组用的是「字段登记表 + 12 个域名的抓包清单 + 12 件数据请求记录 + 36 次删除日志 + 4 个清理任务的执行记录 + 一次两小时演练的时间线」。没有「最佳实践」式的断言。

如何使用。 先用 01 的六属性表对照自己的 12 张表，再用 02 的读取日志删掉零使用字段，用 05 的脚本跑一次导出，用 06 的清单验证一次删除，最后用 10 的十二项检查做季度体检。

如何复核。 取最近一个月：抓一次包，看域名是否都在政策里；抽一个已删除账号，看 9 张表、18 个文件与 5 个外部接口是否真的没有残留；看一次清理任务的日志是否连续。三项都能对上，这套基线才适用。

系列导航

• 回到上级专题：独立开发者（Indie Developer）专题
• 上一组：一个人的计费系统：订阅状态机、按比例计费与失败重试
• 本组下一篇：数据地图：十二张表、七十八个字段与一次「我们到底收了什么」