3、数据映射与清单：如何绘制数据流图、建立数据资产清单、识别数据生命周期
好，咱们进入第三章。这一章，说白了就是回答一个核心问题：你的数据到底在哪儿？怎么流动的？
很多公司做隐私合规，上来就写制度、定流程。但我个人习惯，第一步永远是——先把数据地图画出来。没有地图，你连自己在哪儿都不知道，谈何合规？
3.1 为什么要做数据映射？
数据映射，不是给监管看的漂亮图表。它是你内部排查风险的作战地图。
我在项目中遇到过一家电商公司，被用户投诉个人信息泄露。他们翻遍了所有系统，愣是找不到数据是从哪个环节流出去的。为什么？因为没有数据流图，数据链路是黑的。
数据映射能帮你回答三个问题：
- 数据从哪里来？（采集源头）
- 数据到哪里去？（存储、处理、传输、销毁）
- 谁碰过这些数据？（角色、系统、第三方）
核心原则：没有数据映射，隐私合规就是纸上谈兵。你连数据资产都盘点不清，风险排查就是瞎猫碰死耗子。
3.2 绘制数据流图：从业务场景出发
绘制数据流图，我建议你不要从技术架构图开始。那玩意儿太复杂，容易迷失。从业务场景入手，反而更清晰。
举个例子，用户注册这个场景：
- 用户在App输入手机号、验证码
- 前端把数据传给后端API
- 后端校验后写入用户数据库
- 同时，数据被同步到数据分析平台
- 还有一份，被推送给了推送服务商
你看，这就是一个最简单的数据流。画出来，你就知道数据经过了哪些节点。
数据流图的基本要素
| 符号 | 含义 | 示例 |
|---|---|---|
| 椭圆/圆角矩形 | 外部实体（用户、第三方） | 用户、支付网关 |
| 矩形 | 处理过程（系统、模块） | 用户注册服务、订单处理 |
| 开口矩形 | 数据存储（数据库、文件） | MySQL、Redis、日志文件 |
| 箭头 | 数据流向 | 用户→App→后端→数据库 |
我的小技巧：画图时，用不同颜色标注数据类型。比如个人敏感信息用红色，普通个人信息用蓝色。一眼就能看出高风险区域。
3.3 建立数据资产清单：把数据管起来
数据流图画完了，下一步就是建立数据资产清单。这就像你搬家前，先列个物品清单。不然搬完了，发现少了个箱子，你都不知道丢的是啥。
数据资产清单，至少要包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 数据项名称 | 数据的业务名称 | 用户手机号 |
| 数据类型 | 个人基本信息/敏感信息/设备信息 | 个人敏感信息 |
| 存储位置 | 数据库名、表名、文件路径 | user_db.t_user.phone |
| 采集方式 | 用户主动提供/系统自动采集/第三方获取 | 用户注册时填写 |
| 处理目的 | 为什么收集这个数据 | 用于用户身份验证 |
| 共享情况 | 是否给第三方、给了谁 | 推送服务商（极光推送） |
| 保留期限 | 数据存多久 | 用户注销后30天删除 |
我曾经帮一家金融科技公司做排查，发现他们的数据资产清单里，居然有20多个“未知来源”的数据项。一问才知道，是早期开发人员随手加的字段，后来没人记得了。这就是风险点——你不知道的数据，往往就是泄露的源头。
注意：数据资产清单不是一次性工作。每次业务上线新功能、接入新第三方，都要更新清单。我建议把它纳入发布流程，作为上线前的必检项。
3.4 识别数据生命周期：从生到死
数据生命周期，说白了就是数据从“出生”到“死亡”的全过程。每个阶段都有不同的合规要求。
我习惯把生命周期分成六个阶段：
- 采集：有没有告知用户？有没有获得同意？
- 存储：加密了吗？存多久？
- 使用：谁在用？用在哪？有没有超范围？
- 传输：内部传输加密了吗？给第三方走什么协议？
- 共享：和第三方签了数据保护协议吗？
- 销毁：数据到期后，真的删干净了吗？
嗯，这里要注意。很多公司只关注前三个阶段，觉得数据存好了就万事大吉。但我在项目中遇到过，数据销毁环节出了大问题。一家公司说他们删除了用户数据，结果在备份服务器里还躺着三年前的完整备份。这算不算违规？当然算。
如何识别生命周期中的风险？
我的做法是，针对每个阶段，问自己三个问题：
- 合规性：这个阶段的做法，符合法律法规要求吗？
- 安全性：有没有技术手段保护数据？比如加密、访问控制？
- 可审计性：操作有没有日志？出了问题能不能追溯？
举个例子：采集阶段，如果App在用户未同意的情况下，自动读取了通讯录。这就是合规性问题。存储阶段，如果数据库密码是明文写在配置文件里的。这就是安全性问题。使用阶段，如果谁查了用户数据都没有日志。这就是可审计性问题。
3.5 实战：一个完整的排查案例
最后，我分享一个真实的排查案例，帮你把前面三个步骤串起来。
有一家在线教育公司，被用户投诉“过度收集信息”。我接手后，第一步就是画数据流图。从用户注册、选课、上课、到课后反馈，把每个场景的数据流都画出来。
结果发现，他们的App在用户打开时，会同时向三个第三方SDK发送设备信息。而其中两个SDK，业务方根本不知道是用来干嘛的。这就是典型的“数据流黑洞”。
接着，我建立数据资产清单。把每个数据项都登记在册，标注来源、用途、存储位置。发现有一个叫“user_behavior_log”的表，记录了用户所有的点击行为，包括在App内停留了多久、看了哪些页面。但公司内部没有任何文档说明这个表是用来做什么的。
最后，我识别数据生命周期。发现用户注销账号后，他们的学习记录、支付信息虽然被删了，但行为日志还保留着。而且保留期限写的是“永久”。这明显违反了“最小必要”原则。
排查结果出来后，我们做了三件事：
- 关停了两个不必要的第三方SDK
- 清理了无主的数据表，并建立数据治理规范
- 修改了数据保留策略，行为日志保留90天后自动清理
你看，数据映射、资产清单、生命周期识别，这三步走下来，风险点就无处遁形了。
最后说一句：数据映射不是一次性的项目，而是一个持续的过程。我建议每季度做一次全面排查，每次业务变更后做一次增量排查。养成习惯，你会发现隐私合规其实没那么难。