GDPR 合规实务：没有证书，但你绕不开

安世加

2026年10月16日 18:00
上海

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

\"你们有 GDPR 证书吗？\"——这个问题的潜台词是：\"我怎么确认你们真的合规。\" 需求完全合理，只是问题本身找错了出口——GDPR 是法律，不是标准，不存在一张能证明\"企业整体符合 GDPR\"的证书。

严格来说，GDPR 第 42 条确实设立了认证机制，但它认证的是具体的处理活动（某个产品、服务或流程），不是整家公司，而且认证方案必须经监管机构或 EDPB 批准。目前获 EDPB 批准、可在全欧盟通用的是 Europrivacy（欧洲数据保护印章，2022 年批准）。即便拿到，它也只是证明合规的手段之一，不能免除你的法律义务。

市面上流传的\"GDPR 合规证书\"\"GDPR 合规检测报告\"——多数是把一份自我声明或咨询报告包装成证书卖给你。真正有分量的证明大致三类：经批准的 GDPR 认证方案（如 Europrivacy）、SOC 2 报告里的 Privacy 准则部分、ISO/IEC 27701 认证。后两者证明的是管理体系在运行，并不等于\"通过了 GDPR\"。

但这不是说 GDPR 可以糊弄。恰恰相反：法规比认证更难缠。认证看你有没有达到标准，法规看你的行为本身。

这篇文章把 GDPR 讲透：边界在哪、要做什么、怎么和已有认证接上、2026 年有什么新变化。

一、先搞清边界：你什么时候被 GDPR 管

很多出海企业以为自己\"没有欧盟实体，所以不受管\"，这是最常见的误判。

适用范围（Art. 3）

GDPR 的管辖有三种触发方式，命中任意一条就受管：

① 在欧盟设有机构

且处理活动发生在该机构活动背景下。典型情形：在德国有子公司，处理员工与客户数据

② 未在欧盟设立，但向欧盟数据主体提供商品或服务

典型情形：中国 SaaS 向欧洲客户卖订阅

③ 未在欧盟设立，但监控欧盟数据主体的行为

典型情形：用 Cookie 追踪欧洲用户行为做画像

关键：一家中国 SaaS 公司，只要有意面向欧盟用户提供产品或服务（如提供欧盟语言版本、欧元定价、在欧盟投放广告），或追踪欧盟用户的行为，就受 GDPR 管辖——不需要在欧盟有实体，不需要在欧盟有服务器。反过来，仅仅是欧盟用户\"能访问\"你的网站，本身不足以触发（EDPB《Guidelines 3/2018》）。

容易漏的一项：按 Art. 3(2) 受管的非欧盟企业，原则上还要依 Art. 27 在欧盟书面指定一名代表，作为监管机构和数据主体的联络点（偶发、低风险且不涉及大规模特殊类别数据的处理可以豁免）。没指定代表，本身就是违规。

罚则（Art. 83）

两档上限，取高者：

低档

上限1000 万欧元 或 全球年营业额 2%

覆盖Art. 8、11、25-39、42、43

高档

上限2000 万欧元 或 全球年营业额 4%

覆盖Art. 5、6、7、9、12-22、44-49

注意高档覆盖了什么：合法性、同意、数据主体权利（Art. 12-22）、跨境传输（Art. 44-49）——出海企业最常踩的坑，几乎全部落在高档。

角色决定义务强度：控制者 vs 处理者

这是 SaaS 出海最该先分清的一件事：

控制者（Controller）

决定处理的目的和方式。

义务全责，义务最重

处理者（Processor）

受控制者委托处理数据。

义务较轻，但可以直接被罚

重要提醒：不要以为\"我只是处理者就安全\"。处理者对安全义务（Art. 32）等直接负责，2025 年已有多张罚单直接开给处理者，供应链安全和合规正在成为执法重点。作为 SaaS 厂商，你大概率是处理者——但处理者视角下的义务（安全措施、审计配合、子处理者管理）一样不能少。

怎么判定：看谁决定\"目的\"和\"基本手段\"

GDPR 原文（Art. 4(7)）写的是\"决定处理的目的和方式\"，听起来模糊，实操时要拆成两层——这是最容易判错的地方：

基本手段

处理哪些数据、涉及哪些人、留存多久、提供给谁。判定结果：和目的一起，谁决定，谁就是控制者

非基本手段

用哪家云、什么数据库、怎么加密、代码怎么写。判定结果：不影响角色判定

