数据地图：十二张表、七十八个字段与一次「我们到底收了什么」

客户问的是清单，你交出的应该是一张能指到证据的地图。

一、十四页问卷与一次答不上来的盘点

2026 年 9 月，一家医疗器械公司在签约前发来 14 页安全问卷。前 12 页问加密、备份、权限，他答得很快；第 13 页只有三行：请列出收集的个人数据、存放在哪里、共享给哪些第三方。他打开数据库客户端，34 张表都认识，却挑不出哪 12 张算个人信息表。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

他先按字段名搜，email 和 phone 各自命中一串，两个列表的交集却少得可怜。原因是同一个邮箱在 users、profiles、invitations、messages 里各存一份，列名还分别叫 email、contact_email、invitee_email。

第二个问题更尴尬。他照隐私政策抄了 9 个域名，客户的技术人员回了一句：抓包看到 12 个。多出来的 3 个都是最近半年接入的服务，接入时没人想起政策。

那天下午他做了两件事：把 12 张表列成登记表，把 12 个域名画成一条从收集点到外部服务的线。前者回答「收了什么」，后者回答「去了哪」，合起来才是客户要的那张地图。

数据地图不是一份文档，而是一组能指到具体表和具体域名的证据。

二、十二张表与七十八个字段

判断一张表是否属于个人信息表，他只用一个标准：表里是否存在能单独或组合识别到自然人的列，或者存在指向 users 的外键。34 张表里符合的有 12 张，占 12 ÷ 34 = 35.3%。

78 个字段按主语义分成四类：身份 18、内容 24、行为 22、财务 14。分类规则是「一个字段只进一类」：user_id 算身份，created_at 算行为，amount 算财务；边界模糊的字段（比如带邮箱的邀请记录）按它最常被读取的用途归。

12 张表平均 6.5 个字段，最多的 users 和 events 各 8 个，最少的 organizations、invitations、comments 各 5 个。这个均值不是巧合，而是建表习惯：一张业务表通常只放「这条记录是什么、属于谁、什么时候发生」。

登记表的价值在第三列和第四列。只有表名和字段数的清单，客户看一眼就会追问「用途是什么」；把用途写成「登录」「开票」这种具体动作，才逼得你承认某个字段其实没有用途。

被排除的 22 张表（34 − 12 = 22）要能说清理由。缓存表、队列表和统计汇总表不在名单里，不是因为它们干净，而是因为里面的数据都能追溯到 12 张中的某一张；这个「可追溯」的判断也要写下来，否则下次有人加一张宽表，边界就又模糊了。

四个类别里，身份 18 包含邮箱、姓名、头像与登录标识，内容 24 包含项目名、评论、文件名与消息正文，行为 22 包含事件、会话、审计动作与时间戳，财务 14 包含金额、币种、发票号与账单地址。分类不是学术练习，而是为了回答「哪一类数据被哪个目的使用」。

三、从收集点到十二个域名

把数据流画成三张表之后，问卷里的三个问题就有了对应位置：收集点回答「什么时候收」，业务表回答「存在哪」，域名回答「给谁」。

收集点只有四类，但每一类都可能同时写多张表。注册一次会写 users、profiles、memberships 三张；上传一个文件会写 files 与 projects，还会在 events 里留一条记录。这就是「字段数」和「收集点」对不上的原因。

5 个自有域名加 7 个外部域名等于 12 个。自有域名里，app 和 api 处理会话与业务请求，cdn 与 docs 只有静态内容，status 只发布可用性状态；外部 7 个才是数据真正离开边界的地方。

自有与外部按「数据是否离开你的运维边界」划分，不按公司注册地划分。cdn 即使由第三方托管，也只承载静态资源，按自有域名记；对象存储存的是用户文件，按外部服务记，因为它能被业务代码之外的系统读取。

逐个域名标注「经过什么数据」比标注「是否可信」有用。支付经过金额与账单地址，邮件经过邮箱与正文，对象存储经过文件本身，模型经过用户输入的提示词，分析经过事件与设备标识，搜索经过查询词，鉴权经过邮箱与登录记录。

域名清单要从抓包生成，不要从 SDK 清单生成。SDK 清单只记录主动集成的库，容易漏掉浏览器扩展、错误上报和模型网关；抓包看到的是实际发出的请求，两者对不上时以抓包为准。

这 12 个域名里，政策写到的只有 9 个。剩下 3 个不是故意隐瞒，而是「先接服务、后补文档」的典型顺序：工程侧一天能接完，政策侧要改文案、改同意、重新发版，于是被无限推后。

四、字段登记的六个属性

只有表名、字段名和用途还不够。客户真正会追问的是「凭什么收、留多久、给谁、怎么删」，所以每个字段要补六个属性：来源、目的、依据、保留期、共享方、删除方式。

