验收不是证明自己合规，而是找出下一季度最该补的那三个洞。
一、季度最后一周的重跑
季度最后一周，他把过去三个月写下的隐私事项重新过了一遍。第一遍很顺：数据地图有 12 张表、78 个字段，导出脚本跑得通，请求记录也齐全。第二遍开始不对：删除承诺写「30 天」，但备份保留也是 30 天，软删 30 天加备份 30 天等于 60 天；跨境那份传输评估的复核日期停在 14 个月前；泄露演练的记录只有一页，里面没有时间线。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
这三个问题都不属于「没做」，而属于「做过但没对齐」。一个人的团队最容易在这里失分：每件事都有人做过，但没人负责把它们放在同一张表上互相校验。验收表的作用，就是把「做过」变成「现在仍然成立」。
他给这三件事排了个序：先改对外承诺，再补 TIA 复核，最后补演练记录。顺序的依据不是难度，而是「用户会不会先看到」：删除承诺写在政策里，TIA 只在 DPA 附件里，演练记录只有自己看。
排完序他发现，真正花时间的不是改一句话，而是确认改完之后所有旧版本都失效：政策页、帮助中心、销售邮件模板，以及已经发出去的 DPA 附件。
二、十二项检查：四个维度各三项
12 项不是 12 个功能，而是 12 个可判定的问题。每一项只填「过」或「不过」，不填分数，也不写「基本完成」。分数留给下一节的四维评分，检查表只负责事实。
检查表的填写规则：
- 每项只有一个判定人，避免「大家都觉得过了」
- 每项只有一个证据位置，链接或路径写清楚
- 「不过」必须写下一步动作与日期
- 「不适用」要写理由，不能空着
- 同一项连续两个季度不过，升级为季度目标
这张表最容易退化成打勾游戏。防退化的办法是限制填法：不允许写「部分完成」「基本符合」，只允许「过」「不过」「不适用」三种。
另一个办法是让证据先于结论。先贴链接，再写「过」；如果找不到链接，就默认「不过」。这听起来苛刻，但比事后补材料便宜。
| 维度 | 检查项 | 判定标准 |
|---|---|---|
| 可解释 | 数据地图 | 12 张表、78 个字段都有来源、目的与保留期 |
| 可解释 | 最小化 | 23 个零读取字段已处置或写明保留理由 |
| 可解释 | 政策一致 | 12 个域名与政策披露逐条对得上 |
| 可响应 | 请求入口 | 访问、导出、删除三类都有固定入口 |
| 可响应 | 导出包 | 97 行主数据、18 个文件、113 条事件可一次生成 |
| 可响应 | 时限 | 30 天内部 SLA 有计时与拒绝理由模板 |
| 可删除 | 表分类 | 9 张级联、2 张按保留期、1 张法定保留已标注 |
| 可删除 | 副本承诺 | 对外只承诺主库 30 天、全部副本 60 天 |
| 可删除 | 清理任务 | 4 个每日任务有失败告警与补跑记录 |
| 可交代 | DPA | 7 个处理者各有一份可找到的协议 |
| 可交代 | 传输评估 | 7 份 TIA 都在 12 个月内复核过 |
| 可交代 | 泄露准备 | 4 份模板齐全，且当年做过一次演练 |
「不过」不必然是缺陷，也可能是证据没找到。两种情况要分开记：前者排期修，后者补证据。混在一起会让下一季度重复劳动。
12 项里有几项直接依赖前九篇的产出：数据地图、最小化、删除分类。如果那三篇的表格没有更新，这里的「过」就是假的；所以验收前要先确认上游文档的 lastmod。
三、四维评分：3.80 到 4.18
评分用四个维度加权：可解释 0.30、可响应 0.25、可删除 0.25、可交代 0.20。权重不是行业标准，而是按「用户最可能先问什么」排的；一个人做产品，解释成本最高，所以可解释占三成。
| 维度 | 权重 | 现状 | 修后 |
|---|---|---|---|
| 可解释 | 0.30 | 4.0 | 4.5 |
| 可响应 | 0.25 | 4.5 | 4.5 |
| 可删除 | 0.25 | 3.5 | 4.0 |
| 可交代 | 0.20 | 3.0 | 3.5 |
现状 3.80，修后 4.18。差距主要来自可删除与可交代：一个卡在 60 天副本承诺，一个卡在过期 TIA。可响应已经接近满分，继续投入的边际收益最低，季度预算就应该往另外两维倾斜。
四个维度各自对应一个具体问题：
- 可解释：新用户能否不用追问就看懂收集了什么
- 可响应：一封请求能否在 30 天内闭环
- 可删除：注销后能否说清哪些还在、为什么
- 可交代：客户问起处理者时能否当场给出清单
分数只用于排优先级，不用于对外宣传。4.18 不是「合规认证」，它只表示在这张 12 项表上，当前证据比上季度更完整。
权重调整要留痕。如果下季度把可交代从 0.20 提到 0.30，就要同时重算历史分，否则趋势线没有意义。
四、季度预算：39 小时里拿出 24 小时
一个季度按 13 周、每周 3 小时计，共 39 小时。五项排期合计 24 小时：补 9 个字段属性 6 小时、导出脚本 5 小时、删除演练 4 小时、TIA 复核 5 小时、泄露演练 4 小时。占 61.5%，剩下的 15 小时留给临时请求与回归。
| 项目 | 工时 | 产出 |
|---|---|---|
| 补 9 个字段属性 | 6 h | 字段登记表更新 |
| 导出脚本 | 5 h | 一次生成 4.45 MB 的包 |
| 删除演练 | 4 h | 删除记录与时间线 |
| TIA 复核 | 5 h | 7 份评估的新日期 |
| 泄露演练 | 4 h | 时间线与 3 个缺口 |
排期时先放固定项，再放弹性项。删除演练和泄露演练会牵动外部服务，必须提前预约；字段属性和导出脚本可以拆成碎片时间。
每项完成后立刻记实际工时。连续两个季度实际值明显超过预估，说明预估口径有问题，而不是执行力有问题。
复算：
现状：0.30×4.0 + 0.25×4.5 + 0.25×3.5 + 0.20×3.0
= 1.20 + 1.125 + 0.875 + 0.60 = 3.80
修后：0.30×4.5 + 0.25×4.5 + 0.25×4.0 + 0.20×3.5
= 1.35 + 1.125 + 1.00 + 0.70 = 4.175 ≈ 4.18
季度预算：13 × 3 = 39 小时
五项占比：6 + 5 + 4 + 5 + 4 = 24 小时；24 ÷ 39 = 61.5%
排期要写在日历上，而不是写在文档里。6 小时的字段补齐如果拆成 3 次 2 小时，就必须有三次明确的开始时间；否则它会被「这周太忙」无限推后，到下个季度仍然是 9 个字段待补。
五、行动清单与复算验收
- 把 12 项检查固化成一张只有「过 / 不过」的表
- 每项写明证据位置，而不是只写结论
- 用四维权重算一次现状分，保留算式
- 季度排一次删除与泄露联合演练，共 3 个场景
- 把 24 小时拆进 13 周日历，标出开始时间
- 过期 TIA 与 60 天副本承诺各自单独立项
- 每项验收留存截图、日志或链接作为证据
- 下季度第一周复查「不过」项是否真的关闭
清单不是越全越好。8 条已经覆盖「表、证据、评分、演练、排期、复盘」，再加就会稀释重点。
如果团队只有一个人，建议把「外部复核」写进日历而不是写进愿望；找不到同行，就找一位客户做一次简短问答。
验收标准：季度末能在一页纸上指出 12 项的过与不过、总分算式，以及 24 小时分别落在哪几天。
使用边界与实操验收
边界一：自评会偏乐观。 自己给自己打分时，「基本做到」很容易被记成「过」；至少让一位外部同行按同一张表复核一次。
边界二：12 项不覆盖所有法域。 这张表按 GDPR 与 CCPA 的常见要求设计，PIPL 与其他法域另有要求，具体以适用法域与专业意见为准。
边界三：演练不能替代真实事件。 演练能验证模板和分工，但真实事件的压力、信息缺口和外部询问无法完全模拟。
边界四：权重应按业务调整。 0.30/0.25/0.25/0.20 是这家一人 SaaS 的排序；面向企业客户的产品可能要提高可交代的权重。
边界五：通过不等于零风险。 12 项全过只说明当前检查表覆盖的范围成立，不说明没有未知的数据流或新的供应商变更。
这五条边界里，最容易被忽略的是「通过不等于零风险」。验收表只能证明表内项目成立，表外的数据流、供应商变更和法规更新仍需单独跟踪。
把「表外事项」单列一页，每季度加一条，比不断往 12 项里塞新项更可持续。
关键参考与核验范围
- NIST 隐私框架 ：用于核对验收维度与治理动作的对应关系。
- OWASP 隐私风险 Top 10 ：用于核对检查项是否覆盖常见隐私风险。
- GDPR Art 32 ：用于核对安全措施与验收证据的类型。
- GDPR Art 30 ：用于核对处理活动记录与数据地图的字段口径。
- ICO DPIA ：用于核对高风险场景是否应进入影响评估。
以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。