GDPR数据泄露通知：72小时规则详解（2026年）

根据GDPR第33条，只要泄露事件可能对个人造成风险，数据控制者必须在知悉个人数据泄露之日起72小时内通知其监管机构。计时始于控制者对泄露事件的发生具有合理确定性之时，而非调查结束之时。

个人数据泄露一旦发生，计时立即启动。根据GDPR，数据控制者在知悉符合条件的泄露事件后，仅有72小时通知监管机构。错过这一窗口本身即构成独立违规，可能引发重大罚款，而Meta、爱尔兰银行和Permanent TSB的案例表明，各数据保护机构确实会就此追究责任。

《（欧盟）2016/679号条例》第33条和第34条确立了泄露通知框架。EDPB第9/2022号个人数据泄露通知指南（2.0版，2023年4月通过）以及配套的EDPB第01/2021号泄露示例指南提供了各欧盟和欧洲经济区监管机构所采用的权威解释。

本指南将说明什么构成泄露、各项通知义务何时触发、须包含哪些具体内容、"知悉"的含义、处理者的角色、泄露登记册义务、常见误区、执法情况，以及GDPR规则与其他主要框架的比较。

关于更广泛的监管背景，请参见什么是GDPR。关于合规规划，请参见GDPR合规检查清单。关于处罚范围，请参见GDPR罚款与处罚。

本文仅供参考，不构成法律建议。具体情况请咨询具备资质的数据保护律师或隐私专业人员。

快速解答

72小时规则是GDPR第33条第1款的简称。当个人数据泄露发生时，控制者必须在知悉之日起72小时内通知有管辖权的监管机构，除非该泄露不太可能对个人的权利和自由造成风险。

若无法在72小时内完成通知，仍须尽快提交，并附上迟延的合理说明。

第34条项下的另一项独立义务，可能要求控制者也直接通知受影响的个人，但仅限于泄露事件可能造成高风险的情形，这是一个更高的门槛。

什么构成个人数据泄露

GDPR第4条第12款将个人数据泄露定义为"导致所传输、存储或以其他方式处理的个人数据遭到意外或非法销毁、丢失、更改、未经授权披露或访问的安全泄露事件"。

欧洲委员会和EDPB中小企业数据泄露指南围绕保密性／完整性／可用性三元组，将安全事件分为三类。

保密性泄露

未经授权或意外披露或访问个人数据。例如：

• 网络攻击导致客户数据库被入侵
• 员工将个人数据误发给错误的收件人
• 遗失或被盗的笔记本电脑内含未加密的个人数据
• 处理者的系统遭到入侵，暴露了依第28条协议共享给其的数据
• 云存储桶配置错误，导致数据公开可访问

完整性泄露

未经授权或意外地更改个人数据。例如：

• 网络攻击篡改医疗记录
• 软件缺陷破坏薪资数据
• 未经授权的用户擅自编辑客户账户信息

可用性泄露

意外或未经授权地丧失对个人数据的访问权，或个人数据遭到销毁。例如：

• 勒索软件攻击加密数据库且无可用备份
• 服务器故障永久性破坏记录且无法恢复
• 员工意外删除数据集且未建立备份

勒索软件攻击尤为值得关注，因为它可能同时触发全部三种泄露类型：数据被加密属于可用性泄露；若数据在加密前已被窃取，则同时构成保密性泄露；若攻击者拥有写入权限，则完整性也无法得到保证。

ICO关于个人数据泄露的指南强调，泄露不要求存在恶意意图。只要个人数据受到影响，意外丢失、人为失误和系统故障均属泄露范畴。

关于勒索软件与备份的说明：若组织拥有经验证的、干净的备份，并能够迅速恢复数据、对个人不造成持续影响，则由勒索软件引发的可用性泄露可能无需通知。但这一判断必须予以记录，且组织须确认没有数据被窃取。若存在疑问，应予以通知。

72小时规则：向监管机构通知（第33条）

核心义务

第33条第1款要求控制者"毫不迟延地，并在可行的情况下不迟于知悉泄露事件后72小时内"通知有管辖权的监管机构，除非该泄露"不太可能对自然人的权利和自由造成风险"。

该义务由两个要素构成：

第一，速度。通知必须"毫不迟延"，并在可行时于72小时内完成。这是两项独立要求：72小时上限并不意味着如果信息提前准备好，仍可等到第71小时才通知。

第二，门槛。只有可能对个人造成一定风险的泄露事件才触发该义务。确实不太可能影响任何人的泄露事件无需通知监管机构，但仍须在内部予以记录。

通知须包含的内容

第33条第3款规定了四类必须提供的信息：

