NEWVenvera 支持您的语言: 完整平台支持英语、德语、西班牙语、保加利亚语、阿拉伯语和简体中文。查看新功能 →
欧盟《数字运营韧性法案》(DORA)要求详解
合规指南

欧盟《数字运营韧性法案》(DORA)要求详解

·Alexander Sverdlov

Regulation (EU) 2022/2554,即欧盟《数字运营韧性法案》(DORA),自 2025 年 1 月 17 日起适用。第 1(1)(a) 条列出了它对金融实体的要求:ICT 风险管理,重大 ICT 相关事件的报告以及重大网络威胁的自愿通报,数字运营韧性测试,网络威胁信息和情报共享,以及健全管理 ICT 第三方风险的措施。这五组要求构成了该条例的第 II 章至第 VI 章,即第 5 条至第 45 条,也是监管机构评估您的全部依据。

以这些要求为基础构建的每一个合规项目,都受到两点影响。各项要求的分量并不相同:关于 ICT 风险管理的第 II 章共有十二条,关于第三方风险的第 V 章共有十七条,而信息共享只有一条许可性条款。此外,义务还按实体分级:第 16 条为一份明确列出的较小实体名单设定了简化框架,以取代第 5 条至第 15 条;微型企业则在逐条规定中被豁免了若干具体义务。

事实详情
法律依据2022 年 12 月 14 日的 Regulation (EU) 2022/2554,在每个成员国直接适用。第 64 条规定其自 2025 年 1 月 17 日起适用。
约束对象第 2(1) 条第 (a) 至 (t) 点列出的二十类金融实体,从信贷机构到证券化存储库,外加第 (u) 点规定的 ICT 第三方服务提供商。
五组要求ICT 风险管理(第 5 条至第 16 条),事件管理、分类和报告(第 17 条至第 23 条),韧性测试(第 24 条至第 27 条),ICT 第三方风险(第 28 条至第 44 条),以及信息共享(第 45 条)。
较宽松的制度第 16 条适用于小型且非关联的投资公司、获得豁免的支付机构和电子货币机构,以及小型职业退休金机构(IORP)。根据第 3(60) 条,微型企业即员工少于 10 人、营业额或资产负债表总额不超过 EUR 200 万的企业,被排除在特定义务之外。
报告时限Delegated Regulation (EU) 2025/301 第 5 条:在将事件归类为重大事件后 4 小时内、且最迟在知悉后 24 小时内提交初始通知,72 小时内提交中期报告,一个月内提交最终报告。
执法第 50 条赋予主管机构监管、调查和制裁权力;处罚由各成员国规定。DORA 并未设定全欧盟统一的罚款上限。
按章节顺序排列的五组 DORA 要求:第 5 条至第 16 条的 ICT 风险管理、第 17 条至第 23 条的事件报告、第 24 条至第 27 条的韧性测试、第 28 条至第 44 条的 ICT 第三方风险,以及第 45 条的信息共享

谁必须遵守 DORA?

第 2(1) 条列出了二十类金融实体:信贷机构;支付机构,包括根据第二版《支付服务指令》获得豁免的支付机构;账户信息服务提供商;电子货币机构,包括获得豁免的电子货币机构;投资公司;加密资产服务提供商和资产参考代币发行人;中央证券存管机构;中央对手方;交易场所;交易数据存储库;另类投资基金管理人;管理公司;数据报告服务提供商;保险和再保险企业;保险和再保险中介机构;职业退休金机构;信用评级机构;关键基准管理人;众筹服务提供商;以及证券化存储库。第 2(2) 条将这一群体统称为金融实体。第 (u) 点增加了 ICT 第三方服务提供商,它们承担的是第 V 章的监督条款,而不是金融实体的义务。

随后,第 2(3) 条排除了六类群体:低于《另类投资基金管理人指令》(AIFM Directive)第 3(2) 条所定门槛的另类投资基金管理人;低于 Solvency II 第 4 条所定规模门槛的保险和再保险企业;成员总数不超过 15 人的职业养老金计划;根据 MiFID II 第 2 条和第 3 条获得豁免的人员;属于微型企业或中小企业的保险中介机构;以及邮政汇划机构。第 2(4) 条允许成员国将《资本要求指令》中列出的某些机构排除在其本国领土的适用范围之外。您是否属于适用范围,由这两款规定决定。我们的指南欧盟《数字运营韧性法案》(DORA)与欧盟 NIS2 指令有何不同解释了为什么根据第 1(2) 条,受 DORA 约束的金融实体在 NIS2 意义上被视为受特定行业法律覆盖。