来源写清楚是用户直接填写、系统自动产生，还是从第三方获得；目的写它服务于四类目的中的哪一类；依据写合同、同意还是法定义务；保留期写具体天数或「随账号删除」；共享方写域名或「无」；删除方式写级联删除、匿名化还是随保留期清理。

六个属性里最难写的是目的和依据。保留期可以抄保留策略，共享方可以抄域名表，删除方式可以抄级联规则，但目的必须落到「哪个功能在读」，依据必须落到「合同、同意还是法定义务」；这两列写不出来，说明这个字段本来就不该存在。

写不完的字段先标红，不要留空。标红的意思是「这里有一个我们答不上来的问题」，比编一个看起来合理的答案诚实得多。第一轮就有不少字段被标红，其中几个连来源都说不清。

标红的字段里，有 23 个在最近 6 个月的日志里从未被任何功能读取。它们不是错误数据，而是「收了但没用」的数据，是下一篇要处理的对象；在地图阶段只需要标记，不需要立刻删。

复算：把这张地图上的比例一次算清。

表数占比      12 ÷ 34 = 35.3%
字段均值      12 × 6.5 = 78
类别合计      18 + 24 + 22 + 14 = 78
零读取占比    23 ÷ 78 = 29.5%
域名合计      5 + 7 = 12
政策覆盖      9 ÷ 12 = 75.0%，漏 3 个 = 25.0%

六个属性乘以 78 个字段，是 468 个格子，不是 78 个。这 468 个格子里真正需要人工判断的只有 156 个（78 × 2），其余 312 个可以从 schema、保留策略和域名表批量填。这张表不适合手工维护，应该从数据库 schema 生成初稿，再让人补「目的」和「依据」这两列——只有这两列机器猜不出来。

五、行动清单与复算验收

• 按「可识别自然人或有 user_id 外键」圈出 12 张表，写进一张登记表。
• 给 78 个字段逐个补六个属性，答不上来的标红而不是留空。
• 用抓包列出 12 个域名，标出自有 5 个与外部 7 个。
• 用 6 个月日志标出 23 个零读取字段，只标记不删除。
• 画一条从 4 类收集点到 12 个域名的连线，每条线写明经过的数据。
• 给每张表指定一个 owner，写人名或角色，不写「团队」。
• 把登记表存进版本库，字段变更与迁移文件同一次提交。
• 每季度复核一次，重点看新增的表、字段和域名。

验收标准：客户任指问卷里的一个问题，都能在 10 分钟内翻到对应的表、字段、域名和负责人。

八条里前四条是「这次问卷要交的」，后四条是「让下一次问卷不用重做」。如果只有一天，先做前四条，把标红字段和零读取字段留到下一周；顺序反了，地图会变成一份没人维护的漂亮文档。

地图做完那天，他把登记表和流向图一起发给客户。对方只回了两个字：可以。这两个字的价值不在通过审核，而在于以后再有人问「你们收了什么」，他不用再打开数据库现数一遍。

使用边界与实操验收

数据地图不等于隐私政策。 地图是内部证据，政策是对外叙述；地图可以标红、可以写「不确定」，政策不能。两者要能互相指认，但不能互相替代。

它不覆盖加密与访问控制。 地图只回答「有什么、在哪、给谁」，不回答「谁能看、传得安不安全」；后者要靠权限矩阵与传输评估单独做。

它不能替代 DPIA。 高风险处理需要评估影响与缓解措施，数据地图只是 DPIA 的输入之一，不是结论。

表结构会变。 一次迁移就可能让地图过期，所以地图必须和迁移文件同源更新；季度复核只是兜底，不是唯一更新时机。

问卷答案要能指向证据。 每一个「有」「没有」后面都要能贴出表名、域名或截图；答不出证据的答案，等于没答。

关键参考与核验范围

• GDPR Art 30 ：用于核对处理活动记录的字段与留存要求。
• GDPR Art 5 ：用于核对目的限定、最小化与存储限制的原则表述。
• NIST Privacy Framework ：用于核对「数据清单—数据流—风险」的组织方式。
• OWASP Top 10 Privacy Risks ：用于核对过度收集与披露不足的风险分类。
• ICO DPIA ：用于核对数据地图在影响评估中的位置。

以上链接于 2026-10-26 实测可公开访问；未核验版本、价格与配额。核验日期：2026-10-26。

上述文档只用于核对概念与条款编号；12 张表、78 个字段、12 个域名与全部比例均取自本组教学基线，与文档内容无对应关系。法律表述以适用法域与专业意见为准。

系列导航

• 回到本组目录：一个人的隐私工程：数据地图、最小化与删除权
• 下一篇：数据最小化：二十三个没人读的字段与一次删列迁移
• 相关：组织、工作区、成员：三层模型与一次数据迁移 、事件字典：二十四个事件、六个属性与一张变更表