欧盟银行《数字运营韧性法案》合规差距评估

⚠️ DORA 差距评估 · 2026 年 3 月

执行日期过去十四个月后，监管观察揭示出持续存在的结构性差距。以下是各机构的风险暴露之处，以及应对之策。

⚠️ 监管背景

ECB 的《2025-2026 年监管优先事项》明确将 ICT 风险和数字运营韧性列为重点关注领域。EBA 对 DORA 实施情况的同行评审定于 2026 年第三季度进行。欧盟 27 国的各国主管机关已经发布了现场检查的初步结果。尚未解决这些差距的机构将面临监管行动，这并非理论上的可能，而是有着明确的监管时间表。

📋

差距 1：严重

信息登记册不完整

监管要求

欧盟《数字运营韧性法案》（DORA）第 28(3) 条要求金融实体维护一份完整的信息登记册（RoI），涵盖使用第三方服务提供商所提供 ICT 服务的全部合同安排。欧洲监管局（ESA）于 2024 年 1 月发布的实施技术标准（ITS）规定了确切的数据模型：15 个相互关联的模板，包含 100 多个必填字段，涵盖实体本身、ICT 服务提供商、合同安排、分包外包链、所支持的业务职能以及风险评估。

监管机构的发现：大多数机构都已经建立了登记册，但数据不完整、不一致，或者结构有误。最常见的缺陷包括：

• 缺少分包外包链。第 28(3)(a) 条要求实体不仅要识别其直接的 ICT 服务提供商，还要识别关键或重要职能的整个分包外包链。大多数银行只记录了一级服务提供商。当云服务提供商将数据托管或安全监控分包出去时，这条链在登记册中是看不到的。
• 实体标识符错误或缺失。ESA 的 ITS 要求提供 LEI 代码（如有）、使用 ESA 分类代码的实体类型，以及受监管实体的 NCA 标识符。许多登记册中只有自由文本形式的公司名称，没有结构化标识符，导致这些数据无法用于监管报告。
• 不具备 xBRL-CSV 导出能力。ESA 已规定 RoI 必须能够以 xBRL-CSV 格式报送，这是一种供监管报送系统使用的结构化、机器可读格式。在 Excel 或 SharePoint 中搭建登记册的机构，无法生成有效的监管报送文件。
• 业务职能映射存在缺口。每一项合同安排都必须与其所支持的业务职能以及关键或重要职能相关联。各机构经常把 ICT 服务提供商映射到部门，而不是映射到其自身 ICT 风险管理框架所定义的具体业务职能。

“信息登记册不是一项文档工作。它是 ICT 第三方风险监管所依赖的数据基础设施。不完整的登记册会削弱整个监管框架。”

EBA《关于 DORA 实施的讨论文件》，2025 年

为何持续存在：登记册的复杂程度极具迷惑性。各机构把它当作一项采购工作（列出您的供应商），而不是一项数据架构工作（用达到监管级别的数据为您的整个 ICT 供应链建模）。ESA ITS 数据模型要求 15 张表之间保持关系完整性，而这是电子表格无法强制实现的。

🏗️

差距 2：高风险

ICT 第三方集中度风险未被量化

监管机构的发现：集中度风险分析即使存在，也往往是定性的、流于表面的。各机构承认它们严重依赖少数几家云服务提供商（通常是 AWS、Microsoft Azure 和 Google Cloud），但并未开展 DORA 所要求的定量分析：

为何持续存在：集中度风险分析需要横跨采购、IT 架构、业务连续性和风险管理的数据。在大多数机构中，这些数据分散在由四个不同部门掌管的四个不同系统中。没有统一的 ICT 风险平台，这种分析在结构上就不可能完成。

🚨

差距 3：严重

事件分类标准未落地执行

监管机构的发现：各机构都有引用 DORA 的事件管理策略。它们也更新了事件响应程序，加入了向 NCA 报告的内容。但真正的分类，也就是实时判断某一事件是否越过“重大”门槛的运营机制，并没有嵌入工作流程：

• 阈值定义含糊。RTS 要求设定定量阈值（例如受影响客户的百分比、以小时计的持续时间、失败交易的数量）。大多数机构只以定性方式定义阈值（“相当数量的客户”），或者根本没有校准阈值。
• 报告时限未实现自动化。DORA 要求在分类后 4 小时内提交初始通知，72 小时内提交中期报告，一个月内提交最终报告。一旦某一事件被归类为重大事件，这些截止期限就必须自动触发。在大多数银行，时限管理靠手工完成，甚至根本不存在。
• 分类决策随意。SOC 分析师没有系统地应用七项标准测试，而是对严重程度做出主观判断。这会导致少报（以规避监管审查）或迟报（因为没有人确定是否达到了阈值）。
• 缺少对重复发生事件的汇总。第 19(4) 条要求，对于单独来看未达到重大门槛、但合起来构成显著模式的重复发生事件，必须予以报告。几乎没有机构实现了汇总逻辑。

