DORA 信息登记册 15 个模板详解

我想先坦诚说明一点：EBA、ESMA 或 EIOPA 并没有一份单一文件，能在一个地方告诉您关于 DORA 信息登记册需要了解的全部内容。相关要求分散在 DORA 主法规文本、联合技术标准、关于信息登记册的 ITS、xBRL 分类法文档、各 NCA 门户指南，以及 ESA 针对行业问题发布的一系列 Q&A 中，其中一些 Q&A 澄清了原始文本中确实存在模糊之处的内容。

这份指南，是我希望合规团队在开始准备首次提交时就能拥有的文档。它把所有内容汇总在一起：信息登记册到底是什么、谁必须提交、15 个官方模板各自需要哪些数据、模板之间如何关联、从开始到完成的提交流程是什么样，以及在首次提交完成后，全年维护应如何开展。

读完本文后，您将对 RoI 形成完整的心智模型，不只是足以填写模板，而是足以理解每个字段为什么存在、监管机构想看到什么，以及首次处理这项工作的团队容易踩到哪些坑。

什么是 DORA 信息登记册？

信息登记册（RoI）是欧盟《数字运营韧性法案》（DORA）的核心运营要求之一。它由 DORA 第 28(3) 条规定，详细技术规范则载于由 EBA、ESMA 和 EIOPA 联合发布的关于信息登记册的实施技术标准（ITS）。

RoI 的核心，是一份全面、结构化的记录，涵盖您的组织所依赖的每一家 ICT 第三方服务提供商，并精确映射这些服务提供商提供什么服务、哪些合同约束该关系，以及您的哪些内部业务职能依赖其服务。监管机构使用这些数据主要有两个目的：了解整个金融系统中的风险集中度（如果某一家云服务提供商发生故障，哪些机构会受到影响，严重程度如何？），以及评估单个机构的运营韧性和第三方风险治理情况。

同样重要的是理解 RoI 不是什么。RoI 不是：

• 供应商风险登记册，它不会记录每个服务提供商的风险分数、风险评级或风险缓解措施。这是另一项 DORA 义务。
• 合同管理系统，它会记录有关合同的特定结构化数据字段，但并不是合同本身的文档存储库。
• 合规控制措施框架，它不会跟踪您是否已实施所要求的 ICT 安全控制措施。这属于您在第 5-15 条下的 ICT 风险管理框架。
• 一次性审计材料，它是一份实时登记册，必须持续维护，并在发生重大变化时于规定时限内更新。

谁必须提交，按哪个层级提交？

DORA 第 28(3) 条要求该法规范围内的所有金融实体维护并提交信息登记册。受范围约束的实体完整清单见第 2(1) 条，包括：

微型企业是指欧盟法律下员工少于 10 人且年营业额低于 200 万欧元的实体，可适用欧盟《数字运营韧性法案》（DORA）中的比例性规定。比例性如何适用于信息登记册，取决于您的实体类型。因此，在决定需要提交哪些内容之前，请先查看 ESAs 的比例性指南以及您所在 NCA 针对具体情形的指引。

单体、次级合并与合并提交

对于金融集团，ITS 规定了三种可能的提交层级。在开始建立信息登记册之前，必须先了解哪一种适用于您的组织结构，因为答案将决定您需要收集的数据范围，以及集团内各实体在数据模型中的相互关系。

集团可能需要同时生成全部三个层级的提交：各实体的单体提交、子集团母公司的次级合并提交，以及最终 EU 母公司的合并提交。每一项提交都必须是一套连贯且自洽的数据包，并且能够独立通过验证。

数据模型：15 个模板详解

RoI 数据模型是这项要求的核心，也是大多数指南和模板解释得最不充分的部分。正确理解它，不只是了解每个模板包含什么，还要了解模板之间如何相互关联，正是首次就能正确构建信息登记册的团队与在重新提交循环中耗费数月的团队之间的区别。

在收集任何一个字段之前，请先花一天时间研究该模型。它是一个小型且容易掌握的架构，一旦您能在白板上画出这些关系，登记册的其余工作就会变成数据录入。跳过这一步的团队，收集的是他们手头刚好有的数据，而不是模板要求的数据，之后还得重新收集。

数据模型的主干，是您与 ICT 第三方服务提供商签订的一组合同安排。每项安排都有一个唯一参考编号，该参考编号是把其他模板连接在一起的关键。围绕这条主干，您需要记录每项安排由谁签署、您的哪些实体使用这些服务、服务背后的服务提供商及其供应链、这些服务支持的职能，以及您针对支持关键或重要职能的服务所作的评估。