• 泄露的性质： 受影响数据主体的类别及大概数量；涉及的个人数据记录的类别及大概数量；泄露的发生方式
• 联系人： DPO或其他联系人的姓名和联系方式
• 可能的后果： 描述泄露对受影响个人可能造成的后果
• 已采取的措施： 为应对泄露已采取或拟采取的措施，包括缓解可能产生不利影响的措施

分阶段通知

第33条第4款明确允许分阶段通知。若在72小时内无法获得完整情况，应在该窗口内提交包含当时可获得信息的初步通知，随后随调查进展"毫不迟延地"补充详细信息。

这正是监管机构期望控制者在复杂事件中采用的机制。提交注明"调查仍在进行中"的初步通知，远优于等待获取完整情况而错过72小时期限。

如何通知

EDPB维护着一份各国监管机构泄露通知门户的目录，多数数据保护机构接受通过在线表格提交通知。

在一站式机制下，拥有欧盟主要营业机构的控制者须通知主导监管机构（即控制者主要营业机构所在成员国的数据保护机构）。若泄露主要影响特定成员国内的个人，也可能须一并通知该成员国的机构。

"无风险"例外情形

若泄露"不太可能对自然人的权利和自由造成风险"，则无需通知。EDPB第9/2022号指南指出，这是一项狭窄的例外情形。多数涉及个人数据的泄露确实带有一定风险。当评估结果处于临界状态时，EDPB建议倾向于予以通知。

以下因素可降低风险，可能支持不通知的决定：

• 数据经过完全加密，且加密密钥未被泄露
• 数据本已公开可得，泄露并未造成额外损害
• 泄露事件已被立即控制，未确认存在外部访问
• 涉及的数据类别不敏感，且泄露持续时间短暂

即使决定不通知监管机构，该泄露仍须记入泄露登记册。

计时何时启动："知悉"的含义

72小时计时始于控制者"知悉"泄露事件之时：并非泄露开始之时，也非调查完成之时，更非泄露全部范围明确之时。

EDPB第9/2022号指南将"知悉"界定为"控制者对已发生导致个人数据受到损害的安全事件具有合理确定程度"之时。

实际情形

当入侵检测系统、日志监控或SIEM系统发出泄露警报时，"知悉"始于负责人员审阅并确认该警报表明可能存在泄露之时。仅仅收到无人处理的自动警报，未必构成知悉，但组织应具备合理的响应流程，以确保警报得到及时审阅。

当处理者首先发现泄露并通知控制者时，控制者的知悉时点始于收到处理者通知之时。计时并非从处理者发现事件之时起算，但前提是处理者须及时予以通知。

当外部方（安全研究人员、客户、记者）可信地报告泄露时，控制者的知悉时点始于其收到能使其对泄露发生具有合理确定性的信息之时。

正在进行的、旨在确定泄露全部范围的调查并不会中止计时。控制者必须基于72小时时点已掌握的信息进行通知，并随调查推进补充进一步信息。

常见的"知悉"误区

部分控制者错误地将调查启动时点视为计时起点。这是错误的。钓鱼邮件被打开、凭证遭泄露，或访问日志显示异常活动，均可能在调查完成之前即构成对泄露发生具有充分确定性的证据。

各数据保护机构已因组织在提交泄露通知前先完成调查、从而超出72小时窗口，而对其开出罚款。法国CNIL尤其屡次援引风险评估不充分和通知启动迟延作为反复出现的违规事由。

通知数据主体（第34条）

高风险门槛

第34条第1款要求控制者在泄露"可能对自然人的权利和自由造成高风险"时，"毫不迟延地"将泄露事件告知受影响的数据主体。

高风险门槛明显高于触发监管机构通知的"风险"门槛。并非每一起须向数据保护机构报告的泄露都同样需要个人通知。

EDPB指南指导控制者综合权衡以下因素以评估高风险：

• 数据的敏感度： 健康数据、财务数据、生物识别数据、身份证号码以及涉及儿童的数据带来更高风险
• 数量： 受影响个人数量越多，风险通常越大
• 识别的容易程度： 可轻易与特定个人关联的数据风险更高
• 可能的后果： 身份盗用、经济损失、歧视、名誉损害以及人身安全风险均支持高风险认定
• 受影响个人的特殊特征： 弱势群体（未成年人、患者、遭受家庭暴力的人）面临更大的潜在伤害

通知须包含的内容

向数据主体的通知须传达：

• 以清晰、通俗语言描述泄露的性质
• DPO或其他联系人的姓名和联系方式
• 描述对个人可能造成的后果
• 已采取或拟采取的应对及缓解措施

除非直接逐一通知需要付出不成比例的努力（此时须改为公开通报或采取同等有效的替代措施），通知须直接发送给每位受影响个人。

数据主体通知的三项例外

第34条第3款规定了三种即使存在高风险，也无需进行个人通知的情形：

