文/麻策
2026年6月8日，欧洲数据保护委员会（EDPB）正式通过了新版数据泄露通报模板（Template [2026] for personal data breach notification），并启动公开征求意见程序（截止2026年8月5日）。
这份长达30页的模板，将GDPR第33条和第34条下的通报义务，首次转化为一套统一的、结构化的操作表单。从泄露的分类（保密性/完整性/可用性）、风险等级的逐项评估、到数据主体告知的触发条件，模板的每一个字段背后，都是监管机关多年来执法实践的沉淀，也体现了监管为企业减负的考量。
隐私和网络安全等多个领域对达到相关阈值的组织规定了数据泄露通知义务。虽然全球范围内的要求各不相同，但立法通常会规定：何时需要通知、以何种格式、向谁通知、在什么时间范围内通知，并详细说明通知中应包含的内容。
本文基于该模板、EDPB指南9/2022（数据泄露通报一般指南）、EDPB指南01/2021（数据泄露通报示例）及主要成员国数据保护机关的实务指引，同时结合近年来因违反通报义务而被处罚的典型案例、欧盟法院的相关判例及行业统计数据，以及我们日常服务客户处理类似泄露事件的经验，梳理出中国企业在欧盟运营中最常遇到的十个数据泄露通报问题。
一、什么是GDPR意义上的"个人数据泄露"？
这是所有通报义务的起点，也是企业最为关注的重点，毕竟大部分中国企业的心态是——尽量不麻烦政府，尽量给自己一个默默自我改过自新的机会。
GDPR第4条第12款将"个人数据泄露"定义为"导致意外或非法损毁、丢失、更改、未经授权披露或访问所传输、存储或以其他方式处理的个人数据的安全事件"。这一定义涵盖了三大类型：保密性泄露（未经授权披露或访问）、完整性泄露（未经授权更改数据）和可用性泄露（个人数据因意外或未经授权而无法访问或遭到破坏，比如设备丢失或被盗，或唯一一份个人数据集被勒索软件加密）。EDPB新版模板第55行将这三类明确列为互不排斥的勾选项，实务中一个泄露事件可能同时触发多个类型。
需要注意的是，和中国数据泄露认定逻辑一致，保密性泄露也包括“个人数据很可能（指“likely”）已被泄露或披露（无证据）”的情况。即，即使无证据证实相关数据已经流出控制范围，但只要有类似于非授权访问的日志记录，也将被视为“目视”范围下的泄露。
另外，值得特别注意的是"可用性泄露"的认定边界。模板第59行区分了"临时性可用性问题"与"永久性可用性问题"，并要求从数据主体的视角评估。EDPB指南9/2022第26段明确指出，即使是短暂的拒绝服务，如果对个人的权利和自由产生影响，也应被视为可通报的泄露。
从全球趋势看，数据泄露事件的规模正在急剧膨胀：根据DLA Piper发布的2026年1月GDPR执法与数据泄露调查报告，2025年全年欧盟成员国日均通报数据泄露事件443起，较上年增长22%，较GDPR施行初期的2019年（日均约250起）已接近翻倍。以韩国为例，2026 年 5 月 15 日，个人信息保护委员会 (PIPC) 与韩国互联网振兴院 (KISA) 发布了一份报告，分析了 2025 年度个人信息泄露通知、调查及处置情况。报告显示，2025年共提交了447份泄露通知，较前一年增加了45.6%。黑客攻击占这些事件的62%，其次是专业过失占25%，系统错误占5%。
二、什么情况下必须向监管机关通报？
GDPR第33条第1款的规定常被简化为"72小时通报"，但其核心义务实际是：只要个人数据泄露"不太可能对自然人的权利和自由造成风险"，就不需要通报监管机关。换言之，一旦存在风险可能性（无论风险高低），通报义务即被触发。这是一个极低的门槛——EDPB指南9/2022第37段强调，控制者"应能够向监管机关证明"其不通报决定的合理性，举证责任在控制者一方。
实践中，以下情形通常被认为存在风险从而必须通报：泄露涉及特殊类别数据（如健康数据、生物识别数据）；泄露涉及大量数据主体或大量数据记录；泄露数据可结合其他信息识别特定个人；泄露可能导致身份盗用、欺诈、歧视或声誉损害。模板第89行要求控制者明确选择风险等级的评估结果——"高风险""非高风险的风险"或"不太可能有风险"——这正是对GDPR两步通报义务（向监管通报与向数据主体通报）的直接映射。控制者只有在确认"不太可能有风险"时才能豁免向监管的通报义务，而这一判断必须有据可查。
从总体上来看，在判断逻辑上，我们认为只要符合泄露的定义，则应当原则为通报，并不存在过多的不通报空间——唯一的区别，在于当地执法的执着度，有些地区的监管只是选择性执法。
通报实务现状：从"要不要报"到"怎么报"
了解了通报义务的法律标准之后，一个自然的问题是：现实中到底有多少企业在执行？根据DLA Piper GDPR执法与数据泄露调查（2026年1月出版）的数据，截至2025年底，自GDPR生效以来整个欧洲经济区已累计通报超过120万起个人数据泄露事件。其中，荷兰（33,471起）、德国（27,829起）和波兰位列成员国前三。日均通报量从2019年的约250起增长至2025年的443起，年复合增长率超过10%，且增速呈加快趋势——2025年同比增长22%，是GDPR施行以来增幅最大的一年。
这一增长背后至少有三个驱动因素：其一，监管执法力度持续加大——GDPR罚款总额自2018年以来已累计超过71亿欧元，仅2025年一年即开出约12亿欧元罚单；其二，企业合规意识提升，越来越多的控制者从"被动应查"转向"主动通报"；其三，网络攻击的频率和复杂程度显著上升，勒索软件和供应链攻击已成为泄露的主要来源。这意味着，"要不要通报"已不再是大多数企业的纠结所在——实务焦点已经转移到"如何在72小时内完成一份经得起监管审查的通报"。
三、什么情况下必须向数据主体通报？
向数据主体通报的门槛高于向监管通报。GDPR第34条第1款规定，只有当个人数据泄露"可能对自然人的权利和自由造成高风险"时，控制者才有义务"无不正当延迟"地告知数据主体。这里的关键词是"高风险"——仅仅是风险存在（即触发第33条通报监管的门槛）尚不足以触发第34条。EDPB指南认为，向监管执行通知的根据目的是为了保护个人权利，监管通知后，控制者还可以获得关于是否需要告知受影响个人的建议。因此，数据泄露通知应被视为增强个人数据保护合规性的工具。
EDPB指南01/2021通过大量示例说明了这一区分：例如，一家医院向错误收件人发送了一份包含一名患者常规检查结果的电子邮件，可能构成须向监管通报的泄露（存在风险），但由于仅涉及一名数据主体且数据类型敏感度有限，未必达到"高风险"从而无需向该患者单独通报。而同一家医院如果将数千名患者的HIV检测结果意外公开在网站上，则显然构成高风险，必须逐一通知受影响的数据主体。模板第87行要求控制者对潜在影响进行严重性自评（轻微/中等/严重），这一自评结果直接决定了数据主体告知的必要性。
四、什么情况下无须通报？——三大豁免情形的实务边界
GDPR第34条第3款规定了数据主体告知的三项豁免，但实务中对这三项豁免的误用极为普遍，有必要逐一辨析。
第一项豁免：控制者已采取适当的技术和组织保护措施，且这些措施已适用于受泄露影响的个人数据，"特别是使数据对于未获授权者不可理解"的措施，如加密。这里的关键词是"已适用于"——仅仅有加密政策是不够的，必须在泄露发生时该特定数据已处于加密状态。EDPB模板第57行对此进行了细化，要求控制者确认"数据是否对于未获授权者不可理解"，并区分了四种情形："是的且保护仍有效""已采取措施但可能被攻破""否"和"无法评估"。如果选择"已采取措施但可能被攻破"（例如加密密钥也同时泄露），则不能援引此项豁免。
第二项豁免：控制者已采取后续措施，确保高风险不再可能实现。例如，在误发邮件后立即远程撤回、在发布错误数据后立即删除并清除缓存。但注意，此项豁免要求"确保"风险不再可能实现，而非仅仅是"降低了"风险，实务门槛较高。第三项豁免：逐一通知将涉及"不成比例的努力"。在此情形下，控制者应以公告方式替代，例如在官方网站显著位置发布通知或通过媒体发布——效果须等同于个别通知。EDPB指南9/2022第122段特别指出，"不成比例的努力"不能仅仅因为数据主体数量庞大而自动成立，须有具体证据支持。
五、72小时倒计时从何时起算？——"知悉"的认定
GDPR第33条规定的"72小时内"以控制者"知悉"（aware）泄露为起算点，而非泄露发生之时。EDPB指南9/2022第47段将"知悉"定义为"控制者具有合理程度的确定性，认为发生了导致个人数据泄露的安全事件"。换言之，仅凭可疑迹象或初步警报尚不足以起算72小时；但一旦IT安全团队确认入侵、或在日志中发现未授权访问的证据，"知悉"即告成立——不能以"调查尚未完成"为由拖延。
实务中争议最大的场景是处理者先于控制者知悉泄露。EDPB明确，处理者一旦发现泄露，有义务"无不正当延迟"地通知控制者（GDPR第33条第2款），而控制者的72小时从收到该通知时起算。但控制者不能通过合同条款将处理者的通知义务设定得过长来变相延后自己的起算点——GDPR第28条第3款（f）项明确要求处理者"立即"通知控制者。
新版模板第48行要求填写"控制者知悉泄露的日期和时间"，第49行则在"知悉时间加72小时超出当前时间"时自动显示"逾期通报理由"字段。这意味着监管机关将以系统自动校验的方式判断是否超期，企业必须在通报时准备好逾期理由。
违反通报义务的代价：执法案例与司法判例
理解通报义务的法律标准是一回事，衡量违反这些标准的实际后果是另一回事。过去几年中，欧盟监管机关和法院通过一系列标志性案件，清晰界定了通报义务违反的法律后果。其中最具代表性的案例是爱尔兰数据保护委员会（DPC）2020年12月对Twitter处以的45万欧元罚款——这是GDPR生效后首例因违反第33条和第34条通报义务而作出的跨境执法决定。
在该案中，Twitter的一名员工将内部安全漏洞报告错误标记为"不需要修复"，导致公司在发现该漏洞后未能遵守72小时内通报监管机关的义务——DPC认定其违反了GDPR第33条第1款和第33条第5款，尽管罚款金额相对于GDPR的法定上限（全球年营业额的4%）看似不高，但这一决定的意义在于：它确立了"通报义务具有独立于基础泄露的合规价值"——即使基础安全漏洞本身未造成实际损害，通报延迟本身即构成可处罚的独立违规。
在司法层面，欧盟法院（CJEU）2024年9月在TR诉黑森州案（C-768/21）中作出了一个重要裁决：当个人数据泄露被确认后，监管机关并非在所有情形下都有义务行使纠正性权力（包括处以罚款）——监管机关享有一定的裁量空间。CJEU指出，"GDPR第58条第2款的措辞并未设定监管机关在任何情况下都必须行使纠正性权力的义务"。但法院同时强调，这一裁量权不减免控制者的通报义务本身——即便监管机关可能选择不处罚，控制者仍需依法在72小时内通报。该判决的实务意义在于：不能因为"监管机关可能不会追究"而放弃或延迟通报，因为通报义务是一个独立的法律义务，不以处罚可能性为条件。
从执法趋势看，CMS GDPR Enforcement Tracker的数据显示，与安全措施和泄露通报相关的罚款占比约15-20%。值得注意的是，罚款金额呈加速增长态势——2025年全年罚款总额约12亿欧元，接近GDPR施行前六年总和的一半。监管机关的执法关注点也在从"有无通报"逐渐转向"通报的质量、完整性和及时性"，这与EDPB推出新版统一通报模板的方向完全一致。
六、分阶段通报怎么做？——"不完整通报"的机制
72小时内无法提供全部信息是常见情形。GDPR第33条第4款明确允许分阶段通报：先提交初步信息（不完整通报），随后在合理期限内补充完整。EDPB模板第4行将此机制化为一个简单的下拉选项：通报人可在"完整""不完整"和"撤回"中选择。选择"不完整"后，模板中多个字段会出现"待确定"勾选项，供控制者明确标注哪些信息尚在调查中。
这一机制在涉及复杂网络安全事件的场景中尤为重要。例如，遭受APT攻击后，控制者可能在72小时内仅能确认攻击方式和大致的受影响范围，但无法给出精确的数据主体数量或全部数据类型的完整清单。此时应先以"不完整"状态提交通报，然后在后续补充通报中更新这些字段。EDPB指南9/2022第63段特别强调，不得以调查仍在进行为由整体推迟通报——分阶段机制正是为了在"及时通报"和"信息准确性"之间取得平衡。
七、跨境泄露如何确定"牵头监管机关"？
当泄露涉及跨境处理时，"一站式机制"决定向哪个监管机关报送。GDPR第56条规定，由控制者主要营业机构所在地的监管机关作为"牵头监管机关"，但控制者仍须向受影响数据主体所在的所有成员国的监管机关通报。EDPB模板第113至118行专门设计了跨境处理模块：控制者需逐一勾选受影响的数据主体所在成员国、各成员国受影响人数估算值、并列出已通报或将通报的各成员国监管机关。
模板第117行要求按成员国分别给出受影响数据主体的"大致数量"，这是EDPB模板首次将跨境维度的数据颗粒度要求写入统一通报格式。对于总部设在欧盟境外但适用GDPR第三条域外适用的控制者而言，模板第119至123行提供了完全独立的非EEA控制者模块，同样要求逐国列出受影响数据主体所在国和对应监管机关。这意味着中国出海企业在欧盟多个成员国拥有用户时，不能再以"数据总量"一笔带过，而必须按成员国维度逐项填写——这对数据管理能力提出了更高的要求。
八、处理者的通报义务与责任边界在哪里？
GDPR第33条第2款规定，处理者在发现个人数据泄露后，应"无不正当延迟"地通知控制者。这一义务是唯一的、直接的法定要求——处理者本身并不直接向监管机关或数据主体承担通报义务。但这不意味着处理者可以免责。EDPB指南9/2022第98段明确指出，控制者与处理者之间的合同应事先约定：处理者协助控制者履行通报义务的具体方式、时间框架和提供信息的范围。如果控制者因处理者未及时通知而错过72小时期限，控制者仍须向监管机关承担逾期责任，但可依据合同向处理者追偿。
新版模板第38至41行专门设置了"其他参与方"模块，要求控制者说明是否有处理者或联合控制者卷入泄露事件，并逐一填写其角色、名称和联系方式。监管机关在收到通报时将直接看到供应链中的责任主体，从而可能在后续执法中一并追责。中国企业在作为数据处理者向欧盟客户提供服务时，应在合同中明确约定义务边界和提供信息的时限，避免因信息传递延迟而承担合同违约责任。
九、风险评估怎么做？——模板中的方法论要求
纵观EDPB模板全文，"风险评估"是贯穿始终的核心线索。模板第89行要求控制者给出风险评估的结论性判断（高风险、非高风险的风险或不太可能有风险），而第90行则进一步要求"描述所使用的方法论和纳入考量的相关因素"。这意味着监管机关不再满足于一个简单的结论，而是期望看到控制者的评估过程——采用了什么框架（如ENISA的网络安全事件评估方法、ISO 27005等）、考虑了哪些因素、得出了什么结论。
EDPB指南01/2021附录A提供了一份风险评估方法论参考，列出了应考量的七个维度：泄露类型；个人数据的性质、敏感程度和数量；识别数据主体的难易程度；对数据主体的后果严重程度；数据主体的特殊特征（如涉及儿童、患者等弱势群体）；受影响数据主体的数量；以及控制者或处理者的特征。模板将这些维度全部转化为具体的表单字段：第65行数据主体类别、第70行泄露数据类型、第86行潜在影响的严重程度。实务建议是，企业应在泄露发生前就建立好风险评估矩阵，而不是每次发生泄露时从零开始。
十、泄露记录与文档留存的合规要求
即使决定不向监管通报，GDPR第33条第5款仍要求控制者记录所有个人数据泄露事件，包括与泄露相关的事实、其影响和已采取的补救措施。这份内部记录必须足以使监管机关验证控制者"不通报"决定的合规性。EDPB指南9/2022第140段指出，监管机关检查时若发现记录不完整或无法支持不通报决定，可能构成GDPR第83条项下处罚的依据——不通报可能本来就违法，而不完整记录则构成独立的违规行为。
EDPB模板的附件模块（第125至126行）进一步明确了建议提交的佐证材料清单，包括：数据主体告知函副本、风险评估报告、网络安全事件调查报告、勒索软件勒索信、钓鱼邮件、内部通报程序、数据销毁政策、向错误收件人发送的原函副本以及第三方通报函等。虽然模板将这些标注为"可选"字段，但在监管执法实践中，缺乏这些客观证据往往导致控制者的风险评估结论被质疑。一个常见陷阱是：企业认为"数据已加密"所以无风险，但未保留加密状态的技术证据；在监管调查时无法证明加密措施当时确实有效，从而被认定通报义务未被适当豁免。
及时通报能否减轻处罚？——通报作为合规减责因素
这是实务中企业最关心的问题之一。GDPR第83条第2款明确列举了监管机关在决定是否处以罚款以及确定罚款金额时"应适当考虑"的十项因素，其中第（f）项即为"控制者或处理者与监管机关的合作程度，以纠正违规行为并减轻其可能的不利影响"。及时、完整地履行第33条和第34条项下的通报义务，正是"与监管机关合作"最直接、最重要的体现形式之一。
EDPB在《关于计算行政罚款的指南》（Guidelines 04/2022）中进一步将其操作化：控制者在泄露发生后是否"立即主动"采取了通报行动，是否在通报中如实、完整地提供了全部已知信息，以及是否在后续调查中积极配合监管机关——这三项因素直接影响罚款金额的计算。以Twitter案为例，DPC在决定罚款金额时明确将Twitter"在调查过程中提供的合作"作为降低罚款的一个考量因素——尽管最终仍处以45万欧元罚款，但如果缺乏合作，罚款金额可能会显著提高。
反过来，延迟通报或不通报不仅构成独立的违规行为，还会在监管机关评估整体合规状况时产生"负面叠加效应"——一个未能及时通报泄露的控制者，在监管机关眼中往往也是一个安全管理体系存在缺陷的控制者。这种判断可能触发更广泛的安全措施审计（GDPR第32条），从而导致额外处罚。因此，对中国企业而言，将"72小时通报"视为一项合规义务而非一项负担，并在组织内部建立标准化的事件响应和通报流程，不仅是避免罚款的需要，更是在发生泄露时控制法律风险、维护监管信用的最优策略。
声明：本文来自麻策的备忘录，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