“拥有事件响应策略，并不等于具备可运行的事件分类能力。监管机构检验的是后者，而不是前者。”

ECB《监管通讯》，关于 ICT 风险的观察，2025 年

为何持续存在：DORA 下的事件分类与传统的基于 ITIL 的严重程度模型有着根本区别。DORA 分类是一种具有法律后果的监管行为（强制报告、监管跟进、可能的处罚）。大多数事件管理工具是为 IT 运维打造的，而不是为监管合规打造的。

🛡️

差距 4：显著

韧性测试计划存在缺口

监管机构的发现：年度测试计划在纸面上是存在的，大多数机构早已开展了漏洞扫描和渗透测试。但 DORA 对测试计划的要求远远超出了既有的做法：

为何持续存在：脱节发生在安全测试（由 CISO 管理的技术工作）与 DORA 下的韧性测试（由管理机构监督的治理工作）之间。DORA 要求将测试计划纳入 ICT 风险管理框架，由董事会批准，并将其结果反馈到风险评估中。大多数机构从未把这些流程连接起来。

根据 Art. 30，ICT 合同中必须出现的 14 项以上强制条款：

监管机构的发现：差距巨大。大多数现有 ICT 合同都早于 DORA，是在 DORA 之前的监管框架（EBA《外包指引》、当地 NCA 的要求）下谈判签订的。合同整改计划（即系统性地修订现有合同、加入 Art. 30 条款的过程）要么尚未启动，要么进展过于缓慢：

• 大型超大规模云服务商的合同最难处理。各机构反映，AWS、Microsoft 和 Google 已经发布了部分回应 Art. 30 的“DORA 附录”，但这些标准化文件往往不能完全满足该法规的要求，尤其是在不受限制的审计权和分包外包审批方面。
• 没有逐条款跟踪。大多数机构没有系统化的方法来跟踪每份合同中包含了 14 项以上强制条款中的哪些。评估由法务团队逐份合同手工完成，没有任何结构化的数据输出。
• 续约时间不匹配。许多 ICT 合同的期限长达数年。各机构在等待合同续约时再引入欧盟《数字运营韧性法案》（DORA）条款，这使它们在续约日之前一直处于不合规状态，而续约日可能还要 2-3 年才会到来。

为何持续存在：大规模的合同整改是一项浩大的法务和采购工作。一家中型银行可能有 200-500 份 ICT 服务提供商合同。对照 14 项以上强制条款审查每一份合同，与可能抵制的服务提供商协商修订（尤其是在审计权和分包外包控制措施方面），并跟踪整改计划，这些都需要专门打造的工具，而不是一个法务团队加一张电子表格。

请使用下表，对照五个关键差距领域为贵机构做基准评估。请如实评估：监管机构也会如实评估。

这五个差距并非偶然。它们有一个共同的根本原因：各机构在彼此割裂的电子表格、文档和通用 GRC 工具中管理欧盟《数字运营韧性法案》（DORA）合规，而这些工具并不是针对 DORA 的具体要求打造的。Venvera 正是为解决这一问题而专门打造的。

了解监管日程，对于确定整改工作的优先顺序至关重要。以下是应当驱动您差距弥合时间表的关键里程碑：

“DORA 不是一部金融实体可以在纸面上合规、然后寄希望于监管机构不会注意到实际差距的法规。监管方法旨在检验运营实质，而不是文件形式。只有策略而没有能力的实体将被认定为不合规。”

基于 ECB 银行业监管优先事项和 EBA 指引的分析

监管评估正在进行

EBA 同行评审定于 2026 年第三季度进行。欧盟 27 国的各 NCA 目前正在开展现场检查。如果贵机构在这五个领域中的任何一个存在差距，在正式的监管检查发现出具之前进行整改的窗口期正在关闭。

Venvera 针对欧盟《数字运营韧性法案》（DORA）的差距评估，为您提供结构化的逐条视图，清楚显示您所处的位置，并给出一条清晰的整改路径，帮助您在监管机构到来之前弥合每一个差距。

关于本文

本分析基于 ECB、EBA 和各国主管机关公开发布的监管出版物，并结合了 Venvera 支持欧盟金融实体实现 DORA 合规的直接经验。所识别的五个差距领域反映了在多个司法管辖区和多种机构类型中观察到的规律。