谁承担哪一版本的 DORA 义务:第 2(1) 条规定的二十类金融实体、适用于第 16 条所列实体的简化框架、第 3(60) 条规定的微型企业豁免,以及根据第 31 条由某一欧洲监管机构(ESA)监督的关键 ICT 服务提供商

ICT 风险管理框架必须包含哪些内容?

第 II 章的起点是管理机构,而不是框架。第 5(2) 条要求管理机构对框架中的每一项安排进行定义、批准和监督,并为其承担责任,同时列出了其具体含义:对 ICT 风险承担最终责任;为所有 ICT 相关职能设定角色;批准数字运营韧性战略和 ICT 风险容忍度;批准并审查 ICT 业务连续性策略以及响应和恢复计划;批准 ICT 内部审计计划;分配并审查数字运营韧性预算(包括培训预算);以及批准 ICT 第三方服务使用策略。其中每一项都是监管机构可以要求查看的、注明日期的决定。

随后,第 6(1) 条要求建立健全、全面且有完善文档记录的 ICT 风险管理框架,作为整体风险管理体系的一部分。第 6(4) 条要求微型企业以外的金融实体将 ICT 风险监督职责分配给具有适当独立性的控制职能,并按照三道防线或同等模式,将 ICT 风险管理、控制和内部审计相互分离。第 6(5) 条要求对框架形成文件并至少每年审查一次,此外还须在发生重大 ICT 相关事件后,以及根据监管指示或测试、审计的结论进行审查。第 6(6) 条要求定期对框架开展内部审计,第 6(7) 条要求针对关键审计发现建立正式的跟进流程。第 6(8) 条要求框架包含数字运营韧性战略,其中须设定风险容忍度、附有关键绩效指标和关键风险度量的信息安全目标,以及 ICT 参考架构。

第 7 条至第 14 条提供了具体的运作要素:保持 ICT 系统和工具可靠且及时更新;识别所有业务职能及支持这些职能的 ICT 资产;第 9 条规定的保护和预防;第 10 条规定的、须定期测试的检测机制;第 11 条规定的 ICT 业务连续性策略;第 12 条规定的备份和恢复;第 13 条规定的学习和改进,包括重大事件后的事后审查;以及第 14 条规定的危机沟通计划。我们的指南如何编写 DORA ICT 风险管理框架和 DORA 关键风险指标逐条解读了这些条款。

围绕同一个合规项目的 DORA 第 II 章条款图:第 5 条治理、第 6 条框架、第 11 条业务连续性、第 12 条备份、第 13 条学习以及第 14 条沟通

哪些实体适用简化框架?

第 16(1) 条规定,第 5 条至第 15 条不适用于以下实体:小型且非关联的投资公司;根据《支付服务指令》获得豁免的支付机构;在成员国未行使第 2(4) 条选择权的情况下,根据《资本要求指令》获得豁免的机构;根据《电子货币指令》获得豁免的电子货币机构;以及小型职业退休金机构。这些实体仍须建立并维护健全且形成文件的 ICT 风险管理框架,持续监控所有 ICT 系统的安全和运行,通过具有韧性且及时更新的系统将 ICT 风险的影响降至最低,并识别和管理其业务职能面临的 ICT 风险。框架更加简化,但建立框架的义务并未取消。

Venvera 中的欧盟《数字运营韧性法案》(DORA)仪表板,显示信息登记册、风险管理、事件响应和第三方风险的合规评分,并提供差距评估和韧性测试模块

ICT 相关事件必须如何管理和报告?

