3. DPIA的法律依据与要求归纳总结
做DPIA，说白了就是给自己画一条安全底线。GDPR第35条到第36条是咱们做DPIA的法律准绳。我刚开始接触GDPR时，总觉得这些法条绕来绕去，后来在医疗数据处理项目中反复比对，才发现它们其实很简单——一件事：哪些场景下你必须要做风险评估，做了之后该怎么处理。
3.1 法律依据在哪里？
GDPR第35条是最核心的。它说：如果你的数据处理活动“可能对自然人的权利和自由产生高风险”，就必须进行DPIA。第36条讲的是，如果DPIA做完后发现风险确实高，又找不到合适的缓解措施，那你要提前咨询监管机构（Supervisory Authority）。
嗯，这里要注意：不是所有处理都需要DPIA。像处理普通员工姓名、电话号码这种低风险场景，压根不用折腾。我在一个电商项目中见过同行对所有数据处理活动都做DPIA，结果团队花了三个月时间，最后被监管机构说“过度合规”——说白了，浪费资源。
| 法条 | 核心要求 | 我的理解 |
|---|---|---|
| GDPR第35条 | 高风险场景必须做DPIA | 这是定责条款，谁做DPIA，谁负责 |
| GDPR第36条 | 高风险无法缓解时，提前咨询监管机构 | 别等出事才找监管，提前打招呼 |
| 第35(7)条 | DPIA必须包含系统描述、必要性、风险评估、缓解措施 | 四要素缺一不可，我见过的合规报告被退回，基本都是要素不全 |
3.2 什么时候必须做DPIA？
我个人习惯按“九宫格”来判断——第29条工作组（WP29）给过一份清单，覆盖了最常见的触发条件。下面这几个场景，你基本逃不掉DPIA：
- 系统化监控：用摄像头追踪客户行为、员工考勤等。我之前处理过一个零售门店的案例，店内装了200多个摄像头并用人脸识别分析顾客情绪——妥妥的高风险，必须做DPIA。
- 大规模处理特殊类别数据：健康数据、生物识别数据、政治观点、宗教信仰等。记住，这里强调“大规模”，不是处理几条记录。
- 系统性评估个人：比如信用评分、贷款审批模型、招聘算法。这类数据对个人有法律效力或类似重大影响。
- 公开区域的大规模监控：商场、机场、体育场馆的视频监控。隐私影响面太广了。
- 跨境数据转移：特别是转移到没有充分性保护水平的国家。
一个小技巧：你可以自己建一个“DPIA触发检查表”。把业务流程中的每个数据处理活动过一遍，只要命中上述任意一条，就果断启动DPIA。记得：不做DPIA的后果可能比做DPIA更麻烦——监管罚款可达1000万欧元或年收入的2%。
3.3 DPIA的硬性要求
GDPR第35(7)条把DPIA的内容写得明明白白。我建议你把它拆成四个模块：
- 系统描述：处理活动的性质、范围、背景、目的。别写得太文艺，用结构化表格最好。
- 必要性评估：你为什么需要这些数据？有没有更少侵扰的方式？我在一个智慧城市项目中遇到过，客户想收集所有市民的实时位置数据来做交通流量优化——其实用匿名化的手机信令数据就够了，根本不需要收集个人数据。
- 风险分析：对个人权利和自由带来的风险，包括隐私风险、歧视风险、名誉损害等。这里建议用ISO 31000风险管理框架来打分。
- 缓解措施：如何降低风险？技术措施（加密、假名化）、组织措施（访问控制、培训）、法律措施（合同约束）。
避坑指南：我曾经见过一个团队写的DPIA，把风险评估写成了“风险很低，没有问题”——被监管机构退回要求重做。记住：DPIA不是走过场，监管机构会仔细看你的风险分析和缓解措施是否合理，别想着糊弄。
3.4 免做DPIA的特殊情形
不是所有高风险场景都一定要做DPIA。GDPR第35(10)条给了三个豁免：
- 法律直接要求：如果某项数据处理是法律明文规定的，而且实施该处理时已经进行过类似的评估，那DPIA就免了。但注意——“法律要求”不是你们公司的内部规定，是国家的法律或欧盟法规。
- 已经做过类似DPIA：如果你的处理活动跟之前评估过的某个DPIA高度相似（同样的数据类型、同样的目的、同样的风险等级），可以直接引用，不用重复做。我建议别偷懒，至少在文档里写清楚引用理由。
- 监管机构已批准：如果监管机构已经明确表示你不需要做DPIA，那你就可以跳过——不过这种情况很少发生。你想想看，监管机构很少主动说“你不用做了”，基本都是反过来催你做。
注意：豁免不是免责。即使你不做DPIA，也需要在文档中记录你为什么豁免。别等到监管来检查时才解释——“我们以为不需要做”这种理由完全不靠谱。
3.5 DPIA的法律流程总结
我们把整个DPIA的法律流程串起来，画張图就清楚了：
3.6 需要记录哪些内容？
DPIA做完了，不是交一份报告就完事。GDPR要求你必须把DPIA的记录作为合规证据保存下来。我个人习惯把DPIA文档归档到数据治理平台里，保留至少5年。下面这个表格列了核心记录项：
| 记录项 | 必须包含的内容 | 我踩过的坑 |
|---|---|---|
| 处理活动描述 | 谁、什么数据、什么目的、什么技术 | 描述得太概括，监管问细节答不上来 |
| 必要性评估 | 为什么必须处理这些数据 | 忽略数据最小化原则，被质疑过度收集 |
| 风险评分 | 风险等级、影响程度、可能性 | 评分标准不统一，当时团队内部吵了三天 |
| 缓解措施 | 技术+组织+法律措施，以及负责人 | 忘写“剩余风险”，被监管指出风险未闭环 |
| 决策结果 | 是否咨询监管机构、是否继续处理 | 签字只有DPO，缺了业务负责人 |
我的建议：每次DPIA结束，让数据保护官（DPO）和业务负责人双方签字。我见过最惨的案例——DPIA报告里只有IT经理签字，监管来了问“业务为什么不清不楚”，结果被认定为合规缺失。签字是责任落实的最后一道锁。
好了，关于第3章的法律依据与要求，我就讲到这里。核心就三点：知道什么场景必须做DPIA，明白DPIA包含哪四个模块，记住DPIA的流程里“可缓解”和“不可缓解”两条路怎么走。把这些记住，DPIA就不只是一张纸了——它是你保护用户数据、也保护公司免于罚款的护身符。