各项法规的事件报告截止期限

这个问题没有统一的答案，因为报告时限由约束您的法规决定，而不是由事件本身决定。欧盟规则体系中最短的首个截止期限，是欧盟《数字运营韧性法案》（DORA）规定的 4 小时，而且它从您将事件归类为重大事件时开始计算，而不是从您发现事件时开始。欧盟 NIS2 指令和欧盟《网络弹性法案》（CRA）都要求在 24 小时内发出早期预警。欧盟《通用数据保护条例》（GDPR）给您 72 小时。欧盟《人工智能法案》（EU AI Act）则有违直觉，根据事件造成的后果，给您 2 至 15 天不等的时间。

大多数组织同时受其中不止一项法规约束，而各项时限从不同的起点并行计算。一家支付公司如果遭受勒索软件攻击，同时客户记录也遭泄露，就会同时受 DORA 时限和 GDPR 时限约束，需要以两种不同的格式向两个不同的主管机关报告。

您有多长时间来报告事件？

从 4 小时到 15 天不等，而坦率的答案是：您必须先知道适用哪项法规，这个数字才有意义。决定因素有三个。

第一是发生了什么。个人数据泄露会触发 GDPR，影响受监管服务的事件会触发 NIS2 或 DORA，高风险 AI 系统发生故障会触发 EU AI Act，而您所制造产品中的漏洞会触发 CRA。现实中的一次服务中断，可能同时属于其中几种情形。

第二是由什么启动计时。大多数制度从您知悉之时开始计时；DORA 则从归类之时开始计时，并以知悉后 24 小时作为兜底期限。第三是您需要提交的是报告还是预警：在 NIS2 和 CRA 下，24 小时内需要提交的是早期预警，其设计本身就很简短，并不要求您已完成调查。

GDPR：72 小时时限实际涵盖什么？

比大多数概述所暗示的要少。第 33(1) 条要求控制者在知悉个人数据泄露后，无不当延迟地向主管监管机构作出通知，并在可行的情况下不迟于 72 小时。这句话中包含三项限定条件，而且每一项都很重要。

它是有条件的。如果泄露不太可能对自然人的权利和自由造成风险，则该义务不适用。这一评估由您来作出并记录在案，而不是由监管机构作出。

错过时限并不自动构成违反该条。如果未在 72 小时内作出通知，第 33(1) 条要求通知须附上延迟的理由。条文本身就预见到了附有解释的迟延通知。

72 小时约束的是控制者，而不是处理者。第 33(2) 条要求处理者在知悉后无不当延迟地通知控制者，但没有规定固定期限。向客户承诺 72 小时内通知的供应商，承诺的是该条例并未要求他们做的事情；而依赖这一承诺的控制者，已经让出了自己大部分的时间窗口。

告知相关个人是第 34 条规定的另一项独立义务，完全没有 72 小时时限。该义务须无不当延迟地履行，仅在泄露可能对其权利和自由造成高风险时适用；并且在以下情况下，第 34(3) 条豁免您的这项义务：数据已通过加密等措施变得无法识读；后续措施已使高风险不再可能发生；或者逐一通知需要付出不相称的努力，而改为发布公开通告。

NIS2：报告分为哪几个阶段？

四个阶段，规定于第 23(4) 条，均自知悉重大事件之时起计算。

早期预警：无不当延迟，且无论如何须在 24 小时内发出，并在适用时说明事件是否被怀疑由非法或恶意行为引起，或是否可能产生跨境影响。事件通知：72 小时内提交，以初步评估更新早期预警，包括严重程度和影响，以及（如有）入侵指标。中期报告：报告事件状态，但仅在 CSIRT 或主管机关提出要求时提交。最终报告：不迟于事件通知后一个月提交。如果最终报告到期时事件仍在持续，您须改为提交进展报告，最终报告则在事件处理完成后一个月内提交。

根据第 23(3) 条，如果事件已经或可能造成服务的严重运营中断或给您带来财务损失，或者已经或可能通过造成相当大的物质或非物质损害而影响他人，则属于重大事件。请注意“可能造成”（is capable of causing）这一措辞：该测试并不局限于实际已经发生的损害。

有一项例外常被忽视。对于影响其信任服务提供的重大事件，信任服务提供商须在 24 小时内（而不是 72 小时内）提交 (b) 项规定的通知。如果您同时受 eIDAS 和欧盟 NIS2 指令约束，您的第二个截止期限与第一个相同。

DORA：真的是 4 小时吗？

是的，但起算时间并非您以为的那一刻。这些截止期限并不在欧盟《数字运营韧性法案》（DORA）本身之中。第 19(4) 条规定了初始通知以及中期报告和最终报告；具体时限则规定在 Commission Delegated Regulation (EU) 2025/301 第 5 条中。