该信息登记册由 Commission Implementing Regulation (EU) 2024/2956 规定的 15 个官方模板构成。其代码从 B_01.01 到 B_99.01，并按 B_ 后面的数字组织为多个分组：01（实体和范围）、02（合同安排）、03（签署方）、04（使用服务的实体）、05（服务提供商和供应链）、06（职能）、07（评估）和 99（定义）。

模板如何关联

每项合同安排（B_02.01）上的参考编号，是把信息登记册串联起来的主键。该安排的具体信息（B_02.02）挂接在同一参考编号之下，签署方记录（您方为 B_03.01，服务提供商方为 B_03.02，集团内部服务提供商为 B_03.03）以及哪些实体使用相关服务的记录（B_04.01）也是如此。每项服务均由 B_05.01 中识别的服务提供商交付，其背后的分包商链条在 B_05.02 中列明。贵组织运行的职能在 B_06.01 中编目，支持关键或重要职能的服务评估则位于 B_07.01。B_01.01 识别维护信息登记册的实体，B_01.02 和 B_01.03 描述集团范围和分支机构，B_99.01 保存您所依赖的定义。

这一链条中的每个引用都必须能够解析。只要有一个断开的链接，例如 B_02.02 中某项安排的参考编号在 B_02.01 中找不到匹配项，或者 B_07.01 中某项评估指向的服务提供商未出现在 B_05.01 中，整个提交都会在验证阶段失败。

关键概念：关键性、分包外包与职能

RoI 数据模型中有三个概念需要格外关注，因为它们是团队最常出错的地方，而且出错不仅会影响您的提交，也会影响您的底层合规状态。

关键或重要职能（CIFs）

DORA 下“关键或重要职能”的概念定义在 Article 3(22) 中，并直接关联 EBA 关于外包的指南。当某项职能的中断会实质性损害实体的财务表现，或损害其服务或活动的稳健性或连续性时，该职能即为关键或重要职能。

实践中，这意味着贵组织必须依据这些标准，对每项业务职能进行正式评估并形成文档。RoI 在职能模板（B_06.01）中记录这些评估的结果。常见错误包括：对关键性标签适用过窄（低估哪些职能符合条件，从而低估您的 ICT 依赖），适用过宽（对职能过度分类，造成不必要的报告范围），或者未记录每项分类背后的评估方法，监管机构会要求查看这些内容。

分包外包链条

Article 28(2) 要求金融实体识别并记录分包外包安排，即您的直接 ICT 服务提供商将部分服务分包给另一方的情形。供应链模板（B_05.02）捕捉这些信息，记录每项服务背后的分包层级。实践中，这意味着您不仅需要知道自己的服务提供商是谁，还需要知道他们的服务提供商是谁，至少对于支持关键或重要职能的安排而言是如此。

这是首次 RoI 提交中最常填写不足的部分之一，原因很明显：收集分包外包数据需要您的直接服务提供商披露其供应链信息，而他们可能不愿意分享。您在这里的杠杆来自合同：Article 30(2)(a) 要求安排中说明是否允许对支持关键或重要职能的 ICT 服务进行分包，如允许，则说明适用条件；Commission Delegated Regulation (EU) 2025/532 规定了这些条件必须覆盖的内容。有时被引用到这一点上的 Article 30(2)(h)，实际涉及的是终止权和通知期限，而不是供应链披露。行使这一权利仍需要时间，并且有时会引发争议。强烈建议尽早启动这项数据收集工作，理想情况下是在首次提交前 6 个月开始。

也要在内部设定预期。在遇到分包外包之前，信息登记册并不复杂；一旦进入分包外包，它就不再是数据问题，而是关系管理问题。大型服务提供商会用标准资料包回复，并且排队时间很长。小型服务提供商往往连自己的第四方都不够了解，无法作答。请按数月追踪来安排资源，而不是按数日录入数据来安排，并在此期间把披露义务写入您续签的每一份合同。

服务提供商-合同-服务-职能链条

RoI 中最重要的结构性概念是，每一项 ICT 安排都必须能够从服务提供商一路追溯到内部职能。这反映了监管机构真正的分析目标：针对任何给定的业务职能，准确了解您依赖哪些外部方，以及通过哪些合同关系形成依赖。如果您的数据中这条链在任何位置断裂，即使通过了技术验证，信息登记册也无法实现其目的。

提交流程

格式

