合规指南
差距评估只有在能告诉您两件事时才有用：您距离法规实际要求还有多远，以及应先修复什么。本指南为这两点提供了一个模型，并将每个领域锚定到其来源条文。
欧盟《数字运营韧性法案》（DORA），即 Regulation (EU) 2022/2554，已自 2025 年 1 月 17 日起适用。它并未规定差距评估方法、成熟度等级或评分方案。这些由您自行选择。它确切规定的是您用来评分的实质内容，而这些内容分布在该法规的七个领域和三项技术标准中。
因此，本文将通常被混在一起的两件事分开。模型是我们的：覆盖七个领域的四级量表，然后进行加权。凡出现该模型之处，我们都会标明为编辑性内容。它衡量的要求并非由我们制定，以下每个条文编号、截止期限和数量均引用自法规或技术标准，并在文末列明出处。
| 管辖法律 | Regulation (EU) 2022/2554（DORA）。自 2025 年 1 月 17 日起适用。共有 64 条。 |
| 适用范围主体 | 第 2(1) 条列明的金融实体。部分义务，包括第 24 条中的测试计划，适用于微型企业以外的金融实体。 |
| 详细规则 | Commission Delegated Regulation (EU) 2024/1774（ICT 风险管理）、Commission Delegated Regulation (EU) 2025/301（事件报告内容和时限）以及 Commission Implementing Regulation (EU) 2024/2956（信息登记册）。 |
| DORA 是否要求开展差距评估？ | 并未使用这些措辞。第 6(5) 条要求 ICT 风险管理框架形成文件，并至少每年审查一次；此外，在发生重大事件后，以及根据监管指令或测试、审计结论，也需要审查。差距评估是大多数实体进行该审查的方式。 |
| 以下评分模型是否为规定要求？ | 不是。1 到 4 的量表、七个领域的划分以及权重均由我们设定。您可以使用，也可以替换。 |
差距评估通常在哪里出错
将“存在”与“充分”混为一谈。问“您是否有 ICT 风险管理框架？”，并记录“有”，并不能说明它是否符合 DORA。为早期外包制度编写的框架，可能完全没有涉及第 29 条下的 ICT 集中度风险、第 28(8) 条下的退出策略，或第 6(8) 条要求的数字运营韧性策略。基于是否存在的评分会带来虚假的安全感。
只为策略层评分，却跳过运营输出。DORA 有一些输出要么存在，要么不存在：信息登记册必须能够通过 ITS 所设格式的校验，事件报告必须在固定小时数内向外报送。只阅读策略的评估无法告诉您是否能够产出其中任何一项。
只产出一份清单。整改能力是有限的，如果差距清单没有紧急程度层级，就很难采取行动。这就是为什么以下模型会在制定任何计划之前先对各领域进行加权。
两个不同的问题。将您的控制措施映射到控制措施库并衡量实施情况，可以提供审计就绪度视图。这一点有价值，但并不能说明您是否能够提交有效的信息登记册，或是否能满足报告时限。这两个维度会相互独立地失效，因此应分别评分。较高的控制措施实施率并不能说明提交内容是否会通过验证。
成熟度等级
共四个等级，足以区分具有实质差异的状态，同时避免创造证据无法支撑的精确性。明确说明：这个等级由我们设定，并非监管机构设定。DORA 并未定义成熟度等级。使评分具备可辩护性的关键在于，第 3 级锚定到具名条款，并且您能够提供相应证据。
| 评分 | 等级 | 定义 |
| 1 | 初始 | 没有结构化方法。要求未知、尚未启动，或以临时方式处理，缺乏文档、负责人或可重复性。整改意味着从零开始建设。 |
| 2 | 发展中 | 已有某些内容，但未完全满足要求。覆盖范围不完整，文档较薄弱，或该方法从未演练过。 |
| 3 | 已定义 | 按文本要求得到满足，已形成文档并得到维护，且您可以按要求提供证据。这是基线，仍有更高成熟度可达到。 |
| 4 | 已嵌入 | 已满足、已演练或已审计，并具有效性证据和可运作的改进闭环。Article 6(6) 已要求该框架接受内部审计；4 分意味着该审计确认其有效运行。 |
七个领域及其评分
每个领域都会列出衡量所依据的条款，并定义每个评分的含义。下文引用的每一个数字，无论是截止期限、数量还是频率，都来自法规或技术标准。在开始之前，请明确一点：七个领域在投入工作量上远非相等。D6 是一个下午的工作，而且这个下午的大部分时间是把一项决策写下来。D1 和 D7 是您可以端到端控制的起草和会议记录工作。D2、D4 和 D5 才是会消耗数月的部分，因为这三项都依赖您团队之外的人回复您：服务提供商、律师，以及负责非工作时间值班表的人。
D1. ICT 风险管理框架
第 5 条至第 15 条
Article 6(1) 要求建立健全、全面且有充分文档记录的 ICT 风险管理框架。Article 6(5) 要求该框架形成文档并至少每年一次进行审查，并且在发生重大 ICT 相关事件以及根据监管指令或测试、审计得出的结论时，也应进行审查。Article 6(6) 要求其接受内部审计。Article 6(8) 要求其包含数字运营韧性战略，而 Article 5(2)(d) 将该战略的批准，包括 ICT 风险容忍水平，交由管理机构负责。
| 评分 | 实际表现 |
| 1 | 尚未依据 DORA 评估任何框架。为其他监管制度建立的框架从未与第 5 条至第 15 条进行比较。 |
| 2 | 已有框架，但与法规文本相比存在重大差距。典型情况包括：没有第 6(8) 条要求的数字运营韧性战略，没有成文的 ICT 风险容忍水平，或没有第 6(5) 条要求的年度审查证据。 |
| 3 | 已形成覆盖第 5 条至第 15 条的成文框架，包括第 6(8) 条战略和已定义的风险容忍水平，并有年度审查证据和管理机构批准会议记录。 |
| 4 | 该框架已根据第 6(6) 条接受内部审计，第 6(7) 条下用于整改关键 ICT 审计发现的跟进流程正在运行，且改进可追溯至经验教训。 |
最常见的薄弱点：将第 6(8) 条数字运营韧性战略作为单独获批的成果物，而不只是一个章节标题；第 6(8)(b) 条下的 ICT 风险容忍水平；以及第 6(7) 条针对关键 ICT 审计发现的正式跟进流程。
D2. ICT 事件管理与报告
第 17 条至第 23 条，以及 RTS 2025/301
第 17 条要求建立 ICT 相关事件管理流程，第 18 条规定分类标准。第 19(4) 条要求提交初始通知、中期报告和最终报告，但并未设定时限：它将时限交由技术标准规定。这些时限载于Commission Delegated Regulation (EU) 2025/301第 5(1) 条，也是 DORA 中最常被误引的数字。您需要诚实评估第一个计时要求会如何影响运营模式。撰写通知是容易的部分。难点在于，无论哪一天、哪个小时，分类、签批和提交都必须在四小时内完成，这意味着有权作出分类的人必须在夜间也能联系到。这是一个人员配置决策，也正是运行手册看似完成时，常常被悄然搁置未决的问题。
| 评分 | 实际表现 |
| 1 | 没有 DORA 专用分类。现有 ITSM 严重性模型从未与第 18 条标准进行比较。 |
| 2 | 分类标准已完成映射，但未嵌入流程。团队知道截止期限，但没有经过测试的工作流，无法在办公时间之外产出四小时内的初始通知。 |
| 3 | 在事件流程中设有成文且与 DORA 对齐的分类程序；通知模板已准备；四小时和 72 小时工作流已定义；并明确了凌晨三点也能执行该流程的人员。 |
| 4 | 该流程已通过桌面演练或真实事件进行演练。事后复盘会反馈到程序中，并且您会衡量分类准确性以及距离各项截止期限的接近程度。 |
最常见的薄弱点：能够承受四小时时限的非工作时间升级路径；以及第 19(2) 条下对重大网络威胁的自愿通知，这一点经常被完全遗漏。
把时间算准。RTS 2025/301 第 5(1) 条规定了三个截止期限，而中间那个经常被错误表述：
- 初始通知：“自 ICT 相关事件被分类为重大 ICT 相关事件起四小时内，且最迟不超过金融实体知悉该 ICT 相关事件之时起 24 小时”。
- 中期报告：“最迟在提交初始通知后的 72 小时内”。
- 最终报告：“最迟在提交中期报告后一个月内，或在适用情况下，在提交最新更新的中期报告后一个月内”。
72 小时是中期报告的截止期限。如果您的运行手册另有说法，这本身就是一项审计发现。
D3. 数字运营韧性测试
第 24 至 27 条
第 24(1) 条要求金融实体（微型企业除外）将测试计划作为 ICT 风险管理框架的组成部分。第 24(6) 条要求至少每年对所有支持关键或重要职能的 ICT 系统和应用开展适当测试。第 24(4) 条要求测试由内部或外部独立方执行。第 25(1) 条列出了该计划可采用的测试类型。第 26(1) 条项下的威胁导向渗透测试 (TLPT) 至少每三年开展一次，但仅适用于主管机构已根据第 26(8) 条识别出的实体。
| 评分 | 表现形式 |
| 1 | 没有 DORA 范围内的计划。虽然会开展渗透测试，但从未映射到关键或重要职能。 |
| 2 | 测试按计划开展，但其范围从未正式关联到其应覆盖的职能，且审计发现未跟踪至关闭。 |
| 3 | 有成文计划，范围覆盖支持关键或重要职能的系统，满足第 24(6) 条至少每年的要求，按照第 24(4) 条使用独立测试人员，并对审计发现进行跟踪，同时就第 26 条 TLPT 是否适用形成书面立场。 |
| 4 | 已完成 TLPT，或在根据第 26(8) 条被识别的情况下已有路线图。第 24(5) 条关于确定优先级、分类和补救问题的程序可证明正在有效运行，且结果会反馈至风险框架。 |
最常见的薄弱环节：关于实体是否已根据第 26(8) 条被识别为需开展 TLPT 的书面且注明日期的判断，许多实体根本从未作出该判断；以及从测试计划范围回溯到其应覆盖的关键或重要职能的可追溯性。
D4. ICT 第三方风险管理
第 28 至 30 条
第 28 条要求就 ICT 服务的使用制定战略和策略。第 28(8) 条要求针对支持关键或重要职能的 ICT 服务制定退出策略。第 29 条要求对 ICT 集中度风险进行初步评估，包括服务提供商是否不易替代。第 30(2) 条列明了每项 ICT 合同安排必须包含的要素，第 30(3) 条则在服务支持关键或重要职能时增加了进一步要素。这是对自身时间表控制最少的领域。按第 30 条逐项审阅合同是可以规划的案头工作。让大型服务提供商接受其去年未向您提供的审计权、数据地点承诺和终止条款，则属于谈判，而较小实体在其中几乎没有议价能力。请在合同审查完成前就开启这些沟通，因为审查完成会远早于交易对手回复。
| 评分 | 实际表现 |
| 1 | 没有针对欧盟《数字运营韧性法案》（DORA）的 ICT 第三方策略。供应商管理从未与第 28 条至第 30 条进行对比，合同也未按第 30 条进行审查。 |
| 2 | 策略已起草，合同审查正在进行但尚未完成，且对关键或重要安排没有形成书面的退出策略。 |
| 3 | 策略已批准；已确认各项安排均包含第 30 条第 (2) 款要素，且在服务支持关键或重要职能时包含第 30 条第 (3) 款的附加要素；已根据第 29 条评估集中度风险；已根据第 28 条第 (8) 款记录退出策略。 |
| 4 | 服务提供商监控已上线，退出策略已经演练而不只是写在纸面上，标准合同模板默认包含第 30 条要素。 |
最常见的薄弱环节：对 DORA 适用前签署的存量合同进行第 30 条审查；以及已经实际测试过的退出策略。还要注意数量：第 30 条第 (2) 款列出九项要素，即 (a) 至 (i) 点，第 30 条第 (3) 款随后针对关键或重要职能增加更多要求。任何声称“第 30 条第 (2) 款有 12 项强制性条款”的来源，都是数错了。
D5. 信息登记册
第 28 条第 (3) 款，以及 ITS 2024/2956
第 28 条第 (3) 款要求在实体、次合并和合并层面维护并更新登记册，覆盖所有关于使用 ICT 服务的合同安排。其结构来自Commission Implementing Regulation (EU) 2024/2956：15 个模板，编码从 B_01.01 到 B_99.01。这里要对两件事评分，因为它们会彼此独立地失败：数据是否完整，以及您是否真的能够生成一份可通过校验的提交文件。ITS 起草得非常精确，这一点有利也有弊。提交文件要么通过校验，要么不通过，因此无法用漂亮的叙述来掩盖字段内容不足。填报您自己的合同需要几周细致工作。填报这些合同背后的供应链，则需要一个月去追催那些没有义务按您的时间表行动的服务提供商。
| 评分 | 实际表现 |
| 1 | 没有登记册。服务提供商数据存放在电子表格或供应商系统中，未映射到 ITS 模板。 |
| 2 | 已部分填充。通常 B_05.02 中的供应链和 B_02.02 中的合同细节最薄弱，且尚未端到端运行过导出。 |
| 3 | 全部 15 个模板均已填充，模板之间的引用完整性保持有效，并且已在提交前生成并校验数据包。 |
| 4 | 全年持续维护，而不是每年重新构建；合同事件会触发更新，LEI 有效性受到监控，提交文件可一次通过校验，无需反复重新提交。 |
最常见的薄弱环节：B_05.02，即 ICT 服务供应链，分包外包就在这里体现，而且它几乎总是一开始就不完整，因为它依赖服务提供商必须交给您的数据。一个陷阱是：使用“B00 到 B14”编号的指南并不是在描述 ITS。真实编码范围是 B_01.01 到 B_99.01。
D6. 信息共享
第 45 条
第 45(1) 条规定，金融实体可以在可信社群内交换网络威胁信息和情报。这是允许性规定，而非强制性规定。但仍应评分，因为记录在案的决定几乎不产生成本，而未记录的缺失看起来会像疏忽。
| 评分 | 具体表现 |
| 1 | 不了解第 45 条，也未评估可用安排。 |
| 2 | 已评估第 45 条，已识别相关安排，并已记录参与决定，但尚未采取行动。 |
| 3 | 积极参与至少一项安排，并有流程用于接收并处理所收到的信息。 |
| 4 | 不仅接收，也主动贡献，且情报会输入事件响应和测试计划的范围。 |
最常见的薄弱点：没有结构性问题。这是唯一一个领域，在有书面记录的前提下，作出有理由的不参与决定也是合法答案。
D7. 治理和管理机构问责
第 5 条
第 5(2) 条要求管理机构对与 ICT 风险管理框架相关的所有安排进行定义、批准、监督并对其实施负责，随后在 (a) 至 (i) 项列明其具体职责。第 5(4) 条要求成员主动保持足够的最新知识和技能，以理解和评估 ICT 风险，包括定期参加专门培训。
| 评分 | 具体表现 |
| 1 | DORA 职责未在管理机构层面分配。ICT 风险仅按运营方式处理，没有董事会问责。 |
| 2 | 董事会知情并接收 ICT 风险报告，但其批准没有形成文档，也未开展培训。 |
| 3 | 第 5(2) 条职责已履行并有证据：根据 (d) 批准韧性战略，根据 (e) 批准 ICT 业务连续性策略以及响应和恢复计划，根据 (f) 批准 ICT 内部审计计划，根据 (g) 批准预算，根据 (h) 批准 ICT 第三方策略，并根据 (i) 建立报告渠道。第 5(4) 条项下培训已经开展。 |
| 4 | 会议纪要显示董事会对 ICT 风险报告提出质询，而不仅是知悉；已完成技能评估并采取行动；问责落实到具名个人。 |
最常见的薄弱点：记录在案的批准与记录在案的知情相区别；第 5(4) 条项下董事会成员的培训记录；以及第 5(2)(g) 条项下的预算职责，这是一项具体义务，而不是一般性愿景。
权重：我们的判断及其背后的理由
在每个领域都完成评分后，需要对差距加权。这里我们必须坦诚：我们没有关于哪些领域会引起执法关注的监管数据，任何诚实的人也没有。DORA 自 2025 年 1 月才开始适用，目前没有已发布的执法结果体系可用于归纳。因此，下列权重并非关于监管机构关注重点的主张。
它是一项判断，基于文本唯一能让您推理的一点：某项失败的可见性和时间约束程度。错过报告截止期限和被拒绝的信息登记册提交，都是在固定时钟下对外可见的。薄弱的风险框架则是在更长周期内接受监管评估的问题。驱动权重的是这种不对称，而不是对检查优先事项的猜测。
| 领域 | 我们的权重 | 原因 |
| D2 事件报告 | 关键 | 4 小时的时限，要么按时完成，要么错过，而错过从机制上就会被监管机构看到。 |
| D5 信息登记册 | 关键 | 结构化提交要么通过验证，要么不通过。失败模式是二元的，并且可被外部观察到。 |
| D4 ICT 第三方风险 | 高 | 第 30 条的合规性可以通过阅读合同来核验，因此差距很容易被确认，也很难辩解过去。 |
| D7 治理 | 高 | 第 50(5) 条允许成员国在其国内法约束下，将行政处罚和补救措施扩展至管理机构成员。 |
| D1 ICT 风险管理 | 中 | 这是基础，其他所有工作都建立其上，但其评估周期比提交截止期限更长。 |
| D3 测试 | 中 | 第 24(6) 条规定了明确的年度义务，但 TLPT 仅适用于第 26(8) 条下确定的实体。 |
| D6 信息共享 | 较低 | 第 45 条是许可性规定。一份有记录的决定就是充分答复。 |
不同意某个权重？可以改。把推理写在数字旁边，就是为了让您能质疑它。如果您无法向自己的董事会解释某个权重，就不值得把它带进董事会会议。
从评分到工作顺序
现在，每个领域您都有两个数字：它低于 3 分的程度，以及它的权重。把两者交叉起来看。
如果您想在看矩阵之前先得到一条指令：先修复信息登记册导出和非工作时间报告路径。相对于后果而言，这两项成本都很低，都可以由一个小团队完成而无需等待其他人，并且一旦失败，监管机构会在同一周看到。单薄的框架文件拖延一个季度，楼外可能没人注意到。错过时限则不可能。
| 权重 ↓ / 评分 → | 评分 1 | 评分 2 | 评分 3 或更高 |
| 关键 | 立即处理。现在提交给管理机构，并附带注明日期的计划。 | 紧急。本季度内关闭。 | 维护并提供证据。 |
| 高 | 紧急。本季度内关闭。 | 计划中。下季度。 | 维护并提供证据。 |
| 中或更低 | 计划中。下季度。 | 路线图。 | 持续维持。 |
有一条规则值得硬编码：在关键或高权重下评分为 1 的领域，应附带有时限的计划提交给管理机构，而不是进入待办列表。第 5(2) 条规定董事会要对这些差距所处的框架负责，因此，未报告的关键差距是在技术问题之上叠加的治理失败。
何时再次运行
您不需要自行设计节奏。第 6(5) 条已经给出了节奏。该框架必须形成文件并至少每年一次进行审查，此外还应在以下情况下审查：
- 发生重大 ICT 相关事件时。重大事件既是对 D2 的实战测试，也表明 D1 可能存在一些纸面上看似无问题的缺口。
- 在监管指令之后。这是文本中的明确要求。
- 在相关数字运营韧性测试或审计流程得出结论之后。测试结果是框架审查的一项输入。
还有两个触发因素值得加入，并不是因为该条文本点名了它们，而是因为它们会改变您底层答案：一是 ICT 服务提供商格局发生重大变化，这会影响 D4 和 D5；二是技术标准修订，这可能改变某个领域中 3 分本身的含义。
常见问题
DORA 是否要求进行差距评估？
并不以这个名称要求，DORA 也从未使用这一表述。第 6(5) 条要求的是，ICT 风险管理框架应形成文件并至少每年审查一次，并且还应在发生重大 ICT 相关事件时，以及在监管指令之后或根据数字运营韧性测试或审计流程得出的结论之后进行审查。差距评估通常是执行并证明该项审查的工具，但义务本身是审查。
本文中的 1 到 4 成熟度量表是监管要求吗？
不是。DORA 没有规定成熟度量表、评分模型或权重方案。这里的四级量表、七个领域划分和权重是我们的编辑模型，之所以提供，是因为您需要某种一致的工具来比较各领域。不是编辑性内容的是每个 3 级所锚定的内容：您可能被要求提供证据的具体条款。您可以自由替换自己的量表。但不要替换底层条款。
DORA 事件报告的实际截止期限是什么？
它们不在 DORA 本身中。第 19(4) 条列明了三项提交内容，并将时间限制交由技术标准规定。Commission Delegated Regulation (EU) 2025/301 第 5(1) 条规定了这些期限：初始通知应在将事件分类为重大事件后四小时内提交，且不迟于知悉该事件后 24 小时；中期报告最迟应在初始通知后 72 小时内提交；最终报告应不迟于中期报告后一个月提交，或者在适用情况下，不迟于最新更新的中期报告后一个月提交。请注意，72 小时对应的是中期报告。它非常常见地被错误报道为最终报告期限。
第 30(2) 条要求多少项合同条款？
九项。第 30(2) 条列出了 (a) 至 (i) 项：对职能和 ICT 服务以及分包条件的描述；服务提供和数据处理地点；数据保护条款；关于访问、恢复和返还数据的条款；服务水平描述；事件协助义务；与主管机关合作；终止权和通知期限；以及参与实体的 ICT 安全意识和韧性培训。第 30(3) 条随后在安排支持关键或重要职能时增加了进一步要素。对一份包含 12 项“第 30(2) 条条款”的清单进行差距评估评分，实际上是在针对法规中并不存在的清单进行评分。
我们可以将 ISO 27001 评估复用于 DORA 差距评估吗？
可以部分复用，而且边界很清晰。ISO 27001 评估会为 D1 和 D3 提供真实信号，因为底层安全管理实质存在重叠。它对 D5 没有帮助，因为信息登记册是由 EU 实施条例定义的报告制品，并没有 ISO 对应物。它对 D4 中 DORA 特有的部分没有帮助，尤其是第 30 条合同要素；对 D2 中第 18 条分类标准和报告计时也没有帮助；对 D7 中第 5(2) 条管理机构职责也没有帮助。真正重叠的部分可以复用，其余部分则应按条款进行评估。
我们应该以什么分数为目标？
每个领域达到 3 分，意味着您按文本要求满足了要求并能够提供证据，这就是该法规实际设定的门槛。在失败具有时间限制且对外可见的领域，应争取达到 4 分，按我们的权重，这意味着 D2 和 D5。但比任何数字都更重要的目标是：不得有任何领域停留在 1 分，且没有提交给管理机构的、带日期的计划。
主要来源
本文中的每一个条款编号、截止期限和数量均已根据以下文本核对。在依赖某一具体段落之前，请确认当前版本。
- Regulation (EU) 2022/2554 (DORA)：第 5、6、17 至 19、24 至 27、28 至 30、45 和 50 条。该法规共有 64 条，自 2025 年 1 月 17 日起适用。
- Commission Delegated Regulation (EU) 2025/301：第 5(1) 条规定了 4 小时、72 小时和 1 个月的报告截止期限。
- Commission Implementing Regulation (EU) 2024/2956：关于信息登记册的 ITS，规定了 B_01.01 至 B_99.01 的 15 个模板。
- Commission Delegated Regulation (EU) 2024/1774：关于 ICT 风险管理工具、方法、流程和策略的 RTS。
在 Venvera 中运行评估
Venvera 提供差距评估模块，有必要明确说明它的作用。它针对某一框架运行带评分的评估，生成总体分数，并将每一个差距转化为补救计划，计划包含优先级、负责人和截止日期，因此输出的是一个可跟踪的计划，而不是一份悄悄过时的电子表格。它目前覆盖 DORA 和 NIS2，DORA 评估提供完整版本和微型实体版本。这就是边界，我们更愿意把边界说清楚，而不是暗示范围更大。
DORA 是大多数金融实体同时承担的多个制度之一，相关工作高度重叠。框架映射引擎的存在，是为了让您已经完成一次证据化的控制措施，可以满足 NIS2 或 ISO 27001 下的对应要求，而不必从零重建。若想在承诺投入之前更快了解自身所处位置，请运行一次免费合规检查。
最后更新：2026 年 7 月。本文为一般信息，不构成法律建议。本文中的成熟度量表、七个领域划分和权重是 Venvera 的编辑模型，并非监管要求。请根据现行文本和您主管机构的指引确认条款引用。
监管机构已经在开展评估，因此在评估到来之前，值得先了解DORA 监管评估实际要求提供什么。获得分数后，接下来的两个问题通常是预算和时间表：请参阅DORA 的成本以及从您当前状态达到 DORA 合规需要多长时间。