初始通知应尽早提交，无论如何须在事件被归类为重大 ICT 相关事件后 4 小时内提交，且不得晚于您知悉该事件后 24 小时。这是一个截止期限、两个触发点，两者中先到期的那一个，就是您必须满足的期限。如果您在知悉后 24 小时内未将事件归类为重大事件，但之后将其归类为重大事件，第 5(2) 条给予您自该归类起 4 小时的时间。

中期报告最迟须在提交初始通知后 72 小时内提交，即使事件的状态或处理情况没有变化，也必须提交。随后，您须无不当延迟地提交更新后的中期报告，无论如何须在常规活动恢复时提交。最终报告不得晚于中期报告后一个月提交；如果提交了不止一份中期报告，则不得晚于最新一份更新后的中期报告后一个月提交。

有两项规定最好在事件发生之前，而不是在事件处理期间了解。第 5(3) 条要求，如果您无法按时提交，须在截止期限届满前告知主管机关并说明理由。第 5(4) 条允许落在周末或国家银行假日的截止期限在下一个工作日中午前完成，但第 5(5) 条对信贷机构、中央对手方、交易场所运营者，以及根据 NIS2 第 3 条被认定为基本实体或重要实体的机构，取消了初始通知和中期报告的这一宽限。如果您是银行，周末帮不了您。归类测试详见我们关于 DORA 重大事件归类的指南。

EU AI Act：严重事件何时需要报告？

第 73 条要求高风险 AI 系统的提供者向事件发生地成员国的市场监督管理机关报告严重事件。提供者一旦确定 AI 系统与事件之间存在因果关系，或存在这种因果关系的合理可能性，就须立即报告，且无论如何须在视事件而定的最长期限内报告。

默认的最长期限是自知悉起 15 天。对于大范围侵权，或对关键基础设施的管理或运营造成严重且不可逆转的中断的情形，期限缩短至 2 天。如果有人死亡，期限为 10 天，自知悉起计算，且一旦确定甚至只是怀疑存在因果关系，就须立即报告。

乍看之下，这个顺序似乎有误：有人死亡的最长期限竟然比关键基础设施中断的还长。但读过第 73(4) 条后就不那么奇怪了：该款要求一旦怀疑即须立即报告，而不是等到证实之后，因此 10 天是确定因果关系的兜底期限，而不是允许的延迟。

第 3(49) 条将严重事件定义为直接或间接导致以下后果之一的事件：死亡或对健康的严重损害、关键基础设施的严重且不可逆转的中断、违反保护基本权利的欧盟法律义务，或对财产或环境的严重损害。第 73(5) 条允许先提交不完整的初始报告，随后再提交完整报告；在适用 2 天期限时，这是切实可行的做法。适用范围和日期详见我们关于欧盟《人工智能法案》（EU AI Act）适用范围和截止期限的指南。

CRA：为什么有两份最终报告？

因为第 14 条设有两条独立的路径，而制造商往往只为其中一条做准备，结果被另一条打了个措手不及。

第一条路径是您产品中被积极利用的漏洞。知悉后 24 小时内发出早期预警，72 小时内提交漏洞通知，并在纠正措施或缓解措施可用后不迟于 14 天提交最终报告。

第二条路径是影响产品安全的严重事件。24 小时内发出早期预警，72 小时内提交事件通知，并在该通知后一个月内提交最终报告。

两条路径的前段完全相同，后段却不同。在所有这些制度中，漏洞最终报告是唯一一个从修复方案可用时起算、而不是从知悉或较早的提交起算的时限，因此发布补丁并不会结束您的义务，反而会启动一项新的 14 天义务。两条路径都通过第 16 条规定的单一报告平台，同时向被指定为协调者的 CSIRT 和 ENISA 报告，协调者还可以根据第 14(6) 条要求提交中期报告。

第 71 条规定第 14 条自 2026 年 9 月 11 日起适用，比该条例其余部分于 2027 年 12 月 11 日开始适用早一年多。完整的时间顺序详见我们关于欧盟《网络弹性法案》（CRA）2026 年和 2027 年截止期限的指南。

同时适用多项法规时，以哪个时限为准？

全部适用。这些法律文件中没有任何一项规定履行其中一项义务即可免除另一项义务，而且它们的报告对象各不相同：欧盟《通用数据保护条例》（GDPR）下是监管机构，欧盟 NIS2 指令下是 CSIRT 或主管机关，欧盟《数字运营韧性法案》（DORA）下是金融主管机关，EU AI Act 下是市场监督管理机关，CRA 下则是 CSIRT 协调者和 ENISA。