第 17 条要求建立 ICT 相关事件管理流程,用于检测、管理和通报事件,并要求记录每一起 ICT 相关事件和重大网络威胁,识别、记录并处理其根本原因。第 18 条要求按照既定标准对事件进行分类:受影响客户或金融交易对手的数量和重要性、持续时间(包括服务停机时间)、地域分布范围、数据损失、受影响服务的关键程度以及经济影响。将这些标准转化为重大事件判定的阈值规定在另一部授权条例中,我们的指南 DORA 重大事件分类对此进行了详细解读。

第 19(1) 条要求向相关主管机构报告重大 ICT 相关事件,第 19(4) 条规定了三份文件:初始通知;在状态发生重大变化后或应要求提交的中期报告;以及在根本原因分析完成后提交的最终报告。时限由 Delegated Regulation (EU) 2025/301 第 5 条规定。初始通知应尽早提交,无论如何须在将事件归类为重大事件后四小时内提交,且最迟不晚于实体知悉该事件后 24 小时。中期报告须在初始通知后 72 小时内提交,即使情况没有任何变化也是如此。最终报告须在中期报告或其最新更新后一个月内提交。如果截止期限恰逢周末或银行假日,第 5(4) 条允许在下一个工作日中午之前提交,但第 5(5) 条规定,信贷机构、中央对手方、交易场所以及根据欧盟 NIS2 指令被认定为基本实体或重要实体的实体不享有这一宽限。

第 19(2) 条规定,重大网络威胁的通报属于自愿性质。第 19(5) 条允许将报告工作外包,但实体仍须承担全部责任。我们对各法规事件报告截止期限的比较,将 DORA 的时限与欧盟《通用数据保护条例》(GDPR)、NIS2、欧盟《人工智能法案》(EU AI Act)和欧盟《网络弹性法案》(CRA)的时限并列对照。

根据第 19(4) 条和 Delegated Regulation (EU) 2025/301 规定的 DORA 重大事件报告时限:归类后四小时内且最迟在知悉后 24 小时内提交初始通知,72 小时内提交中期报告,一个月内提交最终报告

DORA 要求开展哪些测试?

第 24(1) 条要求微型企业以外的金融实体建立、维护和审查健全而全面的数字运营韧性测试计划,作为 ICT 风险管理框架不可分割的一部分。第 24(4) 条要求测试由独立方(内部或外部)执行;如果测试人员来自内部,则须配备充足的资源,且不存在利益冲突。第 24(5) 条要求制定程序,对测试发现的每一个问题进行优先级排序、分类和整改。第 24(6) 条设定了最低要求:至少每年对支持关键或重要职能的所有 ICT 系统和应用程序开展适当的测试。

第 25 条列出了测试计划可采用的手段:漏洞评估和扫描、开源分析、网络安全评估、差距分析、物理安全审查、问卷和扫描软件、在可行情况下的源代码审查、基于场景的测试、兼容性测试、性能测试、端到端测试以及渗透测试。第 26 条增加了威胁导向渗透测试(TLPT):由主管机构认定的实体须至少每三年开展一次,并在支持若干或全部关键或重要职能的实时生产系统上进行。我们关于董事会必须批准的年度测试计划和 DORA 威胁导向渗透测试的指南,分别涵盖了这两部分内容。

DORA 对 ICT 第三方服务提供商有哪些要求?

第 28(1) 条将 ICT 第三方风险作为第 6 条框架内 ICT 风险不可分割的组成部分,并规定无论外包了什么,金融实体始终须对其义务承担全部责任。第 28(2) 条要求第 16 条所列实体和微型企业以外的实体,采用并定期审查 ICT 第三方风险战略,其中包括关于支持关键或重要职能的 ICT 服务的策略。第 28(3) 条是大多数合规项目都会低估的要求:信息登记册须涵盖与使用 ICT 服务有关的所有合同安排,在实体、次级合并和合并层面进行维护,区分支持关键或重要职能的安排与不支持此类职能的安排,至少每年向主管机构报告一次,并在主管机构要求时完整提供。同一款还要求就任何计划中的、支持关键或重要职能的安排,及时通知主管机构。

