第三章：数据映射与清单——绘制数据流图、识别数据类别、识别数据主体、识别数据接收方、建立数据清单
好，咱们进入DPIA最核心的实操环节——数据映射与清单。
说实话，很多企业做DPIA，上来就填表、打分、写报告。结果呢？数据从哪来、到哪去、谁经手，全是一笔糊涂账。我见过太多这样的案例：风险评估做了厚厚一沓，一问业务部门“这个字段到底存了啥”，没人说得清。
所以我的习惯是——先画图，再列清单。把数据流理清楚，后面所有分析才有根基。
3.1 为什么要做数据映射？
数据映射，说白了就是给你的数据“拍X光片”。你要知道：
- 哪些数据进了你的系统
- 它们去了哪里
- 谁在处理它们
- 最终流向何方
我在一个跨国电商项目中遇到过这种情况：他们以为用户数据只存在国内服务器，结果一查，订单数据通过第三方支付接口，自动同步到了境外的数据分析平台。嗯，这个“跨境传输”的风险，如果不做数据映射，根本发现不了。
核心原则：没有数据映射，DPIA就是空中楼阁。你连数据在哪都不知道，怎么评估风险？
3.2 绘制数据流图——从业务到技术的桥梁
数据流图不是给技术看的，是给业务、法务、管理层一起看的。我建议用“泳道图”的形式，把每个环节画清楚。
3.2.1 数据流图的基本要素
| 符号 | 含义 | 示例 |
|---|---|---|
| 椭圆/圆角矩形 | 数据主体（用户） | 注册用户、求职者 |
| 矩形 | 处理活动/系统 | CRM系统、HR系统 |
| 箭头 | 数据流向 | 用户→注册页面→数据库 |
| 平行四边形 | 数据存储 | MySQL、云存储桶 |
| 圆柱体 | 第三方接收方 | 支付网关、数据分析平台 |
举个例子，一个简单的用户注册流程：
用户（数据主体）
↓ 提交姓名、手机号、邮箱
注册页面（前端）
↓ HTTPS传输
API网关
↓ 转发
用户服务（后端）
↓ 写入
用户数据库（MySQL）
↓ 同步（定时任务）
数据分析平台（第三方：Google Analytics）
你看，这样一画，数据从用户到第三方平台的路径就一目了然了。我曾经帮一家金融科技公司做数据映射，他们一直以为数据只在内网流转，结果画完图发现，风控模块调用了三个外部API，每个都会传输用户的身份证号。这就是典型的“数据流黑洞”。
我的小技巧：画图时用不同颜色标注“敏感数据流”。比如红色代表身份证、银行卡号，黄色代表手机号、邮箱，绿色代表匿名化数据。这样一眼就能看出风险集中点。
3.3 识别数据类别——别漏了“隐藏数据”
数据类别不是简单列个“姓名、电话、地址”。你要做的是颗粒度拆分。我一般分成三层：
- 直接标识符：姓名、身份证号、护照号、手机号
- 间接标识符：生日、邮编、性别、IP地址
- 特殊类别数据：生物识别、健康数据、政治观点、性取向
这里有个坑——很多人只关注“显性数据”，忽略了“隐性数据”。比如：
- 用户上传的图片里，EXIF信息可能包含GPS位置
- 聊天记录里的表情包，可能包含设备型号
- 日志文件里的User-Agent，可能暴露浏览器指纹
我在一个社交App项目中，就发现他们的日志系统记录了用户的精确经纬度。业务部门说“我们只记录登录时间啊”，结果一查，日志框架默认把请求头的所有参数都打进去了。嗯，这种“默认行为”最危险。
注意：GDPR和《个保法》对“特殊类别数据”有更严格的保护要求。如果你处理了健康数据、生物识别数据，DPIA必须单独评估，且需要更高级别的安全措施。
3.4 识别数据主体——谁的数据？
数据主体不只是“用户”。你要区分：
| 数据主体类型 | 典型场景 | 注意事项 |
|---|---|---|
| 终端用户 | App注册用户、网站访客 | 注意儿童数据（<16岁） |
| 员工 | HR系统、考勤系统 | 员工同意 vs 管理需要 |
| 合作伙伴 | 供应商、经销商 | 合同约束数据使用范围 |
| 被引用的第三方 | 用户通讯录中的联系人 | 间接收集，需额外告知 |
我建议在数据流图上，每个数据主体都用不同颜色的图标标注。比如用户用蓝色，员工用橙色。这样在做风险评估时，可以快速定位“哪个群体的数据风险最高”。
3.5 识别数据接收方——谁在碰数据？
数据接收方不只是“外部公司”。内部部门之间也算。我把它分成三类：
- 内部接收方：市场部、客服部、技术运维团队
- 外部接收方：云服务商、支付平台、数据分析公司
- 跨境接收方：境外母公司、海外数据中心
这里有个关键点——子处理器。比如你用了AWS的云服务，AWS又用了某个CDN服务商。这个CDN服务商就是“子处理器”。很多企业只列了直接合作的第三方，忽略了子处理器。我在一个医疗项目中，发现他们的病历数据通过云存储服务，自动备份到了另一个国家的灾备中心。而合同里根本没写这个灾备中心的存在。
实操建议：要求每个第三方供应商提供“子处理器清单”，并写入合同。如果对方拒绝，那这个供应商的风险等级就要调高。
3.6 建立数据清单——把一切写下来
数据流图画完了，类别、主体、接收方都识别了。最后一步——整理成结构化的数据清单。我常用的模板是这样的：
| 数据字段 | 数据类别 | 数据主体 | 收集方式 | 存储位置 | 接收方 | 保留期限 | 安全措施 |
|---|---|---|---|---|---|---|---|
| 手机号 | 直接标识符 | 注册用户 | 用户输入 | 阿里云RDS | 客服部、短信服务商 | 用户注销后30天 | AES-256加密 |
| 浏览记录 | 行为数据 | 网站访客 | Cookie | 日志服务器 | 数据分析团队 | 6个月 | 脱敏后存储 |
| 身份证号 | 特殊类别 | 实名用户 | 用户上传 | 加密数据库 | 风控部门、公安接口 | 法律要求5年 | HSM硬件加密 |
这个清单不是一次性做完就完事了。我建议每季度更新一次。因为业务在变，数据流也在变。比如你们新接了一个广告SDK，那数据接收方就多了个广告平台，数据类别可能多了个“设备ID”。
我的习惯：用Excel或者Notion建一个“数据资产目录”，每个字段都关联到对应的数据流图。这样审计时，别人问“这个字段从哪来的”，我直接点开链接就能看到完整的流转路径。
3.7 避坑指南——我踩过的那些坑
- 坑1：只画“理想状态”的数据流。 我曾经只画了正常流程，结果忘了画“异常流程”——比如用户注销后，数据还在备份库里躺了半年。后来被监管问到了，才紧急补上。
- 坑2：忽略“人工处理”。 很多数据不是系统自动处理的。比如客服手动导出用户数据发邮件。这种“人工环节”风险极高，一定要画进去。
- 坑3：数据清单和实际不一致。 有一次我审计一家公司，他们的数据清单写着“手机号加密存储”，结果我去数据库一查，明文存储。嗯，这种“纸面合规”最要命。
好了，数据映射与清单这部分，核心就是“画清楚、列明白”。你想想看，如果连自己的数据家底都摸不清，后面的风险评估、风险处置，那不就成了瞎指挥吗？
下一章，咱们聊聊怎么基于这份清单，做真正的风险评估。到时候我会分享一个我常用的“风险评分矩阵”，保证实用。