合规指南
Digital Operational Resilience Act，即 Regulation (EU) 2022/2554，自 2025 年 1 月 17 日起已全面适用。它是条例而非指令，因此其实质要求无需通过成员国国内转化，即可直接适用于所有 EU 成员国。存在差异的是监管方式：DORA 由已经监管您所属实体类型的国家主管机关（NCA）执行，并与三家欧洲监管机构（EBA、ESMA 和 EIOPA）协同开展工作。
DORA 下的监管接触，是主管机关运用 DORA 授予其权力开展的常规工作：审查您的 ICT 风险管理框架，检查您的信息登记册，测试您的事件报告和韧性安排，并在发现差距时跟进。第 50 条列明了这些权力，包括访问任何相关文件或数据、开展现场检查、传唤代表作出说明，以及要求采取纠正和补救措施的权利。
本文将说明 DORA 监管如何组织、审查流程通常包括哪些内容、监管机构会依据法规各部分检查什么、处罚制度实际如何运作，以及如何做好准备。如果某项具体执法金额或监管统计数据无法对应到法规或官方来源，我们宁可不写，也不会猜测。有关监管机构可检查的权力和固定周期的更简短逐条解读，请参见DORA 审计：应预期什么。
信息登记册已开始运行
欧洲监管机构在 2024 年对信息登记册开展了自愿试运行，近 1,000 家金融实体通过其主管机关提交了登记册。正式报告已于 2025 年开始。根据 DORA，主管机关从其监管的实体收集登记册，开展数据质量检查，并作为通往欧洲监管机构的入口。因此，一份完整且可导出的信息登记册，通常会是大多数监管机构首先查看的内容。如果您想用一个指标判断后续审查会如何开展，就是它。登记册是唯一可被机械化检查的 DORA 成果物，因此在任何人对您形成判断之前，其中的差距就会先暴露出来。
🎯
第 1 节
谁负责监督您的 DORA 合规
DORA 并未设立单一的新监管机构。第 46 条针对每一类金融实体，指定已经依据相关行业法律对其实施监管的主管机构。信贷机构由其审慎监管机构监管，其中根据单一监管机制被归类为重要机构的，由 ECB 负责监管。支付和电子货币机构、投资公司、保险和再保险机构、基金管理人、加密资产服务提供商以及其他实体类型，则分别由其适用指令或条例中指定的主管机构负责。
另外，关键 ICT 第三方服务提供商（CTPPs）在 EU 层面接受监督。根据第 31 条至第 44 条的监督框架，将为每个被指定的 CTPP 任命一个 ESA 作为牵头监督方。该监督位于对您自身监管之上：它不会取代您管理第三方关系的义务，但意味着最大型的服务提供商本身也将直接受到审查。
监管关注如何确定优先级
DORA 建立在比例原则（第 4 条）之上：要求和监管强度应反映实体的规模、风险状况，以及其服务的性质、规模和复杂性。主管机构不会一次性审查所有实体。实践中，通常会使某个实体被提前纳入审查队列的因素，在条例本身中已有体现。
系统重要性
规模更大且系统重要性更高的实体承担最完整的一组义务，也会受到最密切的关注。较小实体可适用第 16 条中的简化 ICT 风险管理框架。
事件历史
曾报告重大 ICT 相关事件的实体，会为监管机构进一步审视事件处理和根因后续跟进提供自然切入点。
第三方集中度
对少数 ICT 服务提供商的高度依赖，尤其是其中任何被指定为 CTPP 的服务提供商，正是 DORA 旨在揭示的集中度风险。
专题和常规审查
主管机构还会围绕特定风险开展专题审查，例如云依赖，并将 ICT 风险纳入其既有监管周期。
实际要点是：如果您的实体尚未接受以 DORA 为重点的审查，您仍在适用范围内，现在正是准备的时候。由于 DORA 会融入现有监管关系，更有价值的问题不是“新监管机构何时到来”，而是“当我们现有监管机构提出 DORA 问题时，我们的就绪度如何”。
🔍
第 2 节
DORA 审查涉及什么
欧盟《数字运营韧性法案》（DORA）并未规定单一的评估程序，时间安排和形式会因主管机构以及审查范围而异。确定不变的是主管机构可调用的工具包，该工具包载于第 50 条。审查通常会沿着可识别的顺序推进，理解这一点有助于您分配资源，而不是临时应付。
第 1 阶段 - 通知与范围
审查从主管机构明确其范围开始。这可能是对您的 DORA 框架进行全面审视，也可能围绕某一支柱开展专题审查：ICT 风险管理（第二章）、事件报告（第三章）、韧性测试（第四章）或第三方风险（第五章）。范围函通常会附带初始文件请求。通知期和响应窗口由主管机构设定，而不是由 DORA 设定。
第 2 阶段 - 文件请求与案头审查
第 50 条允许主管机构复制其认为相关的任何文件或数据。请求通常非常细化。常见项目包括：
- 完整的信息登记册（Art. 28），涵盖 ICT 服务提供商、合同安排和分包外包链条
- ICT 风险管理框架和已批准的策略（Art. 5-16）
- 韧性测试计划，包括在要求适用时的任何威胁导向渗透测试 (TLPT)（Art. 24-27）
- 事件分级程序以及就重大事件提交的报告（Art. 17-23）
- 管理机构 ICT 风险报告和批准记录（Art. 5）
- 业务连续性和灾难恢复计划，以及测试证据（Art. 11-12）
- ICT 第三方合同、退出策略和集中度风险分析（Art. 28-30）
第 3 阶段 - 现场检查或远程深度审查
第 50 条赋予主管机构开展现场检查和调查的权力。根据实体的风险状况，这可能是现场访问、远程会议，或两者结合。您应预期主管机构会要求查看流程如何实际运行，而不只是查看成文文件：事件如何升级、信息登记册如何维护、测试审计发现如何跟踪。
第 4 阶段 - 与关键人员访谈
第 50 条明确允许主管机关传唤代表进行口头或书面说明，并访谈任何同意接受访谈的人员。DORA 在第 5 条下将管理机构置于 ICT 风险的核心位置，因此访谈通常会超出技术团队范围：
- 管理机构成员：证明 ICT 风险是常设议程事项，框架已在董事会层面获得批准，且成员保持充分知识
- CTO / CIO：架构、韧性测试结果、变更管理
- CISO：事件分类、威胁态势、安全运营
- 首席风险官：将 ICT 风险纳入更广泛风险框架的整合情况
- 合规 / DPO：DORA、GDPR 和 NIS2 之间的监管报告与一致性
- 第三方风险经理：供应商评估、合同监控、退出计划测试
一致性很重要：监管机构会关注策略内容与人员实际执行之间是否一致。访谈往往是纸面方案被拆穿的环节。如果一名董事会成员无法用自己的话说明 ICT 风险偏好，该框架就会被视为买来的东西，而再多文件也无法在现场修复这种印象。请对他们进行充分简报，并就您已知的薄弱点进行诚实说明。
第 5 阶段 - 审计发现与跟进
如果主管机关发现不足，第 50 条允许其要求采取纠正和补救措施。实践中，这意味着审计发现、整改预期和后续跟进。格式和截止期限由各主管机关设定。审查结果会成为您的监管记录的一部分，并影响下一次您受到多大程度的监管关注。
📈
第 3 节
监管机构逐条审查哪些内容
最清晰的准备方式，是将每项义务映射到相应的强有力证据应具备的样子。下表是一项就绪度辅助工具，依据 DORA 文本整理。它并非任何主管机构发布的监管评分细则。
| 领域 | DORA 引用 | 有力证据 | 可能引发疑问 |
|---|---|---|---|
| 管理机构监督 | Art. 5 | 董事会正式批准 ICT 风险框架；将其作为常设议程项并定期报告；成员保持有记录的 ICT 知识 | 没有董事会层面讨论 ICT 风险的证据；框架仅由 IT 签署批准；没有培训记录 |
| ICT 风险管理框架 | Art. 6-16 | 形成文档的框架，明确负责人和风险偏好，设有定期评审周期，并与企业风险管理集成 | 将通用 IT 策略重新贴标为 DORA 框架；没有 ICT 风险偏好；策略自 DORA 之前以来未被评审 |
| 信息登记册 | Art. 28 | 完整、准确的信息登记册，覆盖所有 ICT 第三方服务提供商；将安排映射到职能；按可报告的 ESA 格式维护 | 服务提供商清单不完整；缺少分包外包链条；无法生成 ESA 格式导出；存在标识符缺失等数据质量差距 |
| 事件分类与报告 | Art. 17-23 | 已实施并测试 DORA 分类标准；满足报告截止期限；根因分析形成文档 | DORA 之前的流程未更新；依据主观判断分类；通知迟延或缺失 |
| 韧性测试计划 | Art. 24-27 | 对关键 ICT 系统开展基于风险的测试；在实体符合条件时执行 TLPT；审计发现跟踪至修复完成 | 测试仅限年度渗透测试；在要求时未执行 TLPT；结果未关联到风险管理；以往审计发现未处理 |
| 第三方风险管理 (TPRM) | Art. 28-30 | 对 ICT 服务提供商开展尽职调查；分析集中度风险；退出策略形成文档并经过测试；合同与 Art. 30 保持一致 | 没有退出策略；合同缺少 DORA 条款，例如审计权、数据位置和分包；未评估集中度风险 |
| 业务连续性和恢复 | Art. 11-12 | 计划覆盖所有关键职能；经过测试并记录结果；恢复目标已定义并验证 | 计划仅停留在纸面且未经测试；未定义恢复目标；上次测试已超过 12 个月；失败未处理 |
| ICT 变更管理 | Art. 9 | 正式流程包含风险评估、测试和回滚；已定义紧急变更流程；维护审计追踪 | 流程非正式或不一致；部署前没有风险评估；紧急变更绕过控制措施 |
| 信息共享 | Art. 45 | 已考虑参与威胁情报共享，并无论决定为何均形成文档 | 不了解相关安排；未参与且未记录理由 |
| ICT 资产管理 | Art. 8 | 完整的 ICT 资产清单；按关键性分类；映射依赖关系；识别支持关键职能的资产 | 清单不完整；没有关键性分类；依赖关系未知；影子 IT 未处理 |
事件报告时钟
一个反复出现的监管主题是，实体是否确实能够满足 ESAs 技术标准设定的重大事件报告截止期限。设计时应围绕第一步展开。4 小时非常紧迫，也算合理，因为只有在您将事件归类为重大事件后才开始计时。常见失效模式是，人员争论不休，导致分类决策不断拖延。因此，相关标准必须提前写明并演练，而不是等到真正需要的那个夜晚才临时确定。时间线分为三步：
| 初始通知 | 在将事件归类为重大事件后的 4 小时内，且不得迟于知悉该事件后的 24 小时。 |
| 中期报告 | 在初始通知后的 72 小时内。 |
| 最终报告 | 在最后一次更新后的 一个月内。 |
⚖️
第 4 节
处罚和补救措施：实际如何运作
欧盟《数字运营韧性法案》（DORA）并不像某些法规那样，为金融实体设定统一适用于全 EU 的罚款上限。第 50 条要求各成员国制定行政处罚和补救措施，并且用法规原文的话说，这些措施必须“有效、相称并具有劝阻性”。因此，最高罚款金额及其计算方式会因成员国而异。除非某个醒目的金额数字明确对应适用于您的具体国家制度，否则应谨慎看待。将金额交由成员国决定，是 DORA 设计中最薄弱的部分。义务是统一的，但后果却分散各处，这使得在预算讨论中很难说明风险敞口，也会在跨境集团内部造成不均衡的压力。相反，应围绕监管措施来规划，因为责令停止某项行为或发布公开通知，都会在罚款发生之前就对受监管机构造成损害。
纠正和补救措施
第 50 条允许主管机关针对违规行为要求采取纠正和补救措施，责令停止违反该法规的行为，并采取包括金钱性质在内的措施，使实体重新恢复合规。
公开通知
根据第 50 条，主管机关可以发布公开通知，包括说明责任人身份和违规性质的声明。声誉风险不仅仅是罚款，也是威慑机制的一部分。
个人问责
第 50 条允许在符合国家法律的前提下，对管理机构成员以及其他对违规行为负有责任的个人采取措施。ICT 风险既是技术问题，也是治理问题。
对关键服务提供商的监督
对于被指定的 CTPP，首席监督方可根据第 35 条，按日处以周期性罚款，最高可达该服务提供商上一年度全球日均营业额的 1%，持续时间最长为六个月。
一个缺口往往会扩大审查范围
某一领域的不足，往往会引发对相关领域的追问。不完整的信息登记册会招致对第三方风险管理的审查，进而引出集中度风险和退出规划问题。及早补齐明显缺口，有助于防止聚焦式审查进一步扩大。
🌎
第 5 节
DORA 监管在 EU 范围内如何组织
由于欧盟《数字运营韧性法案》（DORA）是直接适用的法规，其实质性规则在每个成员国都相同。监管架构是分层的：您自己的主管机关、在 EU 层面协调的三个 ESAs，以及针对最大型 ICT 服务提供商的监督框架。了解每一层负责什么，有助于判断某项请求会来自哪里。
| 层级 | 覆盖对象 | 角色和法律依据 |
|---|---|---|
| 国家主管机关 | 按类型划分的您的金融实体 | 日常监管机构。第 46 条针对每类实体，指定已根据相关行业法律承担监管职责的机关。该机关拥有第 50 条规定的权力，可要求提供文件、开展检查、进行访谈并要求整改。 |
| ECB（SSM） | 银行联盟内的重要信贷机构 | 作为其直接监管的重要银行的主管机关，将 ICT 风险纳入其现有审慎监管。 |
| ESAs（EBA、ESMA、EIOPA） | 通过协调覆盖所有适用范围内实体 | 起草技术标准，通过国家主管机关组织信息登记册收集，并协调一致适用。它们不会取代您的国家主管机关。 |
| 首席监督机构 | 被指定的关键 ICT 第三方服务提供商 | 根据监督框架（Art. 31-44），为每个 CTPP 指定一个 ESAs 作为首席监督机构，并拥有自身权力，包括第 35 条规定的定期罚款。 |
跨境集团
在多个司法辖区接受监管的实体，可能会看到审查时间和形式存在差异，因为尽管规则是共同的，实际做法仍由各国家主管机关决定。如果 ECB 是直接监管机构，ICT 风险会通过其现有监管安排处理。请一次性构建您的证据，并采用任何监管机构都能使用的形式。
✅
第 6 节
准备 DORA 审查：实用检查清单
准备工作决定了一次审查是从容应对，还是仓促救火。以下事项是大多数实体应长期保持的就绪度要求，每一项都对应 DORA 的相应部分，而不是某个单一监管机构的偏好。请如实评估它们的成本。第 2、3 和 7 项需要数周的文档编写和日程纪律。第 1 项一旦开始沿着服务提供商追查分包外包链条，就会变成持续数月的工作，因此应先启动它，并同步推进其余事项。
就绪度检查清单
1. 信息登记册（Art. 28）
完整登记所有服务提供商、合同安排、业务职能映射、分包外包链条和法人实体识别码。核验 ESA 格式的导出。与采购记录交叉核对，发现遗漏的服务提供商。
2. ICT 风险管理框架（Art. 5-16）
经董事会批准的框架，并配套信息安全、访问控制、变更管理、业务连续性和事件管理相关策略。提供带有日期和签署人的评审证据。
3. 管理机构证据（Art. 5）
会议纪要显示 ICT 风险列入议程，已批准的风险偏好声明，管理机构培训记录，以及董事会层面的 ICT 风险报告。
4. 事件响应就绪度（Art. 17-23）
与 DORA 标准一致的分类方法，记录成文的报告工作流并包含可满足截止期限的升级路径，包含根因分析的事件日志，以及演练证据。
5. 韧性测试证据（Art. 24-27）
测试计划，在实体符合标准时提供 TLPT 结果，带整改跟踪的漏洞评估，以及回馈至风险评估的连续性和恢复测试结果。
6. 第三方合同和退出计划（Art. 28-30）
审查合同是否涵盖第 30 条要求，例如审计权、数据位置、分包和终止。为关键服务提供商制定退出策略。具备最新的集中度风险分析。
7. 差距评估和整改跟踪器
形成书面的内部差距评估，并配套整改计划，列明负责人、截止期限和进展。能够证明您了解自身差距并正在弥合，通常比声称不存在任何差距更可信。
8. 员工就绪度
指定协调人，提前向 CTO、CISO、CRO 和管理机构进行简报，为关键人员准备访谈，并建立可向审查团队开放访问权限的中央资料库。
能够顺利通过审查的实体，很少是那些声称完美无缺的实体。它们通常了解自身差距，持有可信的整改计划，并且能够快速、完整地调取证据。能展示您的工作过程，比宣称没有任何问题可查更有价值。
🛡️
第 7 节
Venvera 如何帮助您随时应对审查
Venvera 是一个多框架合规平台。欧盟《数字运营韧性法案》（DORA）是其支持的框架之一，同时还支持 欧盟 NIS2 指令、ISO 27001 等，因此，您为监管机构整理的证据可以在您承担的各项义务中复用。核心很简单：将您的框架、登记册、事件和测试集中在一处，这样当监管机构提出要求时，您只需检索，而不是重新构建。
信息登记册
用于 ICT 服务提供商、合同安排、业务职能和分包外包链条的结构化登记册，支持 ESA 格式导出，让您无需在时间压力下编制电子表格。
带评分的差距评估
覆盖 DORA 各章节的差距评估，并按条款级别评分，让您了解当前状态，并在监管机构要求之前生成整改视图。
董事会就绪报告
与第 5 条对齐的董事会层面 ICT 风险报告：态势、未结审计发现、整改进展和事件趋势，以可提交给管理机构的形式呈现。
证据管理
集中式证据库，包含版本历史和审计追踪，因此可以快速检索连续性测试结果或事件记录，并证明其为最新状态。
事件管理
与 DORA 对齐的分类，以及围绕 ESA 截止期限构建的报告工作流，覆盖从检测到根因分析的事件生命周期。
第三方和集中度风险
服务提供商风险评估、集中度分析、退出计划和第 30 条合同跟踪，因此对于关键服务提供商的问题可以给出有据可查的答案。
常见问题
由谁监管金融实体的 DORA 合规？
由您现有的行业监管机构负责。DORA 第 46 条针对每类实体指定了已根据相关 EU 指令或法规负责监管的主管机关，其中在银行业联盟中，ECB 负责监管重要信贷机构。三个 ESA（EBA、ESMA 和 EIOPA）在 EU 层面进行协调，并通过这些国家主管机关开展信息登记册收集工作。另外，根据第 31 条至第 44 条，关键 ICT 第三方服务提供商由牵头监督机构负责监督，该机构为 ESA 之一。
DORA 从何时开始适用？
DORA，即 Regulation (EU) 2022/2554，自 2025 年 1 月 17 日起适用（第 64 条）。它在整个 EU 直接适用，因此其实质性要求自该日期起生效，无需各国转化为国内法。
监管机构可以根据 DORA 要求什么？
第 50 条赋予主管机构广泛权力：访问并复制任何被认为相关的文件或数据，开展现场检查和调查，传唤代表作出口头或书面说明，访谈任何同意接受访谈的人员，并要求采取纠正和补救措施。在实践中，监管机构通常会要求提供信息登记册、ICT 风险管理框架、事件记录、韧性测试结果以及第三方合同。
DORA 下可能适用哪些处罚？
欧盟《数字运营韧性法案》（DORA）并未为金融实体设定一个统一适用于全 EU 的罚款金额。第 50 条要求各成员国规定有效、相称且具有劝阻性的行政处罚和补救措施，因此最高限额因国家而异。主管机构可以责令停止违规行为，采取金钱措施，发布点名实体和违规行为的公开通知，并对责任个人适用相关措施。对于被指定的关键 ICT 第三方服务提供商，首席监督机构可根据第 35 条，按日处以最高为全球日均营业额 1% 的定期罚款，最长可持续六个月。
审查前我们应准备好什么？
一份完整且可导出的信息登记册；一套经董事会批准的 ICT 风险管理框架及配套策略；能够满足 ESAs 截止期限的事件分类和报告能力；一项韧性测试计划，包括在实体符合条件时开展 TLPT；以及包含第 30 条条款、退出策略和集中度风险分析的第三方安排。在这些基础上保留有文档记录的差距评估和整改计划，通常比声称已完全合规更容易获得正面评价。
使用 Venvera 做好审查准备
DORA 审查在实质内容上很少令人意外：法规已经说明了监管机构可以要求什么。真正的工作在于您能否拿得出来。将您的框架、信息登记册、事件、测试和第三方证据保存在同一个系统中，可以把审查从重建过程变成检索过程。
如果您想快速了解当前所处位置，可以进行一次免费合规检查，或了解 DORA 模块和控制措施映射如何让您在 DORA、欧盟 NIS2 指令和 ISO 27001 之间复用证据。
主要来源
本指南依据法规和 EU 官方材料编写：Regulation (EU) 2022/2554（DORA 全文，包括第 5、17-30、35、46、50 和 64 条）；European Banking Authority DORA 页面；以及 ESAs 关于信息登记册试运行的沟通材料。事件报告截止期限遵循 ESAs 的技术标准。在依赖具体日期或数字之前，请务必确认当前文本以及适用于您的国家制度。
更新于 2026 年 7 月 · Venvera 合规平台 · venvera.com
本文仅供参考，不构成法律或监管建议。请与您自己的顾问确认适用于您机构的要求和国家制度。
