欧盟官方EDPB模板分析欧洲数据保护委员会 (EDPB) 的数据保护影响评估 (DPIA) 模板正在公开征求意见（截止时间：2026 年 6 月 9 日），公开征求意见结束后，该模板将最终定稿（并进行必要的修改）。针对欧盟官方发布的这份DPIA模板，我们可以先进行分析，以便指导我们DPIA的开展。
参考该DPIA模板，我们可以理解：模板把 GDPR 中比较抽象的 DPIA、问责、合法性、最小化、数据主体权利、安全、事前咨询等要求，拆成一个可填写、可评审、可留证据的合规工作底稿。它要求企业证明：处理有合法依据，目的明确，数据必要，默认最小，权利可行使，安全措施有效，风险已识别和降低，DPO/相关方已参与，剩余风险可接受。
DPIA模板目录分七部分，分别为：0 处理概览、1 处理的系统性描述、2 处理分析、3 必要性与比例性、4 风险评估与管理、5 相关方参与、6 结论与决策。模板将GDPR原文条款进行了落地，涉及条款主要有：GDPR 第 5、6、7、9、12–22、24、25、28、30、32、35、36、39、V 章等要求。GDPR 第 35 条要求：当某类处理，特别是使用新技术并结合处理的性质、范围、背景和目的，可能对自然人的权利和自由造成高风险时，控制者应在处理前进行 DPIA；DPIA 至少应包含处理操作和目的的系统性描述、必要性和比例性评估、对数据主体权利自由风险的评估，以及拟采取的保障措施、安全措施和合规证明机制。# 0. Overview of the processing：处理概览这一部分主要落地 GDPR 的 “Article 24 控制者责任、Article 26 共同控制者、Article 27 欧盟代表、Article 37–39 DPO、Article 30 处理活动记录”。模板先要求确认“谁决定处理目的和方式”，因为 DPIA 的责任主体是 controller，而不是算法团队、供应商或业务部门。## 0.2 Processor(s) and sub-processor(s)：处理者和分处理者这部分对应 GDPR **Article 28 处理者要求**。GDPR 第 28 条要求控制者只能使用能提供充分保障的处理者，并通过合同或其他法律文件约束处理者的处理标的、期限、性质、目的、数据类型、数据主体类别及双方义务。模板把这个要求落成“列清楚谁处理、处理什么、承担什么任务”的表格。## 0.3 Name of the processing：处理名称这部分主要落地 **Article 30 处理活动记录** 和 **Article 24 问责原则**。GDPR 要求组织能证明合规，DPIA 不能是孤立文件，而应能和 RoPA、系统设计文档、隐私政策、合同、数据流图相互对应。## 0.4 Planning of the processing：处理计划这部分对应 GDPR 第 35 条“prior to the processing”的要求，即 DPIA 应在处理前完成，而不是上线后补文档；也与 Article 5 的 storage limitation、Article 25 的默认保护、Article 35(11) 的风险变化后复审相关。GDPR 第 35(11) 要求，在必要时，特别是处理操作风险发生变化时，控制者应复审处理是否仍按 DPIA 执行。## 0.5 DPIA technical sheet：DPIA 技术表模板把 DPIA 触发原因分成几类。第一类是 **Article 35(3) 下高度可能强制 DPIA 的处理**，包括：基于自动处理的系统性和广泛个人评价并产生法律或类似重大影响、大规模处理 Article 9 特殊类别数据或 Article 10 犯罪数据、大规模系统性监控公共可访问区域。第二类是成员国法律要求的高风险处理。第三类是按照 EDPB 或国家指南可能高风险的处理，例如评价或评分、自动化决策、系统性监控、敏感或高度个人化数据、大规模处理、数据集匹配、弱势数据主体、创新技术，以及处理本身阻止数据主体行使权利或使用服务/合同。# 1. Systematic description of the processing：处理的系统性描述GDPR 第 35(7)(a) 要求 DPIA 包含对拟议处理操作和处理目的的系统性描述；模板第 1 章就是对这个要求的展开。## 1.1 High-level description of the processing：处理的高层描述### 1.1.a Processed personal data：被处理的个人数据这部分对应 **Article 9 特殊类别数据**。GDPR 第 9(1) 规定，处理揭示种族或族裔、政治观点、宗教或哲学信仰、工会成员身份的数据，以及基因数据、用于唯一识别自然人的生物识别数据、健康数据、性生活或性取向数据原则上被禁止，除非符合第 9(2) 的例外。### 1.1.b Purposes of the processing：处理目的这部分对应 GDPR **Article 5(1)(b) 目的限制** 和 **Article 6 合法性基础**。GDPR 第 5 条要求个人数据应为具体、明确、合法的目的收集，不得以与这些目的不相容的方式进一步处理。### 1.1.c Secondary or compatible uses：二次用途或兼容用途这部分对应 **Article 5(1)(b) 目的限制** 和 **Article 6(4) 兼容性评估**。GDPR 第 6(4) 要求，在处理目的与最初收集目的不同且不基于同意或欧盟/成员国法律时，控制者应考虑目的之间的联系、收集背景、数据性质、对数据主体的可能后果以及加密或假名化等保障措施。### 1.1.d Nature, scope and context of the processing：处理性质、范围和背景这部分对应 GDPR 第 35 条中“nature, scope, context and purposes”的高风险判断，以及 Article 30 记录义务和 GDPR 第 V 章国际传输规则。GDPR 第 35(1) 本身就是要求结合处理性质、范围、背景和目的判断是否可能造成高风险。## 1.2 Functional description：功能描述这部分落地 GDPR 第 35(7)(a) 的“处理操作系统性描述”，同时为 Article 5 数据最小化、存储限制、Article 32 安全处理、Article 30 处理记录提供数据流基础。## 1.3 Means of processing, supporting assets and underlying architecture：处理手段、支撑资产和底层架构这部分对应 **Article 25 数据保护设计和默认保护**、**Article 32 安全处理**，也支撑 Article 35(7)(d) 中“拟采取的保障措施、安全措施和合规证明机制”。## 1.4 Compliance with approved codes of conduct：符合经批准的行为准则GDPR 第 35(8) 明确要求，在评估处理操作影响时，应适当考虑相关控制者或处理者是否遵守 Article 40 下经批准的行为准则。# 2. Analysis of the processing：处理分析第 2 章是模板的合规核心：先判断合法性，再判断最小化、保存、数据质量，最后说明具体保障措施。## 2.1 Lawfulness of the processing：处理合法性### 2.1.a Legal basis：合法依据GDPR 第 6(1) 规定，个人数据处理只有在至少满足六类合法依据之一时才是合法的，包括同意、合同必要、法律义务、重大利益、公共利益/公权力、合法利益。### 2.1.b Reasons to lift the processing prohibition：解除特殊类别数据处理禁止的理由GDPR 第 9(1) 原则上禁止处理特殊类别数据；第 9(2) 列明例外，例如明示同意、就业和社会保障义务、重大利益、已明显公开、法律主张、重大公共利益、医疗卫生、公共卫生、公共利益归档/科研/统计等。## 2.2 Data minimisation, retention periods, and data quality：数据最小化、保存期限和数据质量### 2.2.a Data minimisation and retention periods：数据最小化和保存期限这部分落地 GDPR **Article 5(1)(c) 数据最小化** 和 **Article 5(1)(e) 存储限制**。GDPR 第 5 条要求个人数据应充分、相关并限于目的所必要，且识别状态保存不得超过目的所必要的时间。### 2.2.b Data quality：数据质量这部分对应 GDPR **Article 5(1)(d) 准确性原则**。准确性不仅意味着“数据字段无误”，也意味着用于实现目的的数据质量足够可靠。## 2.3 Measures supporting compliance：支持合规的措施这一节把 GDPR 原则和权利转化为“措施清单 + 适当性/有效性讨论 + 实施状态”。### 2.3.a Measures supporting compliance with principles in Article 5(1)(a-f) GDPRGDPR 第 5 条规定了合法、公平、透明；目的限制；数据最小化；准确性；存储限制；完整性和保密性；并要求控制者负责并能证明符合这些原则，即 accountability。### 2.3.b Measures supporting the exercise of data subjects’ rights这部分落地 GDPR 第三章数据主体权利。模板不是要求简单复制隐私政策，而是要求说明每项权利如何在系统和流程中实现。### 2.3.c Measures supporting compliance with other GDPR requirements1. 如果依赖同意，要证明同意如何取得、记录、撤回；2. 如果有供应商，要证明处理者协议和分处理者管理；3. 如果跨境传输，要证明符合 GDPR 第 V 章。### 2.3.d Measures supporting data protection by design and by defaultGDPR 第 25 条要求控制者在确定处理方式时以及处理过程中实施适当技术和组织措施，例如假名化，以有效落实数据最小化等原则，并把保障嵌入处理之中；同时，默认情况下只处理每个特定目的所必要的个人数据，涵盖数据量、处理范围、保存期限和可访问性。### 2.3.e Measures supporting security of processingGDPR 第 32 条要求控制者和处理者根据技术水平、实施成本、处理性质/范围/背景/目的以及风险，采取适当技术和组织措施，包括假名化和加密、持续保障保密性/完整性/可用性/弹性、事件后及时恢复能力，以及定期测试评估安全措施有效性的流程。# 3. Considerations on necessity and proportionality：必要性与比例性考虑GDPR 第 35(7)(b) 明确要求 DPIA 包含“相对于处理目的而言的必要性和比例性评估”。模板第 3 章将其单独作为一个章节，而不是放在合法依据下面，这一点非常重要。## 3.1 Impacts of the processing on the rights and freedoms of data subjects## 3.2 Assess the necessity of the processing这部分对应 Article 35(7)(b)、Article 5 数据最小化，以及 Article 6 中多个合法依据都包含的“necessary”要求。## 3.3 Assess the proportionality of the processing这仍然是 Article 35(7)(b) 的要求，也体现 GDPR 以风险为基础、兼顾权利和合法目的的逻辑。# 4. Risk assessment and management：风险评估与管理第 4 章把前面识别的影响转成正式风险管理流程：固有风险、缓解措施、剩余风险和行动计划。## 4.1 Risk assessment and management模板第 4.1.a 要求评估由 **non-default, accidental, unlawful, or abnormal events** 导致的数据主体权利和自由影响。第 4.1.b 要求说明风险评估方法，包括可能性、严重性、风险水平、风险是否可接受。第 4.1.c 要求进行固有风险评估。这部分对应 GDPR 第 35(7)(c) 对风险评估的要求，以及 Article 24、25、32 的风险导向合规义务。GDPR 第 32 条也要求根据处理风险的可能性和严重性实施适当安全措施。### 4.2.a Additional mitigating measures### 4.2.b Residual risk assessment这一节让 DPIA 从“评估报告”变成“整改闭环”。如果 DPIA 发现风险，但没有行动计划、责任人、期限、验收标准，就不能算风险真正被管理。# 5. Involvement of interested parties：相关方参与GDPR 第 35(2) 要求控制者在进行 DPIA 时征求 DPO 的意见；Article 39 也将“就 DPIA 提供建议并监督其执行”列为 DPO 的任务。## 5.2 Views of data subjects or their representatives：数据主体或代表意见GDPR 第 35(9) 要求，在适当情况下，控制者应就拟议处理征求数据主体或其代表的意见，但不影响商业或公共利益保护以及处理安全。# 6. Conclusion and decision：结论与决策2. **Consultation**：向 supervisory authority 咨询；4. **Conditionally approved**：满足特定条件后方可处理。模板还要求说明是否需要咨询监管机构，尤其是在控制者无法找到足够措施将风险降至可接受水平、剩余风险仍高且不愿放弃处理时，或成员国法律要求事前咨询/授权时。这部分对应 **Article 36 事前咨询**。GDPR 第 36 条规定，如果 Article 35 下的 DPIA 表明，在控制者未采取措施缓解风险时，处理仍会导致高风险，控制者应在处理前咨询监管机构；咨询时应提供控制者/共同控制者/处理者职责、处理目的和方式、保护数据主体权利自由的措施、DPO 联系方式、DPIA 以及监管机构要求的其他信息。上述参考欧盟委员会官方公布的DPIA模板，链接见：https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2026/edpb-dpia-template_en。
官方链接给出了DPIA模板的文本和说明文件，均可以进行下载。如需要原文文本，可留言联系。
夜雨聆风