RoI 必须以 xBRL-CSV 格式提交，这是一种由 XBRL International 标准定义，并由 ESAs 针对 DORA 制定概要的结构化、机器可读格式。您提交的是一个 ZIP 归档文件，其中包含数据模型中每个表的一份 CSV 文件。每个 CSV 都必须符合 ESAs 发布和更新的 XBRL 分类标准。该分类标准定义字段名称、数据类型、受控取值列表以及表之间的关系约束。

没有规定允许以 Excel 格式、PDF 或任何其他格式提交。NCA 门户只接受 xBRL-CSV ZIP。这是 DORA 最有实际影响的要求之一，这意味着使用 Excel 维护登记册的组织必须经过转换和验证流程，从而在导出阶段引入显著的错误风险。

时间安排和截止期限

年度提交截止期限因 NCA 而异。大多数 NCA 将截止期限设在每个日历年的第一季度，参考日期为上一年度的 12 月 31 日，这意味着您的登记册必须反映截至 12 月 31 日您的 ICT 安排状态。请查阅您所属 NCA 的具体技术指南，确认适用于您的实体类型和司法辖区的确切申报截止期限。

关键运营影响在于：如果您的数据收集流程尚未启动，就不能为了 3 月截止期限而到 1 月才开始建立登记册。仅分包外包数据的收集就可能需要数月。将 RoI 视为年终工作的组织，最终往往不是提交不完整数据，就是申请延期。

以 12 月 31 日为参考日期、第一季度截止期限，听起来时间充裕，直到您逐项计算步骤：收集、核对、让业务部门确认关键性、构建提交包、验证失败、修复、重新提交。真正稀缺的资源是其他人的注意力，而年初正是他们最难分给您的时候。

NCA 门户

每个 EU 成员国的 NCA 都运营自己的提交门户。门户要求注册，提交由授权用户完成，其身份与报告实体绑定。提交时，门户会运行其验证序列：提交包检查、分类标准符合性、引用完整性、受控值和业务规则，并返回回执确认，或返回包含每项失败对应错误代码的反馈文件。

全年维护义务

这是 RoI 最令合规团队意外的一点，尤其是那些习惯于将合规主要视为与审计周期绑定的时点性工作的团队。RoI 不是每年建立一次然后归档的东西。它是一份需要持续维护义务的动态登记册。

这里的解决方案更多是组织性的，而非技术性的，并且是整个工作中价值最高的决策：将登记册作为合同签署的强制步骤。如果采购部门在登记册字段未填写前无法完成新的 ICT 合同，维护就不再是一个项目，而会变成一种习惯。其他所有方法都依赖于有人记得去做。

第 28(3) 条要求金融实体在 ICT 安排发生重大变更时通知其 NCA。ITS 规定了重大变更后更新登记册的时间框架，而“重大”的定义比许多合规团队最初假设的更宽。以下事件均要求更新登记册：

实际影响是，RoI 需要由全年接入组织合同生命周期管理和采购流程的某个人，或某个职能来负责。若合规团队每年只接触一次信息登记册，往往会发现等到提交时它已不再反映实际情况，而在截止期限前几周补录更新会非常匆忙、容易出错，并且常常不完整。

首次构建时的常见错误

团队在首次构建信息登记册时，通常会遇到同一组结构性错误。以下是影响最大的几类错误，以及如何避免它们。

如果您只处理其中一个问题，请先处理第一个。选择记录系统这件事，往往是在第一周随意做出的一次性决定，但随后整个项目期间都要承受其后果。

对于那些不是在构建过程中、而是在提交之后才暴露的错误，请参阅信息登记册为何反复被拒，其中说明了 NCA 实际返回的验证失败情形。

工具和方法

如果您是在比较产品，而不是自行构建，我们在DORA 信息登记册软件排名中对各项选择进行了排名。

组织在构建和维护信息登记册时，通常有三大类方法。每种方法的风险特征不同，正确选择取决于您的登记册规模和复杂性。

一旦您不再只是维护一个小型、简单的信息登记册，专用平台的价值很快就会变得很有说服力。对 RoI 最重要的具体功能包括：强制执行表之间的引用完整性、自动化 GLEIF LEI 校验、对受控值字段设置硬性约束、在打包前运行当前 EBA 校验规则的 xBRL-CSV 导出，以及对全年所做更新进行审计追踪管理。这些并非锦上添花的功能，而是区分“为提交而构建的登记册”和“看似完整、直到 NCA 门户告诉您并非如此的登记册”的关键能力。

管理多个法律实体？了解 Venvera 如何处理集团公司合规软件：在母公司一次性编写策略，并让每家子公司用自己的证据加以证明。登记册也是决定您时间安排的项目，因此它会主导DORA 合规需要多长时间。

常见问题