合规指南
按设计，DORA 的事件报告制度是整部法规中时间压力最大的义务。对于重大 ICT 相关事件，金融实体必须向其国家主管机关（NCA）提交初始通知，时间应尽早，且无论如何不得晚于将事件分类为重大后的 4 小时内，同时不得晚于知悉该事件后 24 小时。这些时限载于 Commission Delegated Regulation (EU) 2025/301，该法规补充了 DORA 第 19(4) 条。
这就形成了一个极其紧迫的窗口。但在计时甚至尚未开始之前，您还面临一个更难的问题：这个事件本身是否属于“重大”？
DORA 第 18 条以及联合 ESAs 关于 ICT 相关事件分类的监管技术标准（Commission Delegated Regulation (EU) 2024/1772）共同确立了一套结构化、多标准的阈值测试。分类是针对七项标准开展的明确评估，每项标准都有重要性阈值，用于判断某一事件是否跨过“重大”界线，并由一项精确的组合规则将这些标准串联起来。
判断错误会在两个方向上造成后果。少报，您将面临监管审查、整改命令和声誉损害。多报，您会让 NCA 被噪声淹没，并在实时事件处理中消耗稀缺资源。本指南将直接依据法规，为您说明确切的标准、阈值、时间线和决策逻辑，帮助您每次都正确完成分类。
📈
RTS 2024/1772，第 1 至 7 条
重大事件的 7 项分类标准
DORA 第 18(1) 条规定了金融实体用于分类 ICT 相关事件的标准，RTS（Delegated Regulation (EU) 2024/1772）第 1 至 7 条将其转化为七项具名标准，并由第 9 条为每一项确定重要性阈值。请先阅读这些标准，再看决定“重大”的组合规则。就阈值测试而言，这套规则设计得相当完善。准入条件将琐碎事项排除在外，双阈值规则避免单一噪声指标把您拖入申报流程，而且二者都足够客观，便于在与监管机构沟通时进行说明。其弱点在于，几乎每一项输入都依赖于您在事件仍在进行时必须收集的数据。
DORA 第 18(1) 条
“金融实体应对 ICT 相关事件进行分类，并应依据以下标准确定其影响：（a）受影响客户或金融交易对手的数量和/或相关性，以及在适用情况下，受影响交易的金额或数量 [...]，以及该 ICT 相关事件是否造成声誉影响；（b）ICT 相关事件的持续时间，包括服务停机时间；（c）地理范围 [...]；（d）ICT 相关事件导致的数据损失，涉及数据的可用性、真实性、完整性或机密性；（e）受影响服务的关键性 [...]；（f）经济影响，特别是直接和间接成本及损失 [...]。”
RTS 将这些内容拆分为七项标准：它把声誉影响单独列为一项标准，并将服务关键性作为准入条件。以下是每项标准及其在 RTS 第 9 条下的重要性阈值的权威拆解：
| # | 标准 | 重大性阈值（RTS Art. 9） | 衡量内容 |
|---|---|---|---|
| 1 | 受影响的客户、金融交易对手及交易 | > 使用受影响服务的客户的 10%，或 > 100,000 名客户；或 > 30% 的金融交易对手；或受影响交易 > 日均数量或价值的 10%（Art. 9(1)） | 统计无法访问或使用受影响服务的唯一客户或交易对手数量，并评估失败、延迟或处理错误的交易价值。交易属于本标准的一部分，而不是单独标准。 |
| 2 | 声誉影响 | 当事件已被媒体报道、导致客户或交易对手反复投诉、威胁实体满足监管要求的能力，或可能使其因重大业务影响而失去客户或交易对手时，即视为满足（Art. 2, Art. 9(2)） | 定性标准。评估可见度以及面向客户的后果。媒体报道，或面向客户的服务出现一波投诉，是最明确的信号。 |
| 3 | 持续时间与服务停机 | 事件持续时间 > 24 小时，或支持关键或重要职能的 ICT 服务停机时间 > 2 小时（Art. 9(3)） | 两个不同的计时口径：整体事件持续时间（24 小时阈值）以及支持关键或重要职能的服务停机时间（2 小时阈值）。包括性能下降。 |
| 4 | 地域范围 | 事件在两个或更多成员国造成影响（Art. 9(4)） | 评估是否有一个以上成员国的客户或运营受到影响。跨境支付系统、清算业务和代理行关系会放大这一标准。 |
| 5 | 数据损失 | 任何影响数据可用性、真实性、完整性或保密性的损失，并对业务目标或监管合规产生不利影响；或成功的恶意未授权访问系统，可能导致数据损失（Art. 9(5)(a) and (b)） | 考虑数据的四个维度。注意第二个分支：成功的恶意未授权访问，是 RTS 中最强的单一触发因素（见下方组合规则）。同时参照 GDPR 的个人数据泄露阈值。 |
| 6 | 受影响服务的关键性 （门槛） | 当事件影响支持关键或重要职能的 ICT 服务或系统；或影响经授权、注册或受监督的金融服务；或构成对网络与信息系统的成功、恶意且未授权访问时，即视为满足（Art. 6） | 这是主要门槛。 如果三个分支均不满足，无论其他阈值如何，该事件都不能构成重大事件。注意第三个分支：即使是非关键系统，成功的恶意入侵也会打开该门槛。 |
| 7 | 经济影响 | 直接和间接成本及损失已超过或可能超过 EUR 100,000（Art. 9(6)） | 汇总直接成本（补救、恢复、取证、罚款）和间接成本（收入损失、客户赔偿、机会成本）。阈值为固定的 EUR 100,000，不存在按收入百分比计算的替代阈值。尽早估算，后续细化。 |
组合规则（RTS 第 8 条）
如果某一事件影响了关键服务（关键性门槛，第 6 条），并且满足以下任一条件，则该事件属于重大事件：（i）达到 Article 9(5)(b) 门槛，即对网络和信息系统实施了成功的、恶意的、未经授权的访问，且可能导致数据丢失；或者（ii）达到 Article 9(1) 至 (6) 中六项重要性门槛中的两项或更多。换言之，单独一个普通门槛并不足够，您需要的是符合条件的恶意入侵，或至少两个门槛。经济影响是这六项门槛之一，并不具备特殊的单独触发效力。这是该规则中最常被误述的部分，而且通常会导致高成本后果。将金额数字视为触发条件的企业会过度报告，而过度报告会让内部人员认为该流程只是噪音。第 8 条还增加了一项汇总规则：反复发生、单独看不属于重大的事件，如果在 6 个月内至少发生两次、具有相同的表面根本原因，并且整体上满足测试条件，则按一个重大事件计算。实体每月进行此项评估，且该规则不适用于微型企业。
⏰
第 19 条 & RTS 2025/301
三阶段报告时间线
欧盟《数字运营韧性法案》（DORA）第 19 条要求，针对每一起重大 ICT 相关事件向相关 NCA 提交初始通知和两份后续报告。确切截止期限载于 Commission Delegated Regulation (EU) 2025/301 第 5 条。每个阶段都有严格计时和明确内容要求；如果您同时受多个制度约束，我们关于按法规划分的事件报告截止期限指南，将 DORA 的计时要求与欧盟《通用数据保护条例》（GDPR）、欧盟 NIS2 指令、欧盟《人工智能法案》（EU AI Act）和欧盟《网络弹性法案》（CRA）的计时要求并列展示。
Commission Delegated Regulation (EU) 2025/301，第 5 条
初始通知：尽早提交，且无论如何应在事件被分类为重大事件后 4 小时内提交，并且不得晚于金融实体知悉该事件后的 24 小时。中期报告：最迟在提交初始通知后的 72 小时内提交。最终报告：不晚于提交中期报告（或最新更新的中期报告）后一个月提交。
| 报告 | 截止期限 | 所需内容 |
|---|---|---|
| 初始通知 | 分类后 4 小时（知悉后最长 24h） | 实体识别信息；检测和分类的日期与时间；事件性质和类型；对受影响服务、客户和交易对手的初步评估；事件是否重复发生；初步影响评估；已采取的即时措施；联系方式。 |
| 中期报告 | 初始通知后 72 小时 | 根据标准和阈值更新的评估；遏制和恢复状态；初步根本原因；更新后的客户和交易对手影响；地理扩散范围；估计经济影响；受影响交易（数量和价值）；触发的其他通知义务；更新后的补救时间线。常规活动恢复后，还应提交一份更新的中期报告。 |
| 最终报告 | 中期报告后 1 个月 | 确认后的根本原因分析；完整量化的影响评估；经济总成本（直接和间接）；经验教训和纠正措施；对 ICT 风险管理框架的变更；该事件是否暴露第三方服务提供商失效；客户沟通确认；已采取措施的审计追踪。 |
“双时钟”问题
初始通知同时承载两个相互重叠的截止期限：自分类起 4 小时以及自知悉事件起 24 小时。这意味着，在绝对兜底期限生效之前，您大约有 20 小时的硬性上限来作出分类决定。应将分类作为一项单独的限时任务来处理。这个上限比标题看起来更宽裕，但仍不应以此作为规划依据。应基于不完整信息尽早分类并随后修订，因为首份报告本就应是初步报告；为了保证准确性而等待，正是机构最终迟报且报告不准确的原因。
自愿通知
第 19(2) 条允许金融实体在重大网络威胁尚未导致重大事件时，自愿通知其 NCA。这是可选的，但能够体现成熟的风险管理；对于符合重大威胁测试的险情未遂情形也可能很有用（见下方 FAQ）。
错过截止期限会发生什么
根据 DORA 第 50 条，主管机关可针对违规行为施加行政处罚和补救措施，并按不合规的严重程度和影响相称确定；在严重情况下，还可公开披露该违规。除制裁本身外，被标记为迟报或未报告者会招致更密切的监管关注，而这一成本往往超过罚款本身。
🌳
决策框架
分类决策树
发生 ICT 相关事件时，请使用这套结构化步骤作出分类决定。顺序很重要：先评估关键性入口条件，再并行评估实质性阈值，以尽量缩短分类时间。
步骤 1 - 入口条件：服务关键性（Article 6）
三个入口分支中是否任一满足？（a）事件影响在您的业务影响分析和信息登记册中支持关键或重要职能的 ICT 服务或系统；（b）事件影响需要授权、注册或监督的金融服务；（c）事件构成对您系统的成功恶意未授权访问。如果三项均为否 → 该事件不是重大事件。记录并管理该事件，但没有向 NCA 报告的义务。这个入口条件的绝大部分工作都应在事件发生前完成，即确定哪些服务支持关键或重要职能。请在没有火情时完成这项工作，入口条件就会变成一次查表；如果一直未做，您就会在时钟已经启动的情况下重新争论自己的业务影响分析。如果任一为是 → 进入步骤 2。
步骤 2 - 并行评估六项实质性阈值
针对 Article 9(1) 至 (6) 中的六项阈值，逐一判断是否满足：
客户 / 交易：>10% 或 >100k 客户，>30% 交易对手，或 >10% 日交易量？
声誉：媒体报道、重复投诉，或客户流失？
持续时间：持续时间 >24h，或关键/重要职能停机 >2h？
地域：两个或更多成员国？
数据损失：对数据造成不利影响，或可能导致数据损失的恶意访问（9(5)(b)）？
经济：成本和损失 > EUR 100,000？
步骤 3 - 适用组合规则（Article 8）
在满足入口条件的前提下，如果任一情况成立，则分类为重大事件：满足 Article 9(5)(b) 阈值（可能导致数据损失的成功恶意未授权访问），或步骤 2 中六项阈值有两项或更多满足。如果只满足一项普通阈值，且不存在符合条件的恶意访问 → 不是重大事件（但需持续监控）。当您将其分类为重大事件时，向 NCA 报告的 4 小时时钟从现在开始计时。
步骤 4 - 持续重新评估
事件会演变。第 1 小时的轻微事件，可能随着影响扩散在第 3 小时跨过第二项阈值。请在整个事件生命周期内重新评估分类。如果某一事件从非重大事件重新分类为重大事件，4 小时时钟从重新分类的时刻开始运行 - 但 24 小时绝对兜底期限仍从您首次知悉该事件时起算。
📑
事件分类法
重大事件、非重大事件与网络威胁
欧盟《数字运营韧性法案》（DORA）区分重大 ICT 相关事件（必须向 NCA 报告）与其他非重大事件（内部记录并管理），并另行允许自愿通报重大网络威胁。理解这些边界，可以避免过度报告，也可防止危险的低估分类。
| 维度 | 重大事件 | 非重大事件 | 重大网络威胁 |
|---|---|---|---|
| 触发条件 | 满足入口条件 + [9(5)(b) 或两个及以上阈值] | 未满足入口条件，或未满足组合规则 | 可能演变为重大事件的威胁（Art. 10），尚未发生事件 |
| 向 NCA 报告 | 是，强制性 | 否（根据 Art. 17 记录） | 自愿（Art. 19(2)） |
| 报告时间线 | 4h / 72h / 1 个月 | 仅内部 SLA | 无固定监管计时要求 |
| 管理机构 | 按 ICT 事件流程升级（Art. 17） | 运营或风险团队 | 风险管理升级 |
| 客户通知 | 在影响客户财务利益时需要通知（Art. 19(3)） | 通常不需要 | 不适用 |
| 根因分析 | 强制要求，纳入最终报告 | Art. 17 流程下预期开展 | 威胁分析 |
| 文档记录 | 完整审计追踪，供监管审查 | 内部记录，监管可访问 | 内部记录 |
为什么非重大事件仍然重要
尽管非重大事件不会触发向 NCA 报告的义务，但仍必须根据您的 ICT 相关事件管理流程（第 17 条）进行记录和管理。监管机构会在检查期间审查您的完整事件登记册，如果发现一系列记录为非重大、但本应分类为重大的事件，将立即引发警示。无论最终分类结果如何，都应为每个事件建立可辩护、带时间戳的分类理由。
🏛️
监管机制
NCA 报告：向谁、在哪里以及如何报告
报告接收方是您的母国 NCA，即授权或注册该金融实体的主管机构。对于银行，通常是国家银行监管机构（例如德国的 BaFin、法国的 ACPR、荷兰的 DNB、爱尔兰中央银行）。对于支付机构，则是相关支付服务监管机构。对于跨境集团，母公司实体的母国 NCA 会与东道国监管机构协调。
报告格式
报告模板由实施技术标准（Commission Implementing Regulation (EU) 2025/302）规定。每个阶段，初始、中期、最终，均使用标准化的结构化表格，并以自由文本叙述补充结构化数据。提交通过 NCA 指定的报告渠道完成。
明确负责人
指定一名有权升级、分类和提交报告的人员，无需等待委员会批准，并预先任命副手以实现 24/7 覆盖。在 4 小时计时下，负责人不清是错过截止期限最常见的单一原因。指定此人本是一次简短沟通，但多数公司会拖延数月，因为它看起来像一个治理问题。将该姓名和副手写入运行手册，然后确认副手知道自己是副手。
跨境协调
对于与其他成员国相关的事件，母国 NCA 会按照 RTS 第 11 条和第 12 条的规定，与相关东道国 NCA 以及 ESAs（EBA、EIOPA、ESMA）共享通知。您向一个 NCA 报告；由其协调其余事项。请在报告中标明跨境维度。
并行通知义务
重大 ICT 事件也可能触发其他制度：欧盟《通用数据保护条例》（GDPR）（第 33 条，72 小时泄露通知）、欧盟 NIS2 指令（如果该实体属于基本或重要实体）以及 PSD2（适用于支付服务提供商）。每项制度都有各自的时间线和主管机构。请将所有并行义务映射到您的事件响应流程中。
实务提示：预先准备报告
预先在初始通知模板中填入静态实体数据（标识符、NCA 编号、授权详情、关键联系人姓名、标准服务说明），以便在真实事件发生期间，您的团队只需填写事件特定字段。这样可以将紧迫的时间窗口用于遏制和评估，而不是填写表格。
⚠️
应避免的陷阱
6 个常见分类错误
这些是在时间压力下最容易让事件团队出错的分类错误，以及每个错误为何重要。
错误 1：等到完整影响数据后才分类
团队会推迟分类，直到获得确定的客户数量、经济数据或已确认的根本原因。但初始通知明确允许使用初步数据，它要求的是合理评估，而不是确定性。等待完美数字会耗尽您的 4 小时窗口，并有违反 24 小时绝对最后期限的风险。应基于当时可获得的最佳信息进行分类，然后在中期报告和最终报告中完善。
错误 2：混淆“ICT 事件”和“网络安全事件”
DORA 的范围比网络安全更广。第 3(8) 条将“ICT 相关事件”定义为实体未计划的单一事件或一系列相互关联的事件，其损害网络和信息系统安全，并对数据的可用性、真实性、完整性或机密性，或所提供的服务产生不利影响。这包括硬件故障、软件缺陷、配置错误、云服务提供商中断和容量耗尽，而不仅是勒索软件和数据泄露。许多实体根本不会将基础设施事件纳入分类流程。这才是需要担心的误读，因为它是无声的。没有任何东西会提醒您存在一个从未执行过的分类；而一次导致支付队列停摆一下午的容量故障，在监管机构看来与您选择不报告的违规事件没有区别。
错误 3：未将服务映射到关键或重要职能
关键性门槛（第 6 条）取决于受影响服务是否支持关键或重要职能，第 3(22) 条将其定义为一旦中断会实质性损害实体财务业绩，或其服务的稳健性或连续性，或其对授权条件的合规性的职能。如果没有基于业务影响分析和信息登记册，对 ICT 服务与职能之间建立确定的映射，门槛评估就会变成猜测。
错误 4：把第三方中断视为“不是我们的事件”
当云服务提供商、支付处理方或 SaaS 供应商发生中断并影响您的服务时，这就是需要由您分类的 ICT 相关事件。各项标准评估的是对您的客户、您的服务和您的交易的影响。外部根本原因并不能免除您的报告义务，DORA 中的第三方风险管理 (TPRM)义务正是针对这种场景。
错误 5：未随事件演变重新分类
最初为轻微的事件，可能会随着级联故障扩散而变成重大事件。09:00 的数据库性能问题可能只影响内部系统；到 11:00，面向客户的 API 可能已在三个国家超时，并使第二个阈值越线。只分类一次且从不重新评估的团队会错过重新分类，并突破报告窗口。对于任何影响 ICT 基础设施的事件，都应在您的行动手册中设置重新评估检查点。
错误 6：未协调 DORA、GDPR 和 NIS2 通知
单一事件可能触发 DORA（4 小时内向 NCA 报告）、欧盟《通用数据保护条例》（GDPR）（72 小时内向 DPA 报告）和欧盟 NIS2 指令（24 小时内向 CSIRT 发出早期预警）下的报告要求。各自的阈值、主管机构和内容均不同。将这些工作放在不同孤岛中运行的实体，必然会向不同监管机构发送不一致的信息，这是会引发审查的危险信号。应从同一份事件记录和同一项分类评估出发，驱动所有通知义务。
🔍
应用分类
实操场景：是否构成重大事件？
理论很清晰，现实却很复杂。以下 4 个示例场景展示了如何适用入口条件和组合规则。每个场景都会说明入口条件测试和阈值计数。
| 场景 | 关键事实 | 标准分析 | 分类 |
|---|---|---|---|
| 云服务提供商中断影响网上银行 | 云区域中断，手机银行和网上银行停机 3.5 小时，约 45,000 名零售客户受影响，涉及单一国家，恢复和补救成本估计超过 EUR 100,000 | 入口条件：网上银行支持关键功能。阈值 1：停机时间 3.5h > 2h。阈值 2：经济影响 > EUR 100,000。满足两个阈值。 | 重大 |
| 内部 HR 系统遭勒索软件攻击 | 勒索软件加密 HR 和薪资系统，员工数据可能已被外传，恢复耗时 48 小时，对客户侧无影响 | 入口条件：一次成功的恶意未授权访问可通过第 6(c) 条打开入口，即使 HR 并非关键功能。单一触发：同一次访问满足第 9(5)(b) 条。入口条件 + 9(5)(b) 本身即已足够。 | 重大 |
| 支付处理能力下降 | 银行卡支付处理能力降至 60%，持续 90 分钟，EUR 2.3M 的银行卡交易延迟，超过该处理机构平均每日交易金额的 10%，DE 和 NL 的客户受影响 | 入口条件：支付处理属于关键功能。持续时间：90 min < 2h，不满足。阈值 1：地域范围，2 个成员国（Art. 9(4)）。阈值 2：受影响交易超过日均交易金额的 10%（Art. 9(1)）。满足两个阈值。 | 重大 |
| 针对营销网站的 DDoS 攻击 | 一次 DDoS 使企业营销网站离线 4 小时；对交易、银行或支付系统无影响；无未授权访问；仅限营销网站 | 入口条件：营销网站并非关键或重要功能，未影响任何金融服务，而 DDoS 是一种服务中断，并非成功的未授权访问。三个入口分支均不满足。 | 非重大 |
灰色地带
大多数争议都出现在入口条件显然满足，但第二个阈值处于边界状态的情形。监管规则并未要求“有疑问即报告”，但监管机构期望每一次判断都有记录在案且站得住脚的理由。当双阈值测试确实处于边缘状态时，许多实体会倾向于先报告，并在中期报告中下调级别。被纠正的过度报告，远不如 NCA 事后发现的少报有害。无论您如何决定，都要记录原因。
⚡
平台能力
Venvera 如何支持事件分级
当您只有 240 分钟时，不能把其中一半时间花在判断是否需要报告上。Venvera 的事件模块是更广泛的多框架合规平台的一部分，它将第 6 条门槛、第 9 条重大性阈值、第 8 条组合规则以及三阶段报告时间线编码为结构化工作流，使分级成为有引导的评估，而不是围绕电子表格的争论。
引导式分级
输入事件参数（受影响服务、持续时间、客户数量、地理范围），模块会根据 RTS 组合规则评估门槛和 6 项阈值，并返回分级建议及其背后的监管依据。
关键功能映射
在您的 ICT 服务、业务功能以及信息登记册中的关键性评估之间预配置映射，意味着第 6 条门槛会根据受影响的服务自动评估。
截止期限倒计时与提醒
自事件记录开始，倒计时器会跟踪 4 小时初始通知窗口、72 小时中期截止期限以及 1 个月最终报告截止日期，并在每个截止期限临近时发出升级提醒。
NCA 报告起草
报告模板与实施技术标准（Regulation (EU) 2025/302）对齐。实体识别信息、静态数据和服务映射会预先填充；事件特定字段采用结构化设计，便于快速完成和导出。
重新分级监测
在实时事件中更新事件参数时，模块会重新评估组合规则。如果非重大事件越过第二个阈值，它会标记该变化，避免您错过报告窗口。
多框架协调
单一事件记录可驱动 DORA、欧盟《通用数据保护条例》（GDPR）和欧盟 NIS2 指令下的并行评估，映射各制度的阈值并独立跟踪各自截止期限，确保一致的信息送达每个监管机构。
分级审计追踪
每一次分级决定、参数变更和重新评估都会记录时间戳和用户归属，因此当监管方询问某个事件为何被分级为非重大时，您可以提供可辩护的推理记录。
结构化根本原因
根本原因捕获与监管方预期的事件分类体系对齐，为您的最终报告以及更广泛的 ICT 风险管理框架（DORA 第 6 条）提供输入。
把时间窗口用于遏制，而不是填表
将规则编码的目的很简单：把分类转化为有引导、数分钟即可完成的评估，并保留可辩护的审计追踪，让您的团队把 4 小时窗口用于遏制事件和保护客户，而不是在电话会议上争论阈值。
要点摘要
- 关口加组合规则：只有在事件影响关键服务（第 6 条），并且发生成功的恶意未授权访问（Article 9(5)(b)），或满足六项阈值中的两项或以上时，该事件才属于重大事件。
- 一项阈值不足以认定：经济影响超过 EUR 100,000，本身并不使事件构成重大事件，它只是六项阈值之一，您需要满足两项阈值（或发生符合条件的恶意入侵）。
- 4 小时初始通知：时钟从分类时开始计算，并以您知悉事件起 24 小时作为绝对兜底期限，因此您最多大约有 20 小时完成分类。
- 三阶段报告：初始报告（4h）、中期报告（72h）、最终报告（1 个月），截止期限由 Delegated Regulation (EU) 2025/301 规定。
- 第三方中断也计入：如果您的服务提供商宕机且您的客户受到影响，则这是需要由您分类和报告的事件。
- 记录每一次判断：无论是否重大，都要记录每个事件的分类理由，监管机构会检查您的事件登记册。
常见问题
根据 DORA，什么会使 ICT 相关事件构成“重大事件”？
根据分类 RTS（Delegated Regulation (EU) 2024/1772）第 8 条，在事件已影响关键服务（第 6 条中的关键性关口），并且满足 Article 9(5)(b) 阈值，即对网络和信息系统发生可能导致数据损失的成功、恶意且未授权访问，或满足 Article 9(1) 至 (6) 中六项重要性阈值的两项或以上时，该事件构成重大事件。仅满足关口条件并不足够，任何单一普通阈值本身也不足够。
DORA 事件报告时间线是什么？
共有三个阶段，截止期限由 Delegated Regulation (EU) 2025/301 第 5 条规定。初始通知应尽早提交，并在将事件分类为重大事件后 4 小时内提交，且最迟不得晚于知悉事件后 24 小时。中期报告应在初始通知后 72 小时内提交。最终报告应在中期报告后不晚于一个月提交。
EUR 100,000 的经济影响金额是否是独立触发条件？
不是。第 9(6) 条中的经济影响阈值，在直接和间接成本及损失超过或可能超过 EUR 100,000 时即被满足，但它只是六项重要性阈值之一。单独来看，即使已满足关口条件，也只产生一项阈值，并不足够。您还需要第二项阈值，或 Article 9(5)(b) 下符合条件的恶意未授权访问。对于 EUR 100,000 这一金额，不存在按收入百分比计算的替代标准。
第三方服务提供商中断是否算作我们的事件？
是的。如果云服务提供商、支付处理方或其他 ICT 第三方发生中断，并影响您的服务、客户或交易，这就是由您进行分类的 ICT 相关事件；如符合测试标准，还需要由您报告。分类标准衡量的是对您运营的影响；外部根本原因并不会免除该义务。
什么是“重大网络威胁”，是否必须报告？
根据 RTS 第 10 条，网络威胁在综合满足以下条件时属于重大：如果实际发生，可能影响该实体（或其他实体、服务提供商、客户或交易对手）的关键或重要职能；根据漏洞、威胁行为者的能力和意图以及持续性判断，其实际发生的可能性较高；并且如果实际发生，可能达到重大事件的关键性和重要性阈值。根据 DORA 第 19(2) 条，报告重大网络威胁是自愿的，并非强制。
主要来源
本指南依据法规及其技术标准编写：Regulation (EU) 2022/2554（DORA，包括第 18、19 和 50 条）；Commission Delegated Regulation (EU) 2024/1772（关于重大 ICT 相关事件和重大网络威胁分类的 RTS，包括第 1 至 10 条）；Commission Delegated Regulation (EU) 2025/301（关于事件报告内容和时限的 RTS，第 5 条）；以及 European Banking Authority 的 DORA 页面，其中包含 ESAs 的事件报告标准。在依赖任何具体数字或截止期限之前，请务必确认当前文本。
本文仅供参考，不构成法律或监管建议。金融实体应咨询其法律顾问和主管机关，以获取关于 DORA 事件分类和报告的实体特定指导。最后审核时间：2026 年 7 月。
