第1章 GDPR概述与核心原则
我刚开始做数据合规审计那会儿,最头疼的就是客户问我:“我们公司不在欧洲,跟GDPR有什么关系?” 嗯,这个问题其实很典型。咱们先把GDPR的来龙去脉理清楚,后面做审计报告时心里才有底。
1.1 为什么会有GDPR?
2016年之前,欧盟的数据保护主要靠1995年的《数据保护指令》。但互联网发展太快了——社交网络、云计算、跨域追踪……那个指令已经跟不上节奏。更直接的原因是几起重大数据泄露事件,比如2015年某社交平台5000万用户数据被滥用。欧盟当时就意识到:再不升级规则,公民数据就跟裸奔一样。
于是2016年4月,《通用数据保护条例》(GDPR)正式通过,2018年5月25日起强制执行。它不再是指令,而是直接适用的法规,各国不用再各自转化立法。罚款上限也狠——2000万欧元或全球年营收的4%,取高者。
一个关键点:GDPR不只保护欧盟公民,而是保护“在欧盟境内的任何数据主体”,包括游客、留学生。我做过一个案例:一家中国电商网站向西班牙游客卖商品,因为没处理好游客的个人数据,被西班牙监管机构盯上了。
1.2 GDPR管到谁?
别以为只有注册在欧盟的公司才受管。GDPR的管辖范围分两条线:
- 地域管辖:机构在欧盟境内设立(哪怕只是个代表处),无论数据在哪处理,都适用。
- 效果管辖:不在欧盟设立,但向欧盟境内的数据主体提供商品/服务(不管是否收费),或者监控他们的行为(比如通过cookies跟踪访问习惯),照样适用。
我见过一个美国SaaS公司,软件免费、靠广告收入,网站只支持英文、支付用美元——照理说没针对欧盟市场。但它的追踪代码收集了欧盟用户的IP和浏览行为,最后被认定构成“监控行为”,被罚了120万欧元。说白了,只要你的业务链条里有欧盟用户的数据流过,就得先好好查一遍。
下面这段伪代码能帮你快速判断:
def is_gdpr_applicable(entity):
if entity.establishment_in_eea:
return True
if entity.offers_goods_or_services_to_eea_subjects:
return True
if entity.monitors_behavior_of_eea_subjects:
return True
return False # 但仍然建议做合规评估
1.3 核心原则
GDPR第5条列出了7项基本原则。别看条款多,你抓住前三项,其他就顺了。我习惯把它们分成“数据收集前的规矩”和“数据持有后的规矩”。
| 原则 | 核心要求 | 避坑提示 |
|---|---|---|
| 合法、公平、透明 | 有明确法律依据(同意、合同、法律义务等),不能暗箱操作;隐私声明必须简单易懂。 | 我曾经审计一家公司,Privacy Policy用了四号字体、密密麻麻的法律术语,监管一句“不透明”就开了罚单。 |
| 目的限制 | 收集数据时就要说清用途,不能回头又拿去干别的。 | 常见坑:用户注册时收集手机号用于登录,后来悄悄用它做营销短信。 |
| 数据最小化 | 只收集与目的直接相关且必要的数据,不多收。 | “万一以后有用”这种想法就是违法信号。我建议每张数据采集表都过一遍:如果砍掉这个字段,业务还能跑吗? |
| 准确性 | 数据要准确,过时的要更新或删除。 | 用户地址变了,你系统里还留着三年前的地址,算违规。 |
| 存储限制 | 存多久?用完就删,不能无限期保留。 | 设定保留周期(比如交易日志保留6个月),到期自动清除。 |
| 完整性与保密性 | 技术措施(加密、访问控制)和组织措施(权限制度)保障数据安全。 | 我被请去应急过一家公司,离职员工的DBA账号没回收,结果把生产库删了。 |
| 问责制 | 你能证明自己遵守了以上所有原则。记录、日志、审计轨迹…… | “我们是小公司没留日志”不是借口,DPIA、RfPA都得做。 |
好,接下来这张图把原则之间的依赖关系理清楚了:
审计实操建议:每次生成审计报告前,先把这7条原则列成检查清单。我习惯在报告里对应每一原则都写一条“合规状态”。比如“目的限制——合规:数据使用时均在原始告知范围内”。这样监管方一眼就能看出你的逻辑是否闭环。
⚠️ 常见误区:数据最小化 ≠ 只收集你业务需要的数据。“需要”的定义必须跟处理目的绑定。举个例子:为了客户服务,你需要姓名和订单号,但不一定需要生日。如果你收集了生日却只用来发优惠券,那生日字段就构成“过度收集”。我曾经在审计中遇到一家电商,为了“客户画像”收集了用户12个字段,实际上只用了3个,剩下的全是冗余——罚款点就在这儿。