所以\"架构是我们自己搭的、代码是我们自己写的\"不构成控制者身份。你决定用 AWS 还是阿里云、TLS 1.3 还是 1.2，都不算\"决定处理方式\"。技术团队最容易在这一步判错。

三问实操法：拿一批数据，依次问三个问题——

1. 为什么要处理这批数据？

谁定的目的

2. 处理哪些字段、留存多久、谁能看到？

谁定的范围

3. 用户提数据请求时找谁？

谁对外负责

前两问是硬判据，第三问做辅助验证。三问答案都指向客户，你就是处理者。

SaaS 的现实是混合角色。所以正确的问法不是\"我们公司是什么角色\"，而是按数据类型列一张角色清单：

客户上传到产品里的终端用户数据

你的角色：处理者 · 谁定目的：客户

用客户数据做产品改进、模型训练

你的角色：控制者 · 谁定目的：你（这是你新增的目的）

官网访客、市场活动线索

你的角色：控制者 · 谁定目的：你

自己员工的人事数据

你的角色：控制者 · 谁定目的：你

你自己的业务数据存放在第三方云／客服工具

你的角色：控制者（对方是你的处理者）· 谁定目的：你

第二行是 SaaS 最容易漏的坑：如果产品里有\"分析客户使用行为来改进功能\"这类动作，而分析对象包含终端用户的个人数据，那这部分你是控制者，需要自己的合法依据和告知——不能藏在 DPA 后面说\"我只是处理者\"。

另一种情况也要分清：如果放进第三方云的是客户的数据，那这家云厂商就是你的子处理者——需要事先取得客户授权，并和它签下游 DPA（Art. 28(2)、28(4)）。

两条硬规则：

角色是事实判断，合同改不了它。EDPB《Guidelines 07/2020》立场明确：合同里写\"乙方为处理者\"，但你实际决定处理目的，法律上你仍然是控制者；反过来客户逼你在合同里承认控制者责任，也改变不了客观事实。先判清事实，别指望用措辞规避。

两个方向判错都贵。把控制者错当处理者 → 漏掉告知义务和 DSR 响应（属 4% 高档）、漏做 DPIA（属 2% 档）；把处理者错当控制者 → 过度承诺义务，客户法务会顺势把不该你担的责任写进合同。

这张清单建议和 RoPA 一起做：一个定性、一个定范围，两张表放在同一份文档里，内部对齐和客户尽调时都能直接用。

六项原则（Art. 5）

全部义务的源头就这六条：合法性/公平性/透明性、目的限制、数据最小化、准确性、存储限制、完整性与保密性。

外加一条问责制（Accountability）：不仅要合规，还要能证明自己合规。这条是 GDPR 真正的抓手——它决定了后面所有\"证据\"要求的来源。

二、七项核心义务：出海 SaaS 的落地清单

把 GDPR 拆成可执行的动作，其实就是下面七件事。每项都给出\"要求 → 动作 → 证据\"。

① 处理活动记录（Art. 30）

要求保留数据处理活动记录（RoPA）

动作建数据地图：数据从哪来、存哪、给谁、传哪

证据RoPA 文档，随业务变更更新

② 合法依据（Art. 6/7）

要求每项处理必须有合法依据

动作逐项标注依据；用同意时做到\"自由给出、明确、知情\"

证据依据清单 + 同意记录

③ 数据主体权利（Art. 12-22）

要求响应访问/更正/删除/可携带/反对/限制

动作建 DSR 表单与流程，1 个月内响应（复杂或请求量大时可再延长 2 个月，但须在 1 个月内告知对方）

证据请求台账 + 响应记录

④ DPIA（Art. 35）

要求高风险处理须做影响评估

动作先做筛查：系统性评估／画像并产生重大影响、大规模处理特殊类别数据、大规模系统性监控公共区域；同时对照当地监管的 DPIA 清单

证据DPIA 报告 + 缓解措施

⑤ 跨境传输（Chapter V）

要求出境须有合法机制

动作充分性认定（中国目前没有）/ SCCs / BCR；签了 SCCs 还要做传输影响评估（TIA）

证据传输清单 + SCCs + TIA

⑥ 泄露通知（Art. 33/34）

要求知悉后 72 小时内通知监管机构（不太可能造成风险的可不报）

动作建事件响应流程，明确判定与上报路径

证据事件记录 + 通知留档

⑦ DPO 任命（Art. 37）

要求三种情形必须设

动作公共机构 / 核心业务涉及大规模、常规且系统性的监控 / 核心业务涉及大规模处理特殊类别或刑事数据

证据任命文件 + 职责说明