第一，加密或同等保护措施。控制者已采取适当的技术措施（如加密），使个人数据对任何未经授权者而言不可理解，且这些措施已应用于泄露所涉及的数据。要满足该例外，加密措施必须足够稳健，且密钥未被泄露。

第二，后续缓解措施。控制者已采取后续措施，确保对个人的高风险不再可能发生。例如：凭证已遭泄露，但控制者在发生任何未经授权使用之前已立即将其撤销，且没有证据表明数据被窃取。

第三，不成比例的努力。若逐一识别并直接联系每位受影响个人需要付出不成比例的努力，控制者须改为发布同等有效的公开通报，通常表现为新闻声明、网站通知或社交媒体公告。

处理者的义务（第33条第2款）

数据处理者依第33条第2款负有自身的泄露通知义务。处理者在知悉个人数据泄露后，必须"毫不迟延"通知控制者。

GDPR并未为处理者向控制者的通知设定固定的小时限制。但EDPB第9/2022号指南建议，处理者应力争在自行发现泄露后72小时内通知控制者，因为控制者向监管机构履行72小时义务，实际上依赖于及时收到处理者的通知。

对合同的意义

第28条数据处理协议应明确规定：

• 从处理者到控制者的最长通知时限（常见做法为24小时，72小时为实践中的上限）
• 处理者通知中必须包含的最低限度信息（泄露的性质、受影响数据类别、大概涉及人数、可能的后果、初步控制措施）
• 处理者协助控制者准备监管机构通知及数据主体通信的义务
• 处理者配合监管机构调查的义务
• 升级联系人及非工作时间的处理程序

若处理者未能及时通知控制者，导致控制者错过72小时窗口，处理者本身也可能面临监管审查。EDPB关于处理安全与数据泄露通知的一站式案例摘要（2024年）记录了各数据保护机构在跨境案件中如何处理处理者链条失效的问题。

泄露登记册（第33条第5款）

第33条第5款要求控制者记录所有个人数据泄露事件，无论是否需要通知监管机构。该内部泄露登记册须包括：

• 泄露事件的事实（发生了什么、如何被发现、发生时间及被发现时间）
• 泄露对受影响个人的影响
• 已采取和拟采取的补救措施
• 控制者的风险评估：对个人风险可能性和严重程度的分析
• 通知或不通知监管机构的理由
• 若适用，不通知数据主体的理由
• 已作出的任何通知的详情（日期、内容、接收机构）

泄露登记册须应监管机构要求提供查阅，是证明控制者依GDPR合规管理泄露事件的主要书面证据。在调查和审计中，缺乏适当的登记册本身即被视为一项违规。

登记册应予以安全保存并定期审查。处理大量个人数据的组织应将泄露登记册视为持续更新的动态文件，而非一次性归档。

常见误区

等待调查结束后再通知。 这是最常被引用的错误。计时始于知悉之时，而非调查结束之时。分阶段通知正是为此而设的机制：在72小时内以现有信息提交初步通知，随后再作补充。

将处理者的发现时点视为自身的计时起点。 若处理者在数日前已发现泄露但延迟通知，控制者的72小时计时并不从处理者的发现日期起算。但若处理者的迟延通知导致您错过通知窗口，您和处理者双方都可能面临监管审查。

认为小规模泄露无需记录。 无论多么轻微的泄露，都须记入泄露登记册；有所不同的仅是通知门槛。对低风险事件跳过登记，是审计中会暴露的合规缺口。

风险评估含糊不清。 各监管机构，尤其是法国CNIL，已将风险评估不充分作为独立的违规事由予以引用。仅陈述"我们评估风险为低"而未提供推理依据、数据量、受影响类别和严重程度分析，是不充分的。登记条目必须体现出评估过程。

在存在高风险时未通知数据主体。 当泄露涉及敏感数据且存在切实的身份盗用、经济损害或歧视风险时，控制者有时会错误地认为加密例外适用，或认为风险已得到缓解。若存在疑问，应通知个人。

向监管机构的通知内容不充分。 第33条第3款规定了必须提供的内容。爱尔兰DPC 2024年12月对Meta作出的2.51亿欧元决定，包含一项具体认定，即其泄露通知未包含第33条第3款要求的全部信息，并依第33条第5款单独认定其泄露登记文件不充分。通知内容不完整被视为独立于迟延通知的另一项违规。

执法示例

Meta：2.51亿欧元（爱尔兰DPC，2024年12月）

