GDPR 数据映射图：如何梳理个人数据在各系统间的流动

问隐私团队个人数据在哪里，你会拿到一张电子表格。问工程团队，你会拿到一张从不提及个人数据的架构图。两者都不完整：表格无法展示数据如何流动，架构图则说不清流动的是什么、为什么流动。

GDPR 数据映射图就是两者交汇的地方。本文介绍数据映射必须记录哪些内容、一套构建方法，以及一个典型 SaaS 产品的完整示例。本文不构成法律意见；合法性基础、传输机制和保留期限由你们的隐私负责人或法律顾问决定。

数据映射与处理活动记录

GDPR 第 30 条要求每个控制者保存一份处理活动记录，其中包含：

• 控制者的名称和联系方式，以及在适用时其代表和数据保护官的名称和联系方式；
• 处理的目的；
• 数据主体的类别和个人数据的类别；
• 接收者的类别，包括第三国的接收者；
• 向第三国的传输，以及部分传输的保障措施文件；
• 在可能的情况下，删除的时限；
• 在可能的情况下，安全措施的一般性描述。

处理者也要为其代表每个控制者进行的处理保存类似的记录。第 30 条第 5 款豁免员工少于 250 人的组织，但前提是处理不太可能对个人权利造成风险、只是偶尔进行，并且不涉及特殊类别的数据或刑事定罪数据。每天处理客户数据的 SaaS 公司很少符合这些条件。欧盟立法者曾讨论提高这一门槛，因此在依赖它之前，请先核对现行条文。

记录是一张表。数据映射则是弄清这张表里该写什么、并在之后核对它是否仍然准确的方法。

每条数据流要记录什么

一套行之有效的方法

1. 盘点系统。 从你能列出来的东西开始：云账户、数据库，以及从单点登录和财务团队的供应商付款记录中找到的 SaaS 工具。影子 IT 工具就是在这里冒出来的。
2. 一次跟踪一条用户旅程。 注册、计费、日常使用产品、一张支持工单、一封营销邮件。画出数据从哪里进入、存在哪里、接下来去往哪里。
3. 询问系统负责人。 针对每个系统：哪些字段、用于什么、谁会接收、保留多久。
4. 标出处理者和传输。 记下每个供应商在哪里处理数据、是否已签署数据处理协议（DPA），以及哪种保障措施覆盖了每一次向 EEA 以外的传输。
5. 补上保留和删除。 没有保留期限的存储本身就是一个发现项。
6. 与隐私团队一起评审，并从数据映射推导出第 30 条要求的记录。

向 EEA 以外的传输

GDPR 第五章（第 44 条至第 49 条）只允许基于特定理由向第三国传输数据。对 SaaS 公司来说，常见的有：

• 充分性认定。 欧盟委员会列出了它认为保护水平充分的国家。对美国而言，2023 年 7 月的认定覆盖参与欧美数据隐私框架（DPF）的公司。欧盟普通法院于 2025 年 9 月维持了该认定，2025 年 10 月又有人就此向欧盟法院提起上诉，因此在依赖它之前，请先确认其现状。
• 标准合同条款。 在没有适用的充分性认定时，欧盟委员会 2021 年版标准合同条款（SCC）是常用的合同型保障措施。
• 其他保障措施和例外情形，例如有约束力的公司规则或明确同意，适用于更窄的情形。

在数据映射图上，一次传输就是一条离开你所在区域的连线，标注目的地和保障措施。

完整示例：一个 B2B SaaS 产品

该产品运行在一个 EU 云区域中：一个 Web 应用、一个 PostgreSQL 数据库和一个分析数据仓库。有五个供应商会接收个人数据：位于 EEA 的邮件发送和支付服务，以及位于美国的产品分析、支持台和 CRM。

这张图的读法如下：