在实际运作中，最短的时限决定您的流程，其他时限沿用这一流程。同时受欧盟《数字运营韧性法案》（DORA）和欧盟《通用数据保护条例》（GDPR）约束的银行，会按 4 小时来构建流程，这样 GDPR 的 72 小时通知就绰绰有余了。按照适用的最长截止期限来设计流程，正是把一个应报告的事件变成执法事项的错误；由此带来的风险，我们分别针对欧盟 NIS2 指令、欧盟《网络弹性法案》（CRA）和 GDPR 作了阐述。唯一值得了解的收窄规则在欧盟《人工智能法案》（EU AI Act）中：根据第 73(9) 条，已受同等欧盟报告义务约束的附件 III 系统的提供者，只需报告涉及基本权利类别的严重事件；第 73(10) 条对医疗器械作了类似的收窄。

其他搜索结果的错误之处

已发布的各类对比文章中反复出现四个错误，其中三个会导致真实的报告提交延误。

第一个错误是把 DORA 说成一条简单的“4 小时规则”。实际上，它是自归类起 4 小时，并以知悉后 24 小时作为兜底期限；把它理解为自知悉起 4 小时的实体会过度报告，而忽视兜底期限的实体则会报告不足。一些广为流传的概述还为 DORA 杜撰了一个“24 小时中期报告”。根本不存在这样的阶段：中期报告的时限是 72 小时。

第二个错误是把 EU AI Act 描述为要求“立即”通知，却不给出具体数字。第 73 条设定了 2 天、10 天和 15 天的最长期限，而建立在“立即”一词之上的合规计划，没有可以用来检验自身的截止期限。第三个错误是把 NIS2 的 24 小时事项当作报告：它是早期预警，正是这一区别让该截止期限能够实现。

第四个错误是对例外规定只字不提。信任服务提供商的 24 小时规则、DORA 的周末条款及其对银行和交易场所的排除规定，以及 CRA 以修复方案为起点的 14 天时限，都写在原始文本中，却几乎从未出现在概述里。成员国在转化 NIS2 时还可以采用比该指令底线更严格的规定，因此某个国家的截止期限可能比本文引用的更短。

梳理您自己的报告时限

请为您自己的组织填写下表。任何一行您答不上来，都对应着一起您会延迟报告的事件。

如果大部分行都是空白，那么差距在于流程而不是工具，但两者相互关联：这些时限如此之短，手工整理一份报告就会耗尽时间。我们的事件管理模块针对上述每一个截止期限提供归类测试和报告模板，而免费合规检查会在您着手设计任何东西之前，告诉您实际适用哪些制度。

常见问题

欧盟最短的事件报告截止期限是多少？

4 小时，依据欧盟《数字运营韧性法案》（DORA），自 ICT 相关事件被归类为重大事件时起算，而不是从您知悉该事件之时起算，且上限为知悉后 24 小时。该时限由 Commission Delegated Regulation (EU) 2025/301 第 5 条规定，而不是由 DORA 本身规定。

GDPR 的 72 小时时限是从事件发生时开始计算吗？

不是。它从控制者知悉个人数据泄露之时起算；如果泄露不太可能对自然人的权利和自由造成风险，则该时限完全不适用。

根据 NIS2 进行报告能否同时满足 GDPR 的要求？

不能。它们是向不同主管机关履行的独立义务，内容和判断标准都不相同。一起事件可能根据欧盟 NIS2 指令属于重大事件，却并不构成个人数据泄露，反之亦然。

CRA 的报告义务何时开始？

2026 年 9 月 11 日。第 71 条规定该条例自 2027 年 12 月 11 日起全面适用，但将第 14 条提前至 2026 年 9 月适用，而且这些义务同样适用于已投放市场的产品。

如果我们错过了截止期限，会怎样？

视情况而定。欧盟《通用数据保护条例》（GDPR）预见了附有延迟理由的迟延通知。DORA 要求您在截止期限届满前告知主管机关并说明原因。NIS2 和欧盟《网络弹性法案》（CRA）将报告义务本身视为可强制执行的义务，而在 CRA 下，第 14 条规定的义务属于最高处罚档位。

原始资料

各项截止期限均摘自原始文本：Regulation (EU) 2016/679（GDPR）第 33 条和第 34 条；Directive (EU) 2022/2555（NIS2）第 23 条；Regulation (EU) 2022/2554（DORA）第 19 条，以及 Commission Delegated Regulation (EU) 2025/301 第 5 条；Regulation (EU) 2024/1689（EU AI Act）第 3(49) 条和第 73 条；以及 Regulation (EU) 2024/2847（Cyber Resilience Act）第 14 条和第 71 条。NIS2 是一项指令，因此各国的转化立法可以规定更短的期限或额外的义务。在依赖某个数字之前，请确认现行文本以及您所在国家的实施规定。