第 28(8) 条要求为支持关键或重要职能的 ICT 服务制定退出战略。第 30 条规定了合同条款:双方的权利和义务须以书面形式载明,并纳入包含服务级别协议在内的同一份文件。第 31 条及以后各条建立了监督框架,欧洲监管机构(ESA)据此认定关键 ICT 第三方服务提供商,并为每一家指定一个牵头监督机构。我们关于信息登记册模板和建立合规的供应商登记册的指南,涵盖了合同条款和报送工作。

Venvera 中依据欧盟《数字运营韧性法案》(DORA)第 28(3) 条建立的信息登记册,显示 ICT 服务提供商、合同安排、业务职能和风险评估,并提供完整度评分和 xBRL-CSV 导出

信息共享是强制性的吗?

不是。第 45(1) 条规定,金融实体之间可以交换网络威胁信息和情报,包括入侵指标,战术、技术和程序,警报以及配置工具,前提是共享旨在增强数字运营韧性,并在可信社区内、根据保护信息的安排进行。这是唯一一个以许可性语气写成的章节。第 45(3) 条增加了唯一一项硬性义务:加入此类安排的实体,须在其成员资格获得确认后通知主管机构,并在退出时再次通知。除此之外,监管机构可以期待看到的,是关于您是否参与以及如何参与的、形成文件的决定。

DORA 如何执行?

第 50(1) 条要求主管机构拥有履行该条例规定职责所需的全部监管、调查和制裁权力,第 50(2) 条列出了最低限度的权力:查阅主管机构认为相关的任何文件或数据,以及开展现场检查和调查,包括传唤代表作出口头或书面解释。第 50(3) 条要求成员国制定规则,规定适当的行政处罚和补救措施,且这些措施须有效、相称并具有威慑力;第 50(4) 条要求成员国至少赋予主管机构下令停止违规行为,以及要求暂时或永久停止某种做法的权力。第 51 条规定,这些权力须依照国家法律框架行使。该条例本身并未设定全欧盟统一的罚款上限;处罚由各国规定。它真正确定的是监管机构可以要求提供的证据,这正是为什么我们的指南 DORA 审计中会遇到什么将第 50 条与第 6(6) 条要求您开展的内部审计结合起来解读。

DORA 合规项目必须展示的内容:十二个月内完成第 6(5) 条规定的框架审查,本年度已按第 24(6) 条对支持关键或重要职能的系统进行测试,ICT 合同已录入第 28(3) 条规定的信息登记册,以及按第 19 条在 24 小时内完成事件分类

其他搜索结果错在哪里

第一个错误是把五大支柱说成规模相同的五个项目。仅第 V 章就从第 28 条延续到第 44 条,而第 28(3) 条规定的信息登记册是一项结构化的年度报送,有其专门的实施条例。第 45 条只有一条,其第一款以“可以”(may)一词开头。为它们平均分配预算的计划,误读了该条例。

第二个错误是把 72 小时说成第一个报告截止期限。这个数字对应的是中期报告。初始通知须在将事件归类为重大事件后四小时内提交,且最迟不晚于知悉后 24 小时,这是一个截然不同的运营问题:计时从一项分类决定开始,而这项决定需要在非工作时间作出。

第三个错误是认为每项义务都以相同形式适用于每个实体。第 16 条针对一份明确列出的较小实体名单取代了第 5 条至第 15 条,微型企业则被排除在第 6(4) 条的控制职能要求、第 6(6) 条的内部审计、第 24 条的测试计划和第 28(2) 条的第三方战略等义务之外。如果在阅读该条例时忽略这些豁免,就会高估小型支付机构的工作量,同时低估较大机构必须记录在案的判断。这两类豁免以及 PSD2 事件相关规则的变化如何适用于支付行业,请参阅我们的指南欧盟《数字运营韧性法案》(DORA)对支付机构的要求。

您目前的状况如何?

请根据您自己的记录填写下表。空白的一行,就是一项等着监管机构提出的审计发现。