• 入口。 客户的用户创建账户、付款、使用产品并联系支持。从 Web 应用出发的每条数据流都标有它所携带的数据类别。
• 自有系统，EU 区域。 应用数据库保存账户和工作区数据。数据仓库接收的使用事件带的是假名化 ID，而不是姓名。
• EEA 内的处理者。 邮件发送服务接收姓名、邮箱地址和邮件内容；支付服务接收账单联系人和发票。这里不涉及跨境传输。
• 美国的处理者。 进入这个框架的每条连线都是一次传输，并标有保障措施：获得该框架认证的供应商标 DPF，未获认证的那一家标 SCC。
• 图例 解释各个标注，并列出每个存储的示例保留期限。

有帮助的绘图约定

• 用数据类别而不是技术来标注连线。 “姓名、邮箱、工单内容”对评审人有用；“REST API”没用。
• 在你自己的系统周围画一条边界，把处理者放在边界之外，并按区域分组。
• 标出每一次传输，写明目的地和保障措施。
• 用统一的一种颜色突出特殊类别的数据，并在图例中说明它的含义。
• 在每个存储上写明保留期限。 这是处理活动记录中最常缺失的一项。
• 把目的和合法性基础留在记录里，放在图旁边。图展示数据在哪里；记录说明为什么。

保持最新

有人新增一个供应商的那天，数据映射图就过时了。把更新和会改变它的事件绑定在一起：供应商引入、收集新数据的新功能，以及数据保护影响评估。根据第 35 条，对于可能带来高风险的处理，控制者必须在开始之前进行评估，而数据映射图正是这项评估的天然起点。每年完整复查一次，并保留上一个版本。不会过时的架构图介绍的正是这样一套工作流程；在隐私 wiki 中嵌入实时更新的图，能让所有人看到同一个版本。

数据映射如何帮助处理数据主体请求

访问或删除请求必须覆盖一个人的数据所在的每个地方：应用数据库、数据仓库、备份，以及每一个处理者。有了最新的数据映射图，回应请求就是照着清单逐项处理，而不是到处搜索。处理者在合同上有义务协助处理这类请求，而数据映射图会告诉你该找哪些处理者。

如需从安全角度看同样的数据流，请参阅威胁建模中的数据流图。

在 Archboard 中构建

1. 使用 Google 或 GitHub 登录，并新建一张图。
2. 为客户的用户添加一个 C4 模型节点包中的 人员。
3. 为你在 EU 区域的系统添加一个基础节点包中的 框架，在里面为 Web 应用放一个 C4 模型节点包中的 容器，为应用数据库放一个数据节点包中的 Postgres，为分析放一个数据节点包中的 数据仓库。
4. 为处理者再添加两个基础节点包中的 框架，一个代表 EEA，一个代表美国，并为每个供应商角色放一个 C4 模型节点包中的 外部系统 节点。
5. 为每条连线标注它携带的数据类别，并在每条进入美国框架的连线上加上保障措施。
6. 添加一个基础节点包中的 Markdown 块，写入图例和保留期限。

这个示例共用 13 个图表节点，在 Free 套餐的限制之内。GDPR 数据映射用例展示了更多数据映射图的布局方式。

常见问题

GDPR 要求必须有数据映射图吗？ GDPR 第 30 条要求的是处理活动记录，而不是一张图。不过大多数团队会发现，不先梳理数据流，就无法建立或维护一份准确的记录。

数据映射图应该归谁负责？ 记录及其中的决定归隐私团队；系统归工程团队。给这张图在两边各指定一位负责人，并一起评审。

数据映射图应该展示单个数据库表吗？ 不应该。展示存储以及其中的数据类别即可。表级别的细节应该放在数据目录里。

一个供应商既是处理者又是控制者，该怎么表示？ 只画一次，并按每条数据流标注它的角色。有些服务商（例如支付服务商）在部分处理中以控制者身份行事；具体是哪些部分，由合同说明。

这张图能取代第 30 条要求的记录吗？ 不能。记录必须以书面形式包含特定信息，包括处理目的和安全措施。用这张图来建立和核对记录。

免费开始 — 1 个席位，无需信用卡。