几个容易搞错的地方

RoPA 的豁免不是绝对的：员工少于 250 人的企业有条件豁免，但只要处理不是偶发的、可能带来风险，或涉及特殊类别／刑事数据，仍须保留记录。持续运营的 SaaS 基本不满足豁免条件——2025 年 CNIL 处罚 Optimove 时就明确了这一点（见第七节）。

DPO 不是\"兼职挂个名\"就行：GDPR 要求 DPO 独立履职、直接向最高管理层汇报、不得因履职被解雇或处罚。挂名 DPO 在审计中属高风险项。

72 小时是给监管机构的：数据主体通知是\"无不当延迟\"，高风险泄露才触发，别把两者搞混。

同意不是万能钥匙：多数场景下同意最难拿到也最难维持（可随时撤回）。能落在\"合同履行必要\"或\"合法利益\"上，通常比硬拿同意更稳。

DPA 有法定必备条款：Art. 28(3) 规定了处理者合同必须写明的内容（按书面指令处理、保密、安全措施、子处理者、协助控制者、合同结束后删除或返还数据、配合审计）。模板缺条款，等于合同本身不合规。

别漏欧盟代表：没有欧盟实体但受 Art. 3(2) 管辖的企业，需按 Art. 27 指定欧盟代表。这一项 SOC 2 和 27701 都替你做不了。

三、关键区分：SOC 2 Privacy 能覆盖什么，覆盖不了什么

这是本文最该记住的部分——它决定了你的认证到底\"顶不顶用\"。

能覆盖的（体系证据层面）

SOC 2 的 Privacy 准则（P1-P8）可以与 GDPR 条款大致对应（以下为常用对照，并非官方映射）：

P1 通知 ↔ Art. 13/14

收集时告知：目的、接收方、权利

P2 选择与同意 ↔ Art. 6/7

合法依据、同意的明确性

P3 采集 ↔ Art. 5(1)(c)

数据最小化

P4 使用、保留与处置 ↔ Art. 5(1)(e)

存储期限限制，到期删除

P5 访问 ↔ Art. 15/16

数据主体访问与更正（DSR）

P6 披露与通知 ↔ Art. 13/14 + 33/34

透明披露 + 泄露通知

P7 质量 ↔ Art. 5(1)(d)

数据准确、及时更新

P8 监督与执行 ↔ Art. 24 + 5(2)

问责制：投诉处理、合规监测与整改

覆盖不了的（必须单独做）

这张表比上一张更重要——因为它列出了一份 SOC 2 报告\"不能替你回答\"的问题：

跨境传输机制（SCCs、充分性认定、TIA）　不覆盖

SOC 2 审的是控制措施，不是传输的法律机制

DPIA（数据保护影响评估）　不覆盖

SOC 2 没有这个交付物

DPO 任命与独立性　不覆盖

组织结构事项，不在 SOC 2 范围

与监管机构的沟通　部分覆盖

SOC 2 管内部响应，不管对外申报

Art. 9 特殊类别数据例外　不覆盖

需单独识别与论证

RoPA 处理活动记录　部分覆盖

SOC 2 的资产/数据清单不等同于 Art. 30 记录

欧盟代表（Art. 27）　不覆盖

法律义务，需单独指定

所以正确的说法是：SOC 2 Privacy 是你向客户证明\"体系在跑\"的证据底座——它是美国注册会计师协会（AICPA）体系下的鉴证报告，不是欧盟认可的 GDPR 认证；GDPR 合规是这些证据 + 一批 SOC 2 覆盖不到的专项动作。前者可以请第三方审计，后者只能自己做。

四、ISO 27701：把体系侧补齐

如果说 SOC 2 Privacy 是\"报告\"，那 ISO 27701 就是\"认证\"——PIMS（隐私信息管理体系）标准。2019 版是 ISO 27001 的隐私扩展，必须先有 27001；2025 年 10 月发布的 ISO/IEC 27701:2025 已改为独立的管理体系标准，可以单独认证，也可以与 27001 一起审核。2019 版证书的转版截止时间一般为 2028 年 10 月，以认证机构通知为准。

三个要点：

可以整合审核：2025 版虽可独立认证，但与 27001 采用相同的管理体系结构，文件控制、内审、管理评审等可以共用；已有 27001 的企业做整合审核成本最低；

自带条款映射：27701 的资料性附录（Annex D）给出了与 GDPR 的对应关系，省掉大量自行对照的成本——但它只是参考，拿到 27701 证书不等于证明符合 GDPR；

