合规指南
更正已于 2026 年 7 月 14 日更正。本文早期版本包含一段归属于“ESA guidance on DORA implementation”的引文，但我们无法找到来源；包含一项关于缺少强制条款合同占比的统计数据，但我们无法找到来源；包含一张“监管机构发现的问题”表格，但没有已发布依据；还包含一组指向错误条款的条文引用，其中包括声称 Article 29(1) 要求每年进行一次集中度评估，而事实上它要求的是合同签订前评估。上述内容均已删除，或已依据《官方公报》文本予以更正。条款数量已替换为实际结构：Article 30(2) 下适用于每一份 ICT 合同的九项要素，以及在服务支持关键或重要职能时 Article 30(3) 下额外适用的六项要素。
欧盟《数字运营韧性法案》（DORA）第 V 章，即第 28 条至第 44 条，涵盖 ICT 第三方风险。它分为两部分。第一节，即第 28 条至第 30 条，是金融实体必须完成的事项：信息登记册、合同签订前评估、集中度评估、强制合同条款以及退出策略。第二节，即第 31 条至第 44 条，是针对关键 ICT 第三方服务提供商的监督框架，属于监管机构一侧的安排，而不是您的义务。第 V 章是 DORA 中成本最高、也往往最晚启动的部分。信息登记册看起来像一项清单盘点工作，因此也常被按盘点项目来排期；在您必须通过从未被要求向任何人披露信息的服务提供商来映射分包外包链条之前，它一直显得很容易。
本指南涵盖第一节，以及其下的三项技术标准：用于信息登记册模板的 Implementing Regulation (EU) 2024/2956、用于支持关键或重要职能的 ICT 服务策略的 Delegated Regulation (EU) 2024/1773，以及用于分包的 Delegated Regulation (EU) 2025/532。
有一点值得尽早说明，因为它很容易混淆。Article 28(9) 要求制定实施性技术标准，后来形成了 ITS (EU) 2024/2956 中的信息登记册模板。Article 28(10) 要求制定关于第三方策略内容的监管性技术标准，后来形成了 Delegated Regulation (EU) 2024/1773。它们是不同的工具，承担不同的功能；如果按照错误的工具建立信息登记册，将无法导出。
📜
第五章，第一节
DORA 对 ICT 第三方风险的要求
第 28(1) 条确立了框架：金融实体“应将 ICT 第三方风险作为其 ICT 风险管理框架内 ICT 风险的组成部分进行管理”。正是这句话，使其不再是一个独立的供应商计划。相关义务随后贯穿 ICT 服务生命周期。
战略与策略（Art. 28(2)）
除微型企业以及 Art. 16(1) 所列实体之外，其他实体必须采用并定期审查 ICT 第三方风险战略，其中包括关于使用支持关键或重要职能的 ICT 服务的策略。管理机构“应定期审查与使用支持关键或重要职能的 ICT 服务的合同安排相关的已识别风险”。该策略的内容由 RTS (EU) 2024/1773 规定。
信息登记册（Art. 28(3)）
在实体层面以及次合并和合并层面，维护并更新一份信息登记册，涵盖使用 ICT 第三方服务提供商所提供 ICT 服务的所有合同安排，并区分支持关键或重要职能的安排与不支持此类职能的安排。
签署之前（Art. 28(4)）
评估该安排是否涵盖关键或重要职能；评估是否满足订立合同的监管条件；识别并评估所有相关风险，包括该安排是否会根据 Art. 29 加剧 ICT 集中度风险；对拟选服务提供商开展尽职调查；并识别和评估利益冲突。
安全标准（Art. 28(5)）
您只能与遵守适当信息安全标准的服务提供商签订合同。凡安排涉及关键或重要职能，您必须在订立安排前，充分考虑该服务提供商是否使用“最新且最高质量的信息安全标准”。
审计权及其行使（Art. 28(6)）
仅拥有审计权还不够。您必须基于风险，预先确定审计和检查的频率以及将被审计的领域。凡安排在技术上较为复杂，您必须核实审计师具备实际执行审计所需的技能。
终止与退出（Art. 28(7), 28(8)）
合同必须能够在 Art. 28(7) 列明的四种情形下终止。对于支持关键或重要职能的 ICT 服务，您必须制定全面、成文、经过充分测试并定期审查的退出战略。
第 28(3) 条实际要求您报告什么，以及向谁报告
年度报告义务的对象是您的主管机关，而不是直接向 ESA 报告，并且其范围窄于完整的信息登记册：实体“应至少每年向主管机关报告使用 ICT 服务的新安排数量、ICT 第三方服务提供商的类别、合同安排类型以及正在提供的 ICT 服务和职能”。此外，您必须应主管机关要求，提供完整的信息登记册或其中指定部分，并且必须及时告知主管机关任何关于支持关键或重要职能的 ICT 服务的计划合同安排，以及某项职能成为关键或重要职能的情形。
📝
第 30 条
合同条款：九项，另加六项
第 30 条是第五章中对运营影响最大的条款，而条款数量经常被错误表述。并不存在单一的“14 项条款”清单。实际上有两份清单。
Article 30(1) 位于前列，却很容易被忽视：双方的权利和义务必须“明确分配并以书面形式列明”，并且“完整合同应包括服务级别协议，并以一份书面文件记录”，该文件应可提供纸质版本，或以可下载、耐久且可访问的格式提供。若合同分散在未签署的订单表、网页条款和服务说明 PDF 中，这本身就已经是一个待发生的审计发现。
Article 30(2)：每份 ICT 合同必须包含的九项要素
| Art. 30(2) | 要素 | 必须包含的内容 |
|---|---|---|
| (a) | 功能和 ICT 服务的说明，以及分包外包安排 | 对所有功能和 ICT 服务作出清晰、完整的说明，并说明是否允许对支持关键或重要功能的 ICT 服务或其重要部分进行分包外包；如允许，还应说明适用条件。 |
| (b) | 服务提供地点和数据处理地点 | 已签约或分包外包的功能和 ICT 服务所提供的地区或国家，以及数据处理所在地，包括存储地点；并要求服务提供商如计划变更这些地点，须提前通知您。 |
| (c) | 数据保护条款 | 关于保护数据，包括个人数据的可用性、真实性、完整性和保密性的条款。 |
| (d) | 数据访问、恢复和返还 | 在服务提供商破产、处置、停止经营或合同终止时，确保能够以易于访问的格式访问、恢复并返还个人数据和非个人数据的条款。 |
| (e) | 服务水平说明 | 服务水平说明，包括对其作出的更新和修订。 |
| (f) | 无成本或按预先约定成本提供事件协助 | 当发生与服务相关的 ICT 事件时，服务提供商有义务以无额外成本或按预先确定的成本向您提供协助。 |
| (g) | 与主管机构合作 | 服务提供商有义务与您的主管机构和处置机构，包括其任命的人员充分合作。 |
| (h) | 终止权和通知期限 | 终止权以及相关的最低通知期限，应符合主管机构和处置机构的预期。 |
| (i) | 参与您的安全培训 | 服务提供商参与您的 ICT 安全意识项目和数字运营韧性培训的条件，应符合 Article 13(6)。 |
第 30(3) 条：服务支持关键或重要功能时的另外六项要素
这些是在上述九项之外的附加要求。
| Art. 30(3) | 要素 | 必须包含的内容 |
|---|---|---|
| (a) | 包含量化目标的完整服务级别描述 | 完整的服务级别描述，包括精确的定量和定性绩效目标，以便您有效监控，并在未达到约定级别时及时采取纠正措施，不得无故拖延。 |
| (b) | 通知期限和服务提供商报告义务 | 通知期限和报告义务，包括对任何可能实质影响服务提供商按约定服务级别交付服务能力的发展情况进行通知。 |
| (c) | 应急计划和安全措施 | 要求服务提供商实施并测试业务应急计划，并具备可提供适当安全水平的 ICT 安全措施、工具和策略。 |
| (d) | 参与 TLPT | 服务提供商有义务参与并充分配合您根据第 26 条和第 27 条开展的威胁导向渗透测试 (TLPT)。 |
| (e) | 持续监控权 | 持续监控绩效的权利：您、您委任的第三方以及主管机关拥有不受限制的访问、检查和审计权；有权在现场复制相关文件；在其他客户权利受到影响时，有权约定替代性的保证水平；服务提供商在现场检查期间予以配合；以及范围、程序和频率的详细信息。微型企业可约定将这些权利委托给由服务提供商指定的独立第三方行使。 |
| (f) | 包含强制过渡期的退出策略 | 退出策略，特别是强制性的适当过渡期，在该期间服务提供商继续提供服务，使您能够迁移至其他服务提供商或将服务转为内部提供。 |
第 30(4) 条增加了一项较为温和、但值得了解的要求：在谈判时，实体和服务提供商“应考虑使用公共机构针对特定服务制定的标准合同条款”。真正的争议预计会集中在 Article 30(3)(e)。不受限制的访问、检查和审计权，是大型服务提供商最强烈抵制的内容；他们的标准答复通常是共享审计报告和问卷。文本也预见到其中一部分情况，允许在其他客户的权利受到影响时采用替代的保证级别，因此请提前决定您会接受哪些替代方案以及理由。带着一个自己无法解释的模板进入谈判，结果往往就是接受对方提供的任何内容。
按合同而非按项目跟踪条款
这里的合规单位是单个合同安排。对范围内的每一项安排，逐一评估 15 个要素是存在、缺失还是部分满足。只有这张矩阵能告诉您整改待办的规模，以及应优先处理哪一份合同续约。我们不会告诉您通常有多大比例的合同不合格：我们没有这方面的公开数据，而且据我们所能查到的，其他人也没有。
📌
构建顺序
构建信息登记册
信息登记册是一个关系型数据模型，其结构由 Implementing Regulation (EU) 2024/2956 中 15 个官方模板确定，范围从 B_01.01 到 B_99.01。先构建数据模型，字段自然就会随之明确。我们在15 个官方模板指南中介绍这些模板本身。以下是从零开始到填充完成的信息登记册的实施顺序。
第 1 步
盘点每一项 ICT 第三方服务安排
信息登记册覆盖“由 ICT 第三方服务提供商提供的 ICT 服务使用相关的所有合同安排”（Art. 28(3)），其范围比“外包”一词所暗示的更广。可从采购和应付账款记录、软件资产清单以及访问日志开始。两个类别经常被遗漏：集团内部 ICT 服务提供商，信息登记册通过专门的集团内部模板处理；以及在采购流程之外由免费层级或业务条线自行购买的 SaaS。核对采购、应付账款与员工实际使用的软件，本质上是持续追踪的工作，而不是技术问题，而且进展会很慢。请预留数周的日历时间，并交给足够资深的人来负责，以便能够询问某个业务条线为何持有一份财务从未见过的合同。
来源：Art. 28(3)
第 2 步
确定哪些职能属于关键或重要职能，并记录原因
第 3 条第 (22) 款将其定义为“某项职能，一旦发生中断，将对金融实体的财务表现，或其服务和活动的稳健性或连续性造成重大损害；或者该职能的停止、有缺陷或失败履行，将对金融实体持续遵守其授权条件和义务，或适用金融服务法律下的其他义务造成重大损害”。这一判定几乎会驱动后续所有工作：哪些合同需要纳入第 30 条第 (3) 款的额外条款，哪些安排需要退出策略，以及哪些需要进行缔约前集中度评估。
来源：Art. 3(22), Art. 28(3)
第 3 步
逐条记录合同安排和条款
第 30 条第 (1) 款要求双方的权利和义务在一份包含服务水平协议的书面文件中“明确分配并以书面形式列明”。随后，依据第 30 条第 (2) 款的九项要素检查合同；如果该服务支持关键或重要职能，还要依据第 30 条第 (3) 款的另外六项要素进行检查。将每一项要素跟踪为已具备、缺失或部分具备。这种逐条款状态，正是告诉您补救待办事项实际位置的工作成果。
来源：Art. 30(1), 30(2), 30(3)
第 4 步
映射关键或重要职能的分包链条
如果服务提供商可能将支持关键或重要职能的服务分包，Delegated Regulation (EU) 2025/532 规定了您在签署前必须确定的事项、合同必须载明的内容，以及链条发生变化时的处理方式。这是新增义务最多的部分，下文设有专门章节说明。
来源：Art. 30(2)(a), 30(5); RTS (EU) 2025/532
第 5 步
开展签约前的集中度评估
第 29 条第 1 款并不是一项年度报告工作。它在您即将签署合同时发生约束：作为第 28 条第 4 款 (c) 项要求的风险识别的一部分，您必须考虑拟议安排是否意味着与不易替代的服务提供商签约，或就关键或重要职能与同一服务提供商或紧密关联的服务提供商保持多项安排。随后，您必须“权衡替代方案的收益和成本”。
来源：Art. 28(4)(c), Art. 29(1)
📈
第 29 条
集中度风险是一项签约前测试
第 29 条的标题是“实体层面的 ICT 集中度风险初步评估”，这个标题已经说明了核心要点。它由第 28(4)(c) 条触发，而该条位于“订立合同安排之前”的标题之下。这是您采购流程中的一道关口。它不是每年 12 月用电子表格做一次的事情。把它放在签署之前，是正确的设计，也是不容易落实的设计。采购部门承载这道关口，评估必须以商业交易推进的速度完成。应将其作为必需步骤嵌入批准工作流，因为交易谈妥之后才写出的评估，看起来就正是那样。
下面是文本要求您权衡的内容。
服务提供商的可替代性
第 29(1)(a) 条：拟议安排是否意味着“与不易替代的 ICT 第三方服务提供商签约”。可替代性是信息登记册评估模板中的一个字段，因此您在这里得出的结论必须被记录下来。
与同一或有关联的服务提供商存在多项安排
第 29(1)(b) 条：您是否最终会“就支持关键或重要职能的 ICT 服务提供，与同一 ICT 第三方服务提供商或与紧密关联的 ICT 第三方服务提供商订有多项合同安排”。请注意“紧密关联”：与同一集团的两家子公司签订两份合同，构成一个集中度。
您考虑过的替代方案
第 29(1) 条第二款要求您将“替代解决方案的收益和成本，例如使用不同 ICT 第三方服务提供商”，与您的数字韧性战略中的业务需求和目标进行权衡。输出结果是对所考虑替代方案的书面比较。
地点、第三国与破产法
第 29(2) 条要求您针对关键或重要职能，考虑如果服务提供商破产将适用的破产法，以及对紧急恢复您的数据的任何限制。如果服务提供商设立在第三国，您还必须考虑其对欧盟数据保护规则的遵守情况，以及该国法律的有效执行。
链条长度与您的监控能力
第 29(2) 条最后一款：如果安排规定了分包，您必须评估“潜在较长或复杂的分包链是否以及如何可能影响其全面监控所签约职能的能力，以及主管机关在这方面有效监督金融实体的能力”。
链条内部的集中度
RTS (EU) 2025/532 第 1(j) 条明确规定，您需要权衡的因素包括“支持关键或重要职能的 ICT 服务或其重大部分的提供，是否集中于某一 ICT 第三方服务提供商的单一分包商或少数此类分包商”。两个独立服务提供商依赖同一个分包商，构成单一依赖。
签署后如何保持有效
Article 28(2) 将持续性义务赋予管理机构，要求其“应定期审查已识别的、与使用支持关键或重要职能的 ICT 服务的合同安排相关的风险”。RTS (EU) 2025/532 Article 3(2) 要求，其服务提供商分包关键或重要服务的实体，针对业务环境变化开展相关风险评估，并“定期”进行，其中包括 ICT 威胁、ICT 集中度风险和地缘政治风险。两项规定均未设定固定的年度频率，因此，如果您在策略中主张每年一次，那就是您自己的承诺。
🔗
RTS (EU) 2025/532
分包：您的服务提供商的服务提供商
这是该制度中细节最多、认知度最低的部分。欧盟《数字运营韧性法案》（DORA）第 30 条第 (2)(a) 项要求，合同必须说明是否允许对支持关键或重要职能的 ICT 服务或其重要部分进行分包，以及在何种条件下允许。第 30 条第 (5) 项随后要求制定技术标准，以明确您必须确定和评估的事项。该标准是 Delegated Regulation (EU) 2025/532，其中包含三个动态组成部分。
1. 决策发生在签署之前
第 3 条第 (1) 款明确规定，金融实体“应在与 ICT 第三方服务提供商订立合同安排之前，决定该 ICT 第三方服务提供商是否可以将支持关键或重要职能的 ICT 服务或其重要部分进行分包外包”。只有在您评估确认第 (a) 至 (j) 点的十项条件均已满足后，才可以订立该安排。这些条件包括：服务提供商能够识别所有支持关键或重要职能的分包商并通知您；分包商向您和主管机关授予与服务提供商相同的访问权和检查权；您已评估分包商故障对您的韧性和财务稳健性的影响；您已根据第 29 条评估集中度风险；以及您已评估是否存在妨碍行使审计和检查权的障碍。
第 3 条第 (3) 款堵住了显而易见的漏洞：依赖服务提供商对其分包商所作的评估，“不得限制金融实体履行其法律和监管义务的最终责任”。
2. 合同必须明确的十二项内容
在允许对关键或重要服务进行分包的情况下，第 4 条第 (1) 款要求合同明确哪些服务可以分包以及适用条件，并列明以下所有事项。
| Art. 4(1) | 合同必须明确 |
|---|---|
| (a) | 服务提供商对其分包商交付的服务负责。 |
| (b) | 服务提供商必须监控所有支持关键或重要职能的分包 ICT 服务，以确保其对您的义务持续得到履行。 |
| (c) | 服务提供商就这些分包商对您承担的监控和报告义务。 |
| (d) | 服务提供商必须评估与现有和潜在分包商及其母公司所在地，以及服务提供地点相关的所有风险。 |
| (e) | 在相关情况下，分包商处理或存储数据的地点。 |
| (f) | 服务提供商必须在其与分包商签订的自身合同中明确这些分包商的监控和报告义务。 |
| (g) | 如果某一分包商未能履行其义务，服务提供商必须确保服务在整个分包商链条中的连续性。 |
| (h) | 服务提供商与其分包商的合同必须传导 DORA Art. 30(3)(c) 中的业务应急计划要求，并明确分包商必须达到的服务水平。 |
| (i) | 同一合同必须明确 DORA Art. 30(3)(c) 所指的 ICT 安全标准以及任何额外安全要求。 |
| (j) | 分包商必须向您以及主管机关和处置机关授予与 DORA Art. 30(3)(e) 中相同的访问、检查和审计权。 |
| (k) | 服务提供商必须将分包安排的任何重大变更通知您。 |
| (l) | 当 RTS 第 6 条或 DORA Art. 28(7) 中的条件得到满足时，您有权终止合同。 |
3. 您对链条的重大变更拥有否决权
第 5 条是最有可能改变您的服务提供商行为的条款。合同必须要求服务提供商在“充分提前”的时间告知您其分包安排的任何拟议重大变更，以便您评估该变更对您的风险以及服务提供商履行其义务能力的影响。合同必须包含“一个合理的通知期，金融实体应在该期限内批准或反对这些变更”。随后是第 5(3) 条：服务提供商“只有在金融实体已批准或在通知期结束前未反对这些变更后，方可实施其分包安排的重大变更”。这是该制度赋予您的最强杠杆，也很容易被浪费。批准窗口只有在有人负责接收这些通知落入的收件箱，并能够按照服务提供商的时间表评估变更时，才是真实有效的。现在就决定该负责人是谁，以及您对重大变更的常设测试标准是什么，否则通知期会在邮件无人阅读时届满。
如果您认定该变更超出您的风险容忍度，第 5(4) 条要求您在通知期结束前告知服务提供商并提出反对。第 6 条随后赋予您终止权，适用于服务提供商实施了您已反对的重大变更、在通知期结束前未经您批准即实施该等变更，或将合同未明确允许其分包的关键或重要服务进行了分包外包的情形。
难点在于数据来自哪里
该义务通过合同落实。RTS 第 3(1)(b) 条要求您在签署前已评估服务提供商“能够识别所有提供支持关键或重要职能或其重大部分的 ICT 服务的分包商，并向金融实体通知并告知这些分包商”。这是对服务提供商能力的尽职调查条件，也是您的杠杆。对于既有合同中缺少该条件的情况，RTS 第 4(2) 条要求为实现合规所必需的变更“及时且在可能的最早时间实施”，并记录计划时间表。大型服务提供商公开维护的子处理方页面可作为交叉核验，但它们可能在不通知的情况下变更，不能替代合同上的通知权。
🚪
Article 28(8)
退出策略：四项测试
支持关键或重要职能的 ICT 服务必须制定退出策略。该义务比“制定退出计划”更具体，其中每一部分都可以被测试。
退出必须能够在不发生三类情况的前提下完成
Article 28(8) 第二款要求实体能够退出，且“不干扰其业务活动”，不“限制对监管要求的合规”，并且不“损害向客户提供服务的连续性和质量”。这就是退出计划必须通过的三项测试。
计划必须经过测试
Article 28(8) 第三款：“退出计划应当全面、成文，并且按照 Article 4(2) 规定的标准，进行充分测试并定期审查。”未经测试的退出计划不符合该条要求。
必须识别替代方案并制定迁移计划
Article 28(8) 第四款要求您“识别替代解决方案并制定迁移计划，使其能够将已签约的 ICT 服务及相关数据从 ICT 第三方服务提供商处移除，并将其安全、完整地转移至替代服务提供商，或重新纳入内部”。
合同必须为您提供过渡期
Article 30(3)(f) 要求，涉及关键或重要职能的合同应包含退出策略，包括设立“强制性的适当过渡期”，在此期间服务提供商继续提供服务。如果您的合同没有过渡期，您的退出计划就是建立在服务提供商的善意之上。退出测试是最常被悄悄降级为桌面推演的要求；对于大型云依赖而言，这可以理解，因为真正的测试成本高且会造成干扰。可辩护的折中做法是演练您能够演练的部分，包括数据提取、恢复到替代方案、运行手册和决策路径，并准确记录哪些部分未测试以及原因。
Article 28(8) 还要求采取应急措施，以便在触发退出的情形发生时维持业务连续性，并将触发清单与 Article 28(7) 中的终止情形相衔接：服务提供商发生重大违约；通过监控发现可能改变履约情况的情形；有证据表明服务提供商的 ICT 风险管理存在薄弱环节；以及由于该安排，主管机关无法再对您进行有效监督的情形。
RTS (EU) 2024/1773 第 10 条将退出和终止纳入支持关键或重要职能的 ICT 服务策略，因此您策略中的退出内容也有了明确的位置。
⚡
工具
Venvera 的定位
所有这些都可以用电子表格来运行，对于少数几个服务提供商，实践中也常常如此。真正出问题的是完整性：登记册是关系型的，合同安排上的引用是一个键，其他多张表都会指向它，而电子表格无法阻止这些引用逐渐彼此脱节。Venvera 覆盖一系列框架，欧盟《数字运营韧性法案》（DORA）就是其中之一。以下是产品目前具备的第三方相关能力。
📚
ICT 服务提供商和合同登记册
将服务提供商、合同安排、分支机构、业务职能和风险评估作为相互关联的记录管理。合同承载合同编号、开始和结束日期、双方通知期限、适用法律、服务提供国家、数据位置和数据敏感性。
📋
第 30 条条款跟踪
每项合同安排都带有逐条款的第 30 条状态，因此缺少条款的合同会作为记录呈现，而不是只停留在记忆中。服务提供商风险评分会读取该状态，并在条款集不完整时下调该服务提供商的评分。
📈
集中度分析
按服务提供商统计支出集中度，并设置份额阈值标记；分析关键职能对单一或多个服务提供商的依赖；按国家和数据位置拆分；并对服务提供商支出计算 Herfindahl-Hirschman 指数并分档。
🔗
分包外包链条
针对分包商所属的安排记录分包商，并包含分包服务提供商的 LEI、国家、服务描述、数据位置、关键性以及链条中的层级。
🚪
退出和可替代性评估
服务提供商风险评估包含可替代性评分和理由、是否存在退出计划、再整合可能性、中止影响、已识别的替代服务提供商以及下次审查日期。合同则包含退出策略引用。
📋
供应商问卷活动
基于带框架标签的模板向服务提供商发送问卷活动，并跟踪每个服务提供商的状态、联系人和评分后的回复。
📊
登记册的 xBRL-CSV 导出
按 ITS (EU) 2024/2956 表结构导出，覆盖从 B_01.01 到 B_99.01 的全部 15 个官方模板，并在导出前呈现完整性评分和验证问题，而不是等门户拒收文件后才发现。
🔔
审计追踪
记录的变更会被记录下来，这会把“登记册得到维护”从一项陈述变成您可以展示的内容。
平台不会替您决定哪些职能属于关键或重要职能，也不会把 Article 30(3) 条款谈入一份您的服务提供商本不愿重新开启的合同。这些决定属于您。平台所做的是确保，一旦您作出这些判断，它们会记录在相应安排下，贯穿全年保留下来，并以信息登记册所要求的形式输出。
基于法规实际采用的数据模型构建 ICT 登记册。
将服务提供商、合同、职能、分包链和风险评估作为相互关联的记录，并内置第 30 条条款跟踪，以及按照 15 个官方模板构建的 xBRL-CSV 导出。
预约演示 →主要来源
- Regulation (EU) 2022/2554 (DORA)。第 3(22) 条，关键或重要职能的定义。第五章，第 28 至 44 条。第一节：第 28 条一般原则和登记册，第 29 条 ICT 集中度风险初步评估，第 30 条关键合同条款。第二节，第 31 至 44 条：关键 ICT 第三方服务提供商的监督框架。
- Commission Implementing Regulation (EU) 2024/2956。根据 DORA 第 28(9) 条，为信息登记册设定标准模板的 ITS。共 15 个模板，B_01.01 至 B_99.01。
- Commission Delegated Regulation (EU) 2024/1773。根据 DORA 第 28(10) 条，关于使用支持关键或重要职能的 ICT 服务之策略详细内容的 RTS。涵盖治理、生命周期阶段、事前风险评估、尽职调查、利益冲突、合同条款、监控，以及退出和终止。
- Commission Delegated Regulation (EU) 2025/532。根据 DORA 第 30(5) 条，关于金融实体在分包支持关键或重要职能的 ICT 服务时必须确定和评估的要素的 RTS。
- Commission Delegated Regulation (EU) 2024/1774。关于 ICT 风险管理工具、方法、流程和策略的 RTS，该框架即第 28(1) 条要求第三方风险纳入其中的框架。
本文仅供参考，不构成法律或监管建议。条文引用已于 2026 年 7 月 14 日根据《官方公报》文本核对。技术标准会随时间修订，因此在依赖本文所述任何要求之前，请确认当前有效版本。