问题您的答案条款
您属于第 2(1) 条所列二十类实体中的哪一类,第 16 条是否适用?Art. 2(1), Art. 16(1)
管理机构最近一次批准数字运营韧性战略和 ICT 风险容忍度是在什么时候?Art. 5(2)(d), Art. 6(8)
ICT 风险管理框架最近一次审查是在什么时候,审查报告在哪里?Art. 6(5)
在非工作时间,由谁决定某个事件是否属于重大事件,初始通知能否在四小时内发出?Art. 18, Art. 19(4)
过去十二个月内,哪些支持关键或重要职能的 ICT 系统接受了测试?Art. 24(6)
是否每一份 ICT 合同都已录入信息登记册,并按是否支持关键或重要职能进行区分?Art. 28(3)
每一份支持关键或重要职能的合同是否都有退出战略?Art. 28(8)

如果有好几行空白,请先从范围入手,再处理框架。我们的指南为您的 DORA 就绪度打分将这些条款转化为加权评估,指南 DORA 合规需要多少成本为其中每一项列出了预算项目,而免费合规检查会告诉您目前能为哪些行提供证据。我们的 DORA 合规软件将各项要求作为有负责人和证据的受跟踪控制措施进行管理,以 xBRL-CSV 格式保存信息登记册,并从分类决定之时起运行四小时事件计时。

DORA 要求的结论:五大支柱、一个框架,以及从分类之时开始计时的报告时限

常见问题

DORA 的五大支柱是什么?

ICT 风险管理(第 II 章,第 5 条至第 16 条),ICT 相关事件的管理、分类和报告(第 III 章,第 17 条至第 23 条),数字运营韧性测试(第 IV 章,第 24 条至第 27 条),ICT 第三方风险管理(第 V 章,第 28 条至第 44 条),以及信息共享安排(第 VI 章,第 45 条)。它们正是第 1(1)(a) 条列为该条例主题事项的内容。

DORA 何时开始适用?

第 64 条规定自 2025 年 1 月 17 日起适用。实体义务没有后续的分阶段实施安排;信息登记册、事件报告时限和测试计划均已自该日起生效。

DORA 是否适用于微型企业?

适用,但有豁免。根据第 3(60) 条,微型企业是指员工少于 10 人、营业额或资产负债表总额不超过 EUR 200 万的企业,可免于履行特定义务,例如第 6(4) 条规定的独立控制职能、第 6(6) 条规定的内部审计以及第 24 条规定的测试计划。框架本身、事件报告和信息登记册仍然适用。

DORA 规定的重大事件报告截止期限是什么?

根据 Delegated Regulation (EU) 2025/301 第 5 条,初始通知须在将事件归类为重大事件后四小时内提交,且最迟不晚于知悉后 24 小时;中期报告须在初始通知后 72 小时内提交;最终报告须在中期报告后一个月内提交。

对银行而言,DORA 是否取代了 NIS2?

第 1(2) 条将欧盟《数字运营韧性法案》(DORA)视为一部特定行业的欧盟法律,适用于根据欧盟 NIS2 指令被认定为基本实体或重要实体的金融实体,因此 DORA 的要求取代了 NIS2 中相应的要求。我们的指南 DORA 与 NIS2 对比列出了两者仍然存在差异的地方。

一手资料来源

文中的条款引用、实体名单、豁免规定和适用日期取自 Regulation (EU) 2022/2554,特别是第 1 条至第 3 条、第 5 条、第 6 条、第 16 条至第 19 条、第 24 条至第 26 条、第 28 条、第 30 条、第 45 条、第 50 条、第 51 条和第 64 条。报告时限取自 Commission Delegated Regulation (EU) 2025/301 第 5 条。在依据某项具体条款之前,请先确认现行文本。

Alexander Sverdlov

Alexander Sverdlov

Venvera 首席执行官兼创始人

Alexander 是 Venvera 的创始人,在欧洲网络安全与合规领域拥有 20 多年经验。他曾为受监管的金融机构、金融科技公司和 SaaS 企业主导安全与风险项目,这些企业需要遵守 DORA、NIS2、GDPR、ISO 27001 和 EU AI Act。创立 Venvera 之前,他创办了进攻性安全咨询公司 Atlant Security,为 EU 和中东地区的客户开展渗透测试、红队演练和 ISO 27001 就绪项目。他的文章聚焦现代合规的跨框架实践:如何把一项控制措施映射到多项义务,电子表格会在哪里失灵,以及审计师真正坐下来之后,监管机构实际要求的是什么。

查看 Alexander 的更多文章 →

相关文章