网站 GDPR：给做工程的团队的一份实操指南
GDPR 自 2018 年 5 月 25 日起适用。八年过去，大多数公司相信自己是合规的，而我们看过的大多数网站并不合规。
这通常不是出于漠不关心。而是因为 GDPR 的工作只做过一次，以文档的形式，然后系统绕着它继续演进。新的分析工具、新的 CRM、新的聊天机器人、新的营销自动化。每一个都增加了处理记录从未覆盖到的处理活动。
这份指南聚焦你作为工程团队真正拥有的那一面：数据模型、集成、权利请求，以及代码里到底发生了什么。它不是法律建议，我们也刻意避开属于你们律师的解释性问题。
先讲一小段基础
第 (EU) 2016/679 号条例管的是个人数据的处理。个人数据是与已识别或可识别自然人相关的任何信息，而"可识别"这个概念比多数团队想象的要宽。IP 地址、Cookie 标识符、设备标识符、哈希后的邮箱和用户账户 ID 全都算。
如果你在欧盟设有机构，条例适用于你；如果你不在欧盟，但向欧盟境内的人提供商品或服务，或监测他们的行为，同样适用。
控制者决定处理的目的和方式。处理者代表控制者进行处理。大多数网站所有者是控制者，大多数 SaaS 供应商是处理者，但也存在供应商是独立控制者的情形，那会改变你需要的合同。
六项处理依据，以及被滥用的那一项
每一项处理活动都需要第 6 条下的一项依据：
- 同意。 自由给出、具体、知情、明确无误。撤回必须和给予一样容易。
- 合同。 为履行与数据主体的合同所必需。
- 法律义务。 法律要求你这么做。
- 重大利益。 在网站场景中很少见。
- 公共利益。 主要是公共部门。
- 合法利益。 你或第三方的利益，且不被数据主体的权利所压倒。
实践中，合法利益是被滥用的那一项。它是真实存在的依据，但常常在没有做那个让它成立的平衡测试的情况下被援引。如果你打算用它，你需要一份书面评估，标明利益是什么、评估必要性、并权衡数据主体的权利。一页纸就够。什么都没有则不够。
有一点不能靠猜：访问用户设备上的数据或在其上存储数据，属于电子隐私指令的范围，不只是 GDPR。这就是为什么非必要 Cookie 需要同意，无论你为数据本身援引了哪项处理依据。
网站真正失败的地方
八年的修补之后，同一份清单反复出现。
脚本在同意之前加载
经典问题。同意横幅渲染出来了，但 Google Analytics、Meta 像素和聊天挂件已经从 <head> 里加载了。用户什么都没点，三个第三方已经拿到了他的 IP。
这是代码问题，不是平台问题。同意平台能拦截它认识的脚本，但你自己加的 script 标签，如果没有条件化，照样会加载。真正的修法是条件加载：在同意状态已知之前不注入任何脚本。
按监管机构的方式去测。用干净的配置文件打开浏览器，打开网络面板，加载页面，不要碰横幅，看看有什么发出去了。那就是审计。
同意横幅无效
要求已经稳定下来了，而大多数横幅至少违反其中一条：
- 拒绝必须和接受一样容易，同一层级的按钮，不能藏在菜单里。
- 预先勾选的选择框不是同意。
- "继续浏览即表示您同意"不是同意。
- 同意必须按目的可分开选择。一个总开关不行。
- 撤回必须和给予一样容易，也就是要有一个常驻链接重新打开设置。
- 必须保存同意证据：同意了什么、何时、用的是哪个版本的横幅。
最后一条最常被忘掉。没有同意日志，"用户同意了"这句话就无法证明。
规则集正在变化。Digital Omnibus 拟议的第 88a 条和第 88b 条会把这些规则搬进 GDPR，加上拒绝后六个月的静默期，并让机器可读信号具有法律约束力。这仍在谈判中，我们在Digital Omnibus 之后的 Cookie 同意里讨论了现状。
无法满足数据主体请求
用户要求一份自己数据的副本。你需要全部，而全部意味着每一个系统：生产数据库、分析、CRM、工单系统、邮件平台、文件存储、日志、备份、数据仓库。
大多数组织能从生产数据库里回答，其余靠猜。那不是合规，那是运气。
期限是收到请求后一个月，复杂情形下可延长两个月，前提是你在第一个月内告知了延长。
你必须实现的权利：
- 访问权。 数据副本以及关于处理的信息。
- 更正权。 修正不准确的数据。
- 删除权。 条件满足时予以删除。
- 限制处理权。 保留数据但停止处理。
- 可携带权。 结构化、常用、机器可读的格式，且在技术可行时直接传输给另一控制者。
- 反对权。 特别是针对直接营销，此时停止是无条件的。
- 不受仅基于自动化决策约束的权利，前提是该决策产生法律效果或类似的重大影响。
你为此构建的可携带接口，很大程度上就是数据法案对产品数据要求的同一套基础设施。值得只建一次。
留存期实际上是永久
GDPR 要求个人数据的保存时间不超过收集目的所必需。实践中，大多数系统永远保存一切，因为从来没有人构建过删除。
行之有效的做法是把留存做成数据模型的属性，而不是政策文档。每一张含个人数据的表都有一条留存规则，每条规则都有一个定时任务，任务记录它删了什么。没有这些，你对监管机构"这个你们保存多久？"的回答就是"直到有人想起来"，那不是回答。
备份是一个长期问题。被普遍接受的立场是：如果存在一份书面流程，确保恢复的数据不会被再次处理，并且会随备份轮换而消失，那么备份不必支持定向删除。这个立场应该在用到之前就写下来。
跨境传输处理得很表面
如果数据离开欧盟，你需要一项传输机制：充分性决定、标准合同条款或有约束力的公司规则。如果你用标准合同条款，你还需要一份传输影响评估。
实际的难点在于清单。大多数团队知道大的供应商，漏掉小的：字体托管、CDN、错误跟踪、邮件投递、客服挂件、A/B 测试平台。只要供应商在欧盟之外处理，每一个都是一次传输。
怎么建才能保持正确
保持合规的网站和逐渐走偏的网站，差别是结构性的。
让处理记录成为活的产物。 这是第 30 条的要求，在大多数地方它是一份过期的电子表格。把它放在离代码近的地方，每次新增集成时复核，并让它成为供应商引入流程的一部分。
集中个人数据。 个人数据散落的系统越多，每一次权利请求就越贵。一个规范的人员实体加引用，而不是副本。
权利请求处理只建一次，建好。 一条工作流查询每一个系统、汇总结果、记录做了什么。如果是手工的，它就慢、不一致，并且恰好在最关键的时候误了期限。
让同意状态成为一等概念。 你的应用应该能以编程方式查询同意状态，并在服务端据此做决定，而不只是决定浏览器里某个脚本加不加载。
在做决定的当下就记录下来。 一小段说明：为什么选了合法利益、为什么留存是 24 个月、为什么这个供应商是处理者而不是控制者。这些记录正是监管机构会要的东西，而且一年后几乎不可能重建。
数据泄露
自你知悉个人数据泄露起 72 小时内向监管机构通报，除非该泄露不太可能带来风险。对高风险泄露，还要毫不迟延地通知数据主体。
如果你的组织同时有 NIS2 或网络韧性法案的义务，你会有面向不同机构、门槛不同的并行倒计时。把它们放在一起设计。我们写过这两者：NIS2 指南和网络韧性法案指南。
罚款，以及真正触发罚款的东西
上限是 2000 万欧元或全球年营业额的 4%，取较高者，适用于最严重的违规；其他违规是 1000 万欧元或 2%。
实践中，执法的触发方式很好预测：未获答复的数据主体投诉、监管机构按行业开展的 Cookie 横幅行动、引发更大范围审计的已通报泄露，以及被竞争对手举报的广告技术相关站点。
模式是：一件小事打开了门，审计覆盖了全部。
现实的起步顺序
如果你从一个不确定的位置开始，这个顺序见效最快：
- 检查同意之前加载了什么。 一小时，而且这是最常见的发现。
- 按系统盘点个人数据。 不求完美，但求诚实。大多数组织会发现从没被列出来的系统。
- 自己走一遍数据主体请求。 索取你自己的数据，看要多久、缺什么。
- 复核供应商清单的传输与合同。 每一个接触个人数据的供应商都需要一份数据处理协议。
- 在数据增长最快的地方设留存期。 日志、分析、工单。
这是几周的工作，不是一个季度，而它把你从猜测带到了知道。
我们在哪里介入
我们为在欧洲经营的公司构建和维护软件，这类工作我们常做：在服务端也成立的同意架构、覆盖每个系统的数据主体请求工作流、留存自动化，以及因为接在引入流程上而始终保持正确的数据地图。
我们不是律师事务所，也不提供法律建议。我们把你们律师定下的立场，变成一个能运转的系统。
如果你们的网站或产品需要这类工作，写信到 office@c9group.dev。更广的监管图景见我们的 2026 年欧盟数字合规指南，更多关于我们欧洲业务的内容见欧盟市场进入页面。