分工清晰：SOC 2 面向客户（美国市场问卷文化需要报告），27701 面向体系（欧盟大企业和合规部门更认认证）。

谁该做：客户集中在欧盟、被反复追问隐私合规、计划把 27001 升级为\"安全 + 隐私\"双体系的企业。如果只是偶尔有欧盟客户，先用 SOC 2 Privacy 打底即可，不必急着做 27701。

五、落地路径：四步走

不要一上来就买工具、改政策。按这个顺序走，返工最少：

第一步 · 定角色

分清每类数据你是控制者还是处理者。

产出角色清单（按数据类型/场景）

卡点混合角色不拆开，导致义务错配

第二步 · 画地图

数据结构化盘点：来源、存储、共享、出境。

产出RoPA + 数据流图

卡点盘点不全，漏掉日志、备份、第三方

第三步 · 补文档

隐私政策、DPA、SCCs、DPIA、保留策略。

产出文档包

卡点文档写了但没人执行

第四步 · 通流程

DSR 响应、泄露响应、证据留存。

产出流程 + 台账

卡点没有留证，等于没做

顺序很重要：②③④ 都依赖 ①。很多企业上来就改隐私政策（③），结果因为角色没定清，义务范围本身就是错的——改完还得重来。

六、2026 年的新变量：Digital Omnibus

这是必须知道的最新动态，也是很多中文解读还没跟上的部分。

提案是什么，通过了吗

2025 年 11 月 19 日，欧盟委员会发布 Digital Omnibus 一揽子简化提案。它分成两条线，命运完全不同：

AI 线（COM(2025) 836）

修订 EU AI Act。

状态已生效：Regulation (EU) 2026/1744（2026 年 7 月 8 日签署，7 月 27 日生效）

数据线（COM(2025) 837）

修订 GDPR 本身。

状态仍是提案：截至 2026 年 9 月，理事会尚未形成谈判授权，议会仍在一读，三方谈判未启动；何时通过、最终文本如何均未定

拟议中的 GDPR 修订要点

泄露通知：仅在可能造成\"高风险\"时才须通知监管机构（门槛提高），时限从 72 小时延长到 96 小时，并为 GDPR、NIS2、DORA 等建立单一报告入口；

访问权收口：针对\"滥用型访问请求\"（例如借 Art. 15 取证用于劳动争议或民事诉讼）设置限制；

个人数据定义收窄：以持有方能否识别为准——对某一方无法识别的数据（如它拿不到密钥的假名化数据），对它可能不构成个人数据；

AI 相关：拟新增 Art. 88c（AI 开发运营的合法利益依据）与 Art. 9(2)(k)（AI 训练中的残余特殊类别数据例外）；

统一模板与清单：欧盟层面统一的泄露通知模板和高风险情形清单，以及需要／无需做 DPIA 的统一清单；

Cookie 规则并入 GDPR：安全、自用汇总统计等低风险用途免同意；要求提供一键拒绝，用户拒绝后至少 6 个月内不得再次弹窗征求同意。

怎么看待它

2026 年 2 月 10 日，EDPB 与 EDPS 通过联合意见 2/2026：总体支持简化方向，但明确警告不要削弱数据主体的基本权利。反对最强烈的是收窄个人数据定义，两机构\"强烈敦促\"立法者不要采纳；对 AI 条款和访问权限制也有保留；对 96 小时时限和\"高风险\"门槛则表示欢迎。

给你的实操结论：当前有效的法律，仍然是现行 Art. 13/14/15 的权利和 72 小时泄露窗口。不要把提案当依据来做设计——文本在通过前可能大幅变化。正确姿势是：按现行法做合规，同时跟踪提案进展。

七、执法数据：为什么\"等等看\"是最贵的选择

累计与年度

累计罚款（2018.5 - 2026.1）

约 71 亿欧元

2025 年全年罚款

约 12 亿欧元（与 2024 年持平）

爱尔兰 DPC 累计

约 40.4 亿欧元（约占总额 57%）

罚款案件数量第一

西班牙（连续第七年）

泄露通知量（2025.1-2026.1）

日均 443 件，同比涨 22%（2018 年来首破 400）

数据来源：DLA Piper《GDPR Fines and Data Breach Survey》（2026 年 1 月）；CMS《GDPR Enforcement Tracker Report》（2026 年）。

历史最高罚款 Top 10

1Meta12 亿欧元 · 2023
非法 EU-US 数据传输

2TikTok5.3 亿欧元 · 2025
非法 EEA 至中国传输 + 透明度缺失