爱尔兰DPC对Meta开出2.51亿欧元罚款，源于2018年一起泄露事件，攻击者利用Facebook"以他人身份查看"（View As）功能的漏洞，窃取了全球约2900万个账户（其中约300万位于欧盟/欧洲经济区）的访问令牌。该罚款涵盖多项违规：因Meta的通知未包含全部required信息而违反第33条第3款，处以800万欧元；因泄露文件记录不充分而违反第33条第5款，处以300万欧元；因第25条项下系统设计不良，处以1.3亿欧元；以及因未能默认仅处理必要数据，处以1.1亿欧元。

Meta案的意义在于，它表明各数据保护机构不仅会因迟延通知，也会因通知内容不完整而单独开出罚款。

爱尔兰银行：46.3万欧元（爱尔兰DPC，2022年3月14日）

爱尔兰DPC对爱尔兰银行（Bank of Ireland）开出46.3万欧元罚款，源于对2018年11月至2019年6月期间提交的22起泄露通知展开的调查。DPC认定其中19起事件构成个人数据泄露。其中一起泄露事件影响了约47,000名数据主体，而爱尔兰银行最初的通知仅称受影响者为一人。DPC认定爱尔兰银行未能毫不迟延地报告泄露事件，违反了第33条第1款：在多起案件中，泄露虽已在内部被发现，但延迟九天以上才上报DPO，使通知远远超出72小时窗口。

Permanent TSB：27.75万欧元（爱尔兰DPC，2026年5月）

爱尔兰DPC对Permanent TSB开出27.75万欧元罚款，源于对自2022年5月起报告的个人数据泄露事件展开的调查。相关泄露源于恶意人员致电该银行的Open24客服中心，冒充客户并利用部分客户信息访问和篡改账户信息。其中2.75万欧元罚款专门针对第33条第1款违规：PTSB未能在知悉泄露事件后72小时内通知DPC。另有25万欧元罚款是针对相关的第5条和第32条违规而作出的。

Booking.com：47.5万欧元（荷兰DPA，2021年）

荷兰DPA对Booking.com开出47.5万欧元罚款，原因是该公司在知悉一起泄露事件（涉及超过4000名客户的财务信息和护照详情等个人数据）后22天才通知DPA。该迟延被认定为独立的第33条第1款违规。该案至今仍是各国数据保护机构就何为不可接受的通知延迟提供指引时的重要参考案例。

泄露通知的国际对比：与其他司法辖区的比较

GDPR的72小时规则是全球最为严格的泄露通知时限之一。以下为高层次对比：

与NIS2的重叠。 NIS2指令要求所有欧盟成员国须在2024年10月前完成转化，对基本实体和重要实体发生的重大网络安全事件，规定了独立的24小时早期预警加72小时完整通知，须提交国家CSIRT或有管辖权的机构。同时受GDPR和NIS2约束的组织，可能须就同一事件分别通知两个不同机构：依GDPR第33条通知监管机构（数据保护机构），以及依NIS2通知有管辖权的机构或CSIRT。两套制度的门槛和所需内容各不相同。

泄露应对基础设施

妥善应对泄露事件的组织，通常在任何事件发生之前就已建立以下机制。

检测能力。 若没有快速检测泄露的技术能力，泄露通知义务便无从实现。入侵检测系统、SIEM工具、终端监控和异常检测应能生成可操作的警报，并在事件发生后数小时内送达相关人员。

指定的响应团队。 在事件发生前预先指定各项角色：事件协调员、IT／安全负责人、法务或DPO联系人、传播负责人以及高管升级联系人。每个人都应清楚自己的职责，并可在非工作时间被联系到。

风险评估框架。 预先批准的评分模板（涵盖数据类别、受影响人数、损害可能性和严重程度）可使团队快速、一致地完成第33条和第34条的门槛评估。这一阶段的速度直接决定能否赶上72小时窗口。

通知模板。 针对最常见的泄露场景（凭证被盗、设备丢失、系统被入侵、意外披露），在事件发生前预先起草监管机构通知表格和数据主体信函。预先批准的模板可在响应过程中节省关键时间。

处理者程序。 确认您的主要处理者已建立有记录的泄露检测和通知程序，其合同中已明确通知时限，并且您已掌握非工作时间的升级联系方式。

经过测试的泄露登记册。 登记册格式应事先确立，并为负责填写的人员所熟悉。未经测试的登记册往往在监管机构调查期间才暴露出漏洞。

桌面演练。 每年至少开展一次情景演练，从检测走到评估、通知和补救的全过程，识别流程中的薄弱环节。

通知时间线参考

更多GDPR指南

• 什么是GDPR：该条例的全面概述
• GDPR合规检查清单：分步骤合规指南
• GDPR罚款与处罚：执法数据与处罚结构
• GDPR数据主体权利：全部八项个人权利
• GDPR同意要求：有效同意标准
• 面向中小企业的GDPR：中小企业专项指南
• 欧盟数据隐私法律：欧盟数据保护完整概览