第4章：数据映射与数据流分析

好，咱们进入第4章。这一章我特别喜欢，因为它特别「实在」。你想想看，你连数据长什么样、从哪来、到哪去都不知道，那合规审计就是纸上谈兵。说白了，数据映射就是给企业数据画一张「全家福」。

4.1 为什么要做数据映射？

我刚开始做隐私合规那会儿，有个客户被罚了200万欧元。原因很简单——他们根本说不清楚用户数据存在哪台服务器上。监管来了，问「你们把欧洲用户的数据传到美国了吗？」负责人支支吾吾答不上来。嗯，这就是典型的「数据黑箱」问题。

数据映射的价值在于：

• 摸清家底：你到底收集了哪些数据？存在哪？谁在用？
• 识别风险：跨境传输合不合规？第三方共享有没有授权？
• 应对监管：GDPR第30条明确要求企业维护数据处理活动记录（ROPA）

4.2 数据资产清单：从「不知道」到「门儿清」

我个人习惯，第一步永远是做数据资产盘点。别一上来就画图，先搞清楚你手里有什么牌。

数据资产清单至少包含以下字段：

字段	说明	示例
数据类别	个人数据、敏感数据、业务数据	个人身份信息（PII）
数据字段	具体包含哪些信息	姓名、手机号、身份证号
数据来源	通过什么渠道收集	用户注册表单、API接口
存储位置	数据库、文件服务器、云存储	阿里云RDS（上海节点）
保留期限	数据存多久	用户注销后30天删除
访问权限	谁可以看、谁可以改	客服部可读，技术部可读写

4.3 绘制数据流转图：五个关键节点

数据流转图，说白了就是回答五个问题：数据从哪来？存在哪？谁在用？给谁了？什么时候删？

我习惯用这五个节点来画：

1. 收集（Collection）：用户注册、下单、填写问卷、埋点采集……每个入口都要标注清楚。
2. 存储（Storage）：存在哪个数据库？有没有备份？备份存多久？
3. 使用（Use）：哪些部门在用？用于什么目的？比如市场部做精准营销，风控部做反欺诈。
4. 共享（Share）：有没有给第三方？比如支付网关、物流公司、数据分析服务商。
5. 删除（Deletion）：什么时候删？怎么删？是逻辑删除还是物理销毁？

举个例子，一个电商App的用户数据流转可能是这样的：

收集：用户注册 → 填写姓名、手机号、地址
  ↓
存储：MySQL主库（上海） + Redis缓存（上海）
  ↓
使用：订单系统（调用地址）、推荐系统（分析购买记录）
  ↓
共享：物流公司（地址）、支付网关（姓名+银行卡号）
  ↓
删除：用户注销后30天，定时任务清理数据库记录

4.4 标注数据跨境传输路径

这一块是合规审计的重灾区。尤其是GDPR和《个人信息保护法》都要求，数据出境必须有合法依据。

跨境传输路径标注，我建议你关注三点：

• 起点和终点：数据从哪个国家/地区传到哪个国家/地区？
• 传输方式：API调用、数据库同步、文件传输？有没有加密？
• 法律依据：标准合同条款（SCCs）、充分性认定、企业约束规则（BCR）？

举个例子：

跨境传输路径：
起点：中国（上海数据中心）
终点：新加坡（AWS亚太节点）
传输方式：TLS加密的API同步
法律依据：签署了标准合同条款（SCCs）
涉及数据：用户订单信息（不含身份证号）

4.5 数据映射的常见误区

做了这么多年，我总结出几个容易踩的坑：

• 只画「理想状态」：很多团队只画了生产环境的数据流，忽略了测试环境、开发环境、灾备环境。这些环境里往往也有真实数据。
• 忽略非结构化数据：日志文件、邮件附件、聊天记录……这些非结构化数据里可能包含大量个人信息。我见过一个案例，客服的聊天记录里存了用户的身份证照片，但数据资产清单里根本没列出来。
• 不更新：数据映射不是一次性工作。业务变了、系统升级了、换了云服务商，数据流就会变。我建议每季度至少review一次。