3Instagram4.05 亿欧元 · 2022
儿童数据处理不当

4Meta3.9 亿欧元 · 2023
广告处理的合法依据不成立

5TikTok3.45 亿欧元 · 2023
儿童数据 + 暗黑模式

6LinkedIn3.1 亿欧元 · 2024
行为广告合法依据不成立

7Uber2.9 亿欧元 · 2024
司机数据传输至美国

8Meta2.65 亿欧元 · 2022
数据抓取与设计保护缺失

9Meta2.51 亿欧元 · 2024
2018 年数据泄露：设计保护缺失 + 泄露通知不当

10WhatsApp2.25 亿欧元 · 2021
透明度缺失

注：Amazon 2021 年 7.46 亿欧元罚款已于 2026 年被撤销，未计入；Google 2025 年 3.25 亿欧元罚款（法国 CNIL）依据的是法国 Cookie 与电子营销规则，不属于 GDPR 罚款，也未计入。

三个最该记住的洞察

① TikTok 的 5.3 亿欧元，是中国出海企业最该看的案例

不是因为算法，而是因为EEA 到中国的数据传输 + 透明度缺失——这恰好是中国出海企业的典型风险区。罚款理由是传输机制，不是技术问题。

② 处理者会被直接罚

2025 年已有多张罚单直接开给处理者（Processor），下面这家以色列公司就是一例。SaaS 厂商别以为\"我只是帮客户处理数据\"就安全，安全措施不到位一样担责。

③ 非欧盟实体照样罚

2025 年 12 月，法国 CNIL 对以色列营销技术公司 Optimove（Mobius Solutions，Deezer 的处理者）罚款 100 万欧元——它在合同终止后仍保留约 4690 万 Deezer 用户的数据，以\"改进服务性能\"为由在指令之外自行处理，数据最终泄露；同时未建立处理活动记录（员工虽不足 250 人，仍不能豁免）。\"我不在欧盟\"从来不是抗辩理由。

一个别误读的案例

2021 年卢森堡对 Amazon 开出的 7.46 亿欧元罚款，在 2026 年 3 月被卢森堡行政法院（上诉审）撤销，案件发回监管机构重新决定。

注意撤销的理由：程序问题——监管机构没有分析违规是出于故意还是过失，也没有说明为什么选择罚款而非其他纠正措施。法院同时确认了大部分违规事实成立。

所以别把它读成\"监管松了\"。它说明的是：罚款金额可以被挑战，但违规认定很难推翻。合规该做还得做。

八、常见踩坑

1. 找 GDPR 证书——不存在\"整体合规证书\"，卖\"GDPR 合规证书\"的多数是智商税。经批准的 GDPR 认证（如 Europrivacy）针对的是具体处理活动；SOC 2 Privacy 和 ISO 27701 证明的是体系——三者都不等于\"GDPR 合规\"。

2. 以为签了 DPA 就完事——DPA 是合同义务的起点，不是合规终点。签了不做，等于承认了义务却没履行。

3. 只改隐私政策，不改流程——政策是承诺，流程是能不能兑现。DSR 请求来了 3 个月不回，政策写得再漂亮也没用。

4. 忽视处理者视角——处理者会被直接罚。安全措施、子处理者管理、审计配合，一样都不能少。

5. 用了 SCCs 却没做 TIA——Schrems II 之后，签标准合同条款只是第一步，还必须做传输影响评估（TIA）。

6. DSR 响应不留证据——问责制的核心是\"能证明\"。响应了但没记录，在监管眼里等于没响应。

7. 把 Digital Omnibus 提案当现行法——数据线尚未通过。按现行法设计，别拿提案做依据。

8. 只盯罚款，忽略民事索赔——GDPR 第 82 条允许个人索赔，欧盟法院已确认非物质损害也可索赔，且不设\"严重程度\"门槛（C-300/21）。罚款是监管给的，索赔是用户给的，两条线并行。

9. 没有欧盟实体就不指定欧盟代表——Art. 27 是独立义务，没指定代表本身就构成违规，而且这是监管最容易查实的一项。

法规不发合规证书，但它给了你一套证据链逻辑。

认证是\"我达到了标准\"，法规是\"我为我的行为负责\"。前者可以请第三方审，后者只能自己做。

SOC 2 Privacy 给你证据底座，ISO 27701 给你体系框架，而 GDPR 要的，是你把这两样变成每天在跑的东西——数据主体发来一封请求邮件时，有人知道该在几天内回复、怎么回、留什么档。

证书挂在墙上，合规活在流程里。