数据映射基础：什么是数据映射、数据流图、数据清单

好，咱们今天聊点实在的。数据映射，说白了就是搞清楚你的系统里，哪些数据在跑、从哪来、到哪去、谁在碰它。我刚开始做GDPR合规那会儿，觉得这事儿特简单——不就是画几张图嘛。结果第一次被审计官问到“你们系统里那个用户手机号，到底经过了几次中转？”我当场就卡壳了。

嗯，从那以后，我再也不敢小看数据映射了。

数据映射到底是什么？

数据映射不是画图，也不是填表。它是一套方法论，用来回答三个核心问题：

• 数据长什么样？——字段、类型、格式
• 数据怎么流动？——从采集到删除的完整路径
• 谁对数据负责？——控制者、处理者、子处理者

我个人习惯把数据映射比作“数据的地铁线路图”。你不需要记住每一站，但必须知道起点、终点、换乘站和紧急出口。GDPR第30条要求的数据处理记录（ROPA），本质上就是数据映射的书面化成果。

数据流图：把看不见的路径画出来

数据流图，是数据映射最直观的呈现方式。你想想看，一个用户注册流程，背后可能涉及前端、后端、数据库、第三方SDK、日志系统……光靠文字描述，谁也理不清。

我建议用分层的方式画数据流图：

1. 上下文层：只画外部实体和系统边界。比如“用户→注册系统→数据库”。
2. 功能层：细化到每个功能模块。比如“注册表单→验证模块→存储模块→通知模块”。
3. 数据元素层：标注具体字段。比如“手机号、邮箱、密码哈希值”。

下面是我自己常用的一张数据流图结构，你可以参考：

数据清单：把每一笔数据都登记在册

数据流图是“骨架”，数据清单就是“血肉”。没有清单，光有图，审计官问你“这个字段存了多久？”你答不上来。

一份合格的数据清单，至少包含以下字段：

字段	说明	示例
数据项名称	业务含义明确的名称	用户手机号
数据类型	字符串、数字、布尔等	varchar(20)
数据来源	采集方式或上游系统	用户注册表单
存储位置	数据库、文件、缓存等	MySQL: user.phone
保留期限	明确的时间或条件	账号注销后30天
访问权限	谁可以读/写	客服部（只读）
安全措施	加密、脱敏、掩码等	AES-256加密

我建议用Excel或Airtable来维护数据清单。别用Word，别用PDF——你想想看，每次系统变更都要重新排版，谁受得了？

数据映射的三步法

说了这么多，到底怎么落地？我总结了一个三步法：

1. 盘点：把所有涉及个人数据的系统、模块、接口列出来。别漏了第三方SDK、日志系统、备份系统——这些最容易成为盲区。
2. 连线：画出数据流图，标注每个节点的输入输出。注意，数据流是双向的——读和写都要画出来。
3. 登记：填写数据清单，每个字段都要有明确的归属和约束。这一步最枯燥，但也最重要。

嗯，这里要注意：三步不是线性的。你画图时发现漏了一个字段，就得回去更新清单；你登记时发现某个数据流不合理，就得回去改图。迭代几次，才能形成完整的映射。

---