合规指南
更正已于 2026 年 7 月 14 日更正。本文早期版本中的若干引用与官方文本不一致：一份章节到 RTS 的映射中，条款范围与 Delegated Regulation (EU) 2024/1774 的结构不对应；事件通知截止期限被表述为单一的四小时窗口；以及若干管理机构职责被归属于 Article 5(2) 的错误分项。以下所有引用均已根据《官方公报》文本重新核验。无法追溯到已发布来源的关于监管行为的主张，已被删除而不是弱化表述。
欧盟《数字运营韧性法案》（DORA）第 II 章第 5 条至第 16 条要求，范围内的每一家金融实体都必须建立 ICT 风险管理框架。第 6(1) 条是可操作的核心句：该框架必须是其整体风险管理体系的一部分，即“稳健、全面且有充分文档记录的 ICT 风险管理框架”。该法规已自 2025 年 1 月 17 日起适用。
该法规规定了义务。细节位于其下一层级，即 Commission Delegated Regulation (EU) 2024/1774，这是一项监管技术标准，旨在“具体规定 ICT 风险管理工具、方法、流程和策略，以及简化的 ICT 风险管理框架”，依据 DORA 第 15 条和第 16(3) 条通过。其第 2 条至第 27 条适用于完整框架。其第 28 条至第 41 条为 DORA 第 16(1) 条所列实体规定了简化框架。
只引用一级文本的框架文件，缺少了要求真正被具体规定的那个层级。这种两层结构是 DORA 中最被低估的一点。法规读起来像是一套完善的策略即可作答。RTS 才是真正需要落实工作的地方，而且其细化程度会迫使您改变 ICT 的运行方式，而不仅仅是改变您对其的描述方式。本指南将逐章梳理结构，并为每一章列出其必须回应的条款。它不会告诉您监管机构在想什么，因为这不是我们能够提供来源依据的内容。
📜
第 1 节
框架必须覆盖的内容
第二章涵盖第 5 条至第 16 条。第 5 条和第 6 条规定治理以及框架本身。第 7 条至第 14 条规定实质性义务。第 15 条是技术标准授权，第 16 条则为其列明的较小型实体划定了简化框架。该文件需要为以下每一项内容设置位置。
第 5 条 - 治理与组织
管理机构必须“界定、批准、监督并负责实施与第 6(1) 条所述 ICT 风险管理框架相关的所有安排”。第 5(2) 条随后列出九项具体职责，即 (a) 至 (i) 项。
第 6 条 - ICT 风险管理框架
一个健全、全面且有充分文件记录的框架。除微型企业外的实体必须将 ICT 风险分配给独立控制职能部门 (6(4))。该框架至少每年以及在重大事件后进行评审 (6(5))，接受内部审计 (6(6))，并且必须包含数字运营韧性策略 (6(8))。
第 7 条 - ICT 系统、协议和工具
系统必须与运营规模相适应，可靠，具备足以处理峰值容量的能力，并在市场承压条件下具备技术韧性。
第 8 条 - 识别
识别、分类并记录所有由 ICT 支持的业务职能、信息资产和 ICT 资产及其依赖关系。映射关键资产和相互依赖关系 (8(4))，识别依赖 ICT 第三方的流程 (8(5))，维护清单 (8(6))，并对遗留 ICT 系统开展年度风险评估 (8(7))。
第 9 条 - 保护与预防
第 9(4) 条规定了六项框架义务，即 (a) 至 (f) 项：信息安全策略 (a)、网络和基础设施管理 (b)、访问限制策略 (c)、强认证和加密密钥保护 (d)、有文件记录的 ICT 变更管理 (e)，以及全面的补丁和更新策略 (f)。
第 10 条 - 检测
用于及时检测异常活动、ICT 网络性能问题和事件，并识别潜在重大单点故障的机制。检测机制必须支持多层控制措施并定义告警阈值 (10(2))，且其本身也必须定期测试。
第 11 条 - 响应与恢复
ICT 业务连续性策略、需接受独立内部审计评审的响应和恢复计划 (11(3))、业务影响分析 (11(5))，以及至少每年和在发生实质性变更时对计划进行测试 (11(6)(a))。除微型企业外的实体需要设立危机管理职能 (11(7))。
第 12 条 - 备份、还原与恢复
有文件记录的备份策略，明确范围和最低频率；与源系统在物理和逻辑上隔离的还原系统 (12(3))；除微型企业外的实体需具备冗余 ICT 容量 (12(4))；并按职能设定恢复时间目标和恢复点目标 (12(6))。
第 13 条 - 学习与演进
具备收集威胁和漏洞信息的能力；在重大事件后开展事后评审 (13(2))；将测试和事件经验教训纳入 ICT 风险评估流程 (13(3))；由高级 ICT 人员每年向管理机构报告 (13(5))；以及强制性的 ICT 安全意识和韧性培训模块 (13(6))。
第 14 条 - 沟通
用于负责任披露重大事件和漏洞的危机沟通计划；分别面向内部员工和外部利益相关方的沟通策略；以及至少指定一名负责公众和媒体职能的人员。
“金融实体应建立内部治理和控制框架，按照第 6(4) 条，确保对 ICT 风险进行有效且审慎的管理，以实现高水平的数字运营韧性。”
DORA 第 5(1) 条。请注意其交叉引用了第 6(4) 条，即关于独立 ICT 风险控制职能的要求。在引用这句话时，这一点经常被省略，而它恰恰是会带来组织层面后果的部分。
这些并不是相互独立的章节。第 8 条的识别会驱动第 9 条的保护措施。第 10 条的检测会支撑第 11 条的响应。第 13(3) 条通过要求将测试和真实事件中的经验教训持续纳入风险评估流程，并作为对框架本身进行评审的基础，完成闭环。无法展示这一闭环的文件，只是一叠策略，而不是一个框架。撰写一份覆盖第 5 条至第 16 条的文件，可能只需要数周起草。能够用每个步骤中带日期的产物，向他人讲清楚这一闭环，则需要一整年的运营纪律。两者都要规划，并且要向董事会清楚说明，您要求他们批准的是这两者中的哪一个。
⚖️
第 2 节
RTS 在 DORA 本身之外增加了什么
Delegated Regulation (EU) 2024/1774 共有 42 条。第 1 条是比例原则条款。第 2 条至第 27 条规定完整的 ICT 风险管理框架。第 28 条至第 41 条规定简化框架。下表将第 2 条至第 27 条这一实质性部分，映射到其要求以及其补充的 DORA 条款。
| RTS 2024/1774 | 领域 | 框架必须涵盖的内容 | DORA 锚点 |
|---|---|---|---|
| Art. 2 | ICT 安全策略、程序、协议和工具的一般要素 | ICT 安全策略必须嵌入框架，与韧性战略中的信息安全目标保持一致，并注明管理机构正式批准该策略的日期。 | DORA Art. 9(2) |
| Art. 3 | ICT 风险管理 | 风险管理程序本身：风险容忍度、评估影响的准则、方法论，以及由承担问责的角色接受剩余 ICT 风险。 | DORA Art. 6(1) |
| Arts. 4-5 | ICT 资产管理策略和程序 | 策略（Art. 4）和运营程序（Art. 5）：资产关键性分级、关联关系和相互依赖关系，以及对即将结束支持的资产的处理。 | DORA Art. 8(1), 8(4), 8(6) |
| Arts. 6-7 | 加密和密码控制措施；密码密钥管理 | 覆盖静态、传输中和使用中数据的密码策略，以及覆盖生成、更新、存储、吊销和销毁的密钥管理生命周期。 | DORA Art. 9(4)(d) |
| Arts. 8-12 | ICT 运营：策略和程序、容量和性能、漏洞和补丁管理、数据和系统安全、日志记录 | 这里规定运营层面的细节：按关键性确定补丁截止期限、漏洞扫描、容量规划，以及日志留存和防篡改保护。 | DORA Art. 9(1), 9(4)(f) |
| Arts. 13-14 | 网络安全管理；保护传输中的信息 | 网络分段、网络连接和防火墙规则审查、安全远程访问，以及传输中信息的保护。 | DORA Art. 9(4)(b) |
| Arts. 15-17 | ICT 项目管理；系统采购、开发与维护；ICT 变更管理 | 项目治理和安全要求，开发、测试与生产环境的隔离，以及包含批准、测试、回滚和紧急变更处理的成文变更程序。 | DORA Art. 9(4)(e) |
| Art. 18 | 物理和环境安全 | 对场所、数据中心和指定敏感区域实施物理访问控制措施，提供环境保护，并安全处置介质。 | DORA Art. 9(4)(c) |
| Arts. 19-21 | 人力资源策略；身份管理；访问控制 | 雇佣关系中的安全职责、唯一身份，以及涵盖最小权限、按需知悉、特权访问、远程访问和访问权限定期审查的访问控制策略。 | DORA Art. 9(4)(c) |
| Arts. 22-23 | ICT 相关事件管理策略；异常活动检测 | 检测标准和触发条件、升级机制，以及将检测与 DORA 第 III 章报告义务相衔接的事件管理流程。 | DORA Art. 10, Art. 17 |
| Arts. 24-26 | ICT 业务连续性策略；连续性计划测试；响应和恢复计划 | 连续性策略的组成部分、计划的测试制度，以及响应和恢复计划的内容，包括恢复目标。 | DORA Art. 11, Art. 12 |
| Art. 27 | ICT 风险管理框架审查报告的格式和内容 | DORA Article 6(5) 要求的报告必须以可搜索的电子格式提交，并必须包含 Article 27(2) 所列章节。 | DORA Art. 6(5) |
为什么 RTS 编号很重要
交叉引用表通常是框架文件中成本最低、最适合抽查的部分，它能反映起草工作究竟是基于原文，还是基于原文摘要。如果保护控制措施实际上覆盖第 6 条至第 21 条，却将第 4 章映射到“RTS 第 8 条至第 17 条”，这种映射会造成自找的审计发现。请以《官方公报》文本为基础构建该表，并持续保持更新，因为这些标准会被修订。
📋
第 3 节
框架文档结构
这一十章结构为欧盟《数字运营韧性法案》（DORA）第 II 章的每项要求以及 RTS 的每一条规定都提供了归属位置。它是一份结构蓝图。请根据您的规模、复杂性和风险状况调整各小节，并将该调整记录为您的比例原则评估。
第 1 章
治理与职责
映射至：DORA Art. 5, Art. 6(1)-(7) | RTS (EU) 2024/1774 Art. 2, Art. 3
- 管理机构职责，逐项映射至 Article 5(2) 的 (a) 至 (i) 点
- ICT 风险控制职能及其独立性（Art. 6(4)）
- ICT 风险容忍度水平，作为韧性战略的一部分设定（Art. 6(8)(b)）
- 预算分配（Art. 5(2)(g)）以及框架审查周期（Art. 6(5)）
- 管理机构正式批准的日期，这是 RTS Art. 2(2)(b) 要求安全策略载明的内容
第 2 章
ICT 资产管理与分类
映射至：DORA Art. 8(1), 8(4), 8(6) | RTS (EU) 2024/1774 Arts. 4-5
- ICT 资产和信息资产清单
- 分类方案和关键性映射
- 资产之间的关联和相互依赖关系，这是 Art. 8(4) 要求您进行映射的内容
- 清单更新触发条件，包括每次重大变更时更新（Art. 8(3), 8(6)）
第 3 章
风险识别与评估方法
映射至：DORA Art. 8(2), 8(3), 8(7) | RTS (EU) 2024/1774 Art. 3
- 持续识别 ICT 风险来源，并至少每年审查风险场景（Art. 8(2)）
- 对基础设施、流程或程序的每项重大变更开展风险评估（Art. 8(3)）
- 每年对所有遗留 ICT 系统开展专项 ICT 风险评估（Art. 8(7)）
- 剩余风险接受情况，记录到指定的问责角色名下
第 4 章
保护与预防控制措施
映射至：DORA Art. 9 | RTS (EU) 2024/1774 Arts. 6-21
- 信息安全策略（Art. 9(4)(a)）
- 网络和基础设施管理，包括即时断开或分段连接的能力（Art. 9(4)(b); RTS Arts. 13-14）
- 限制物理和逻辑访问（Art. 9(4)(c); RTS Arts. 18-21）
- 强身份认证和加密密钥保护（Art. 9(4)(d); RTS Arts. 6-7）
- ICT 变更管理，并由适当管理线批准（Art. 9(4)(e); RTS Arts. 15-17）
- 补丁和更新策略（Art. 9(4)(f); RTS Art. 10）
第 5 章
检测与监控
映射至：DORA Art. 10 | RTS (EU) 2024/1774 Art. 12, Art. 23
- 通过多层控制措施和已定义的告警阈值进行异常检测（Art. 10(2)）
- 日志记录：记录哪些内容、保留多长时间，以及如何防篡改保护（RTS Art. 12）
- 识别潜在的重大单点故障（Art. 10(1)）
- 定期测试检测机制本身（Art. 10(1)，第二项分段）
第 6 章
响应与恢复
映射至：DORA Art. 11, Art. 12 | RTS (EU) 2024/1774 Art. 22, Arts. 24-26
- ICT 业务连续性策略以及响应和恢复计划（Art. 11(1), 11(3)）
- 采用定量和定性标准开展业务影响分析（Art. 11(5)）
- 按职能确定恢复时间目标和恢复点目标（Art. 12(6)）
- 危机管理职能（Art. 11(7)）以及中断期间的活动记录（Art. 11(8)）
- 年度测试，包括网络攻击场景以及切换至冗余能力（Art. 11(6)）
第 7 章
测试方案
映射至：DORA Arts. 24-27 | RTS on TLPT (EU) 2025/1190
- 作为框架组成部分的韧性测试方案（Art. 24(1)）
- 对支持关键或重要职能的所有 ICT 系统和应用开展年度测试（Art. 24(6)）
- Art. 25(1) 列明的测试类型，从漏洞扫描到端到端测试和渗透测试
- 针对 Art. 26 项下确定的实体开展威胁导向渗透测试 (TLPT)，并受 Delegated Regulation (EU) 2025/1190 规制
- 对测试发现的每一项问题进行优先级排序、分类和补救的程序，以及确认其已得到充分处理的内部验证（Art. 24(5)）
第 8 章
第三方风险整合
映射至：DORA Arts. 28-30 | RTS (EU) 2024/1773, RTS (EU) 2025/532, ITS (EU) 2024/2956
- ICT 第三方风险战略，包括关于支持关键或重要职能的 ICT 服务的策略（Art. 28(2); RTS (EU) 2024/1773）
- Art. 28(4) 中的合同订立前评估和尽职调查
- ICT 集中度风险的初步评估（Art. 29）
- 支持关键或重要职能的服务分包（Art. 30(2)(a); RTS (EU) 2025/532）
- 退出策略和过渡计划（Art. 28(8)）
- 信息登记册（Art. 28(3); ITS (EU) 2024/2956）
第 9 章
报告与沟通
映射至：DORA Art. 14, Arts. 17-19 | RTS (EU) 2024/1772, RTS (EU) 2025/301
- 危机沟通计划，以及负责公众和媒体职能的指定人员（Art. 14(1), 14(3)）
- 根据 Delegated Regulation (EU) 2024/1772 中的标准和重要性阈值进行事件分类（Art. 18）
- Delegated Regulation (EU) 2025/301 第 5 条规定的通知截止期限，见下文第 4 节
- 管理机构报告：至少包括高级 ICT 人员提交的年度报告（Art. 13(5)）以及 Art. 5(2)(i) 要求的报告渠道
第 10 章
评审与持续改进
映射到：DORA Art. 6(5), Art. 13 | RTS (EU) 2024/1774 Art. 27
- Art. 6(5) 中的四类评审触发条件：至少每年一次、发生重大 ICT 相关事件时、根据监管指令，以及基于韧性测试或审计结论
- 事件后评审，以及 Art. 13(2) (a) 至 (d) 点中的四个有效性问题
- 将测试和事件经验反馈到风险评估流程中（Art. 13(3)）
- 关键绩效指标和关键风险指标，Art. 6(8)(c) 要求在韧性战略中列明这些指标
- 框架评审报告的格式和内容（RTS Art. 27）
法规原文中的比例原则
“金融实体应按照比例原则实施第二章规定的规则，同时考虑其规模和整体风险状况，以及其服务、活动和运营的性质、规模和复杂性。”
DORA Article 4(1)。比例原则用于校准深度，并不意味着可以删除章节。Article 4(3) 还补充规定，主管机关在根据 Article 6(5) 提交的报告审查 ICT 风险管理框架一致性时，“应考虑金融实体对比例原则的适用”。相关理由本身也可被审查，因此请将其写下来。比例原则是 DORA 讨论中最常被误用的词。减负是真实存在的，它作用于每项控制措施需要做到多深，但每一章仍然都需要有答案。花一个下午写清理由，可以消除一个容易出现的审计发现。
🔍
第 4 节
文本要求您提供证据的六个关联
我们不会告诉您监管机构首先会问哪个问题，因为我们没有来源依据来支持这种说法。我们能做的是指出文本中要求证明两件事之间存在可展示关联的地方，而不是仅要求一份策略声明。这些正是框架中事后最难补齐的部分。
1. 董事会问责链
第 5 条第 2 款并不是说“董事会批准该框架”就结束了。它列出了九项职责，即 (a) 至 (i) 项，每一项都是一个证据问题。(f) 项是 ICT 内部审计计划。(g) 项是预算。(i) 项是一组公司层面的报告渠道，覆盖第三方安排、对这些安排计划进行的重大变更，以及至少重大 ICT 相关事件。如果管理机构在您的框架中只出现一次，而且仅出现在批准区块中，那么该文件并未覆盖第 5 条第 2 款。
2. 清单完整性
第 8 条第 4 款要求您识别所有信息和 ICT 资产，“包括位于远程地点的资产、网络资源和硬件设备”，对被视为关键的资产进行映射，并映射“不同信息资产和 ICT 资产之间的联系和相互依赖关系”。没有依赖关系图的资产清单不符合该条要求，而依赖关系图正是需要时间建立的部分。
3. 风险、控制措施、测试、风险闭环
第 13 条第 3 款要求，将韧性测试、真实事件以及连续性计划启动所得经验“持续并适当地纳入 ICT 风险评估流程”，并且这些审计发现“应构成对 ICT 风险管理框架相关组成部分进行适当评审的依据”。如果一个框架在一章描述风险、另一章描述控制措施，却没有记录二者之间的路径，就无法为此提供证据。
4. 实际发生过的连续性测试
第 11 条第 6 款 (a) 项要求对连续性计划以及响应和恢复计划进行测试，“至少每年一次，并且在支持关键或重要职能的 ICT 系统发生任何实质性变更时”也要测试。对于微型企业以外的实体，测试计划必须包括网络攻击场景，以及主基础设施与冗余容量之间的切换。
5. 通知计时
报告截止期限不在 DORA 第 19 条中，该条将其交由技术标准规定。它们载于 Delegated Regulation (EU) 2025/301 第 5 条，而且初始截止期限包含两个条件，而不是一个。如果框架中写错了计时规则，其下的事件响应运行手册也会继承这个错误。
6. 签约前的集中度风险
第 29 条第 1 款要求，在您根据第 28 条第 4 款 (c) 项进行风险识别时，还必须考虑拟议合同是否会导致第 29 条所列情形。这使其成为采购流程中的合同前关口，而不是年度报告工作，框架必须把它放在这个位置。
正确表述通知计时规则
DORA 第 19 条第 (4) 款要求提交初始通知、中期报告和最终报告，但并未规定截止期限。它将这些期限交由技术标准确定。相关规定见 Delegated Regulation (EU) 2025/301 第 5 条第 (1) 款：
- 初始通知：“尽早提交，但无论如何，应在将 ICT 相关事件分类为重大 ICT 相关事件后 4 小时内提交，并且不得晚于金融实体知悉该 ICT 相关事件之时起 24 小时”。这是两个条件。4 小时计时从分类开始。24 小时计时从知悉开始。
- 中期报告：“最迟在提交初始通知后 72 小时内”提交，即使事件的状态或处置没有变化，也仍需提交。
- 最终报告：“不得晚于提交中期报告后一个月，或在适用情况下，不得晚于提交最新更新的中期报告后一个月”。一个月期限从中期报告起算，而不是从事件起算。
第 5 条第 (4) 款允许将落在周末或银行假日的截止期限顺延至下一个工作日中午，而第 5 条第 (5) 款则对信用机构、中央对手方、交易场所运营者，以及根据 Directive (EU) 2022/2555 被认定为基本或重要的实体提交初始通知和中期报告撤回该宽限。一个只写着“4h / 72h / 1 month”然后到此为止的框架，在三个不同地方都是错误的。双条件的初始截止期限设计得很合理。它既防止因分类迟缓而拉长计时，又保留了判断所面对情况的空间。它要求您具备的是一个能够快速作出并有证据支持的分类决策，这属于流程问题，而不是起草问题。
⚠️
第 5 节
董事会批准前的质量检查清单
下表每一行都对应文本中的一项具体要求。请将其作为您自己文件在批准前的检查。如果您只修正两行，请优先修正引用依据和相称性理由。这两项成本都很低，都可以由从未接触过贵公司的人进行核查，并且都会影响他们如何解读文件其余部分。我们不声称这些差距有多常见，因为我们没有相关的公开数据。
| 差距 | 实际表现 | 文本要求的做法 |
|---|---|---|
| 复述法规 | 框架只是重述条文后便停止。它读起来像 DORA 摘要，而不是治理工具。 | 针对每项要求，说明谁负责、流程是什么、运行频率如何，以及会产出什么工件。 |
| 缺少 RTS 细节 | 框架涵盖了 DORA 条款，但没有涵盖 Delegated Regulation (EU) 2024/1774 的条款，而工具、方法、流程和策略实际上正是在该授权法规中规定的。 | 将框架与 RTS 第 2 条至第 27 条逐项交叉引用。这些条款中的每一条都应落到一个具名章节中。 |
| 引用指向错误条款 | 条文引用看似精确，但实际错误。加密引用为 Art. 9(4)(b)，而不是 9(4)(d)。预算职责引用为 Art. 5(2)(b)，而不是 5(2)(g)。RTS 映射表中的范围整齐，却与 RTS 不匹配。 | 对照 Official Journal 文本核查每一处引用。引用错误的框架会让读者认为其底层分析也是按同样标准完成的。 |
| 没有比例原则依据 | 实体依赖比例原则来降低控制措施强度，但没有记录任何理由。 | 第 4(1) 条允许在“考虑其规模和整体风险状况，以及其服务、活动和运营的性质、规模和复杂性”的情况下适用比例原则。根据这些因素记录评估。第 4(3) 条说明主管机关将考虑您如何适用该原则。 |
| 治理真空 | 职责被分配给“组织”或“IT”，而不是分配给具名角色、委员会和升级路径。 | 第 5(2)(c) 条要求管理机构“为所有 ICT 相关职能设定清晰的角色和职责”。使用 RACI，并在 DORA 提及管理机构的所有位置明确写出管理机构。 |
| 第三方风险后置拼接 | ICT 第三方风险单独放在自己的策略中，没有回到框架的路径。 | 第 28(1) 条要求实体“作为其 ICT 风险管理框架内 ICT 风险的组成部分”管理 ICT 第三方风险。交叉引用风险登记册、保护性控制措施和连续性计划。 |
| 静态文件 | 没有版本历史，没有审查证据，也没有基于触发条件的更新机制。 | 第 6(5) 条设定了四项审查触发条件：至少每年一次、发生重大 ICT 相关事件时、遵循监管指令时，以及根据韧性测试或审计得出的结论。将这四项全部写入版本控制表。 |
| 没有测试反馈闭环 | 描述了测试计划，但没有任何内容将测试发现与风险评估相连接。 | 第 24(5) 条要求建立程序，对测试发现的所有问题进行优先级排序、分类和补救，并建立内部验证方法以确认问题已得到充分处理。第 13(3) 条要求将经验教训纳入风险评估流程。 |
| 风险指标未定义 | 该框架提到监测，但未定义指标、阈值或升级触发条件。 | Article 6(8)(c) 要求韧性策略列明“明确的信息安全目标，包括关键绩效指标和关键风险指标”。请定义指标、阈值，以及阈值被突破时应通知的人员。 |
适用于每一句话的检验标准
对于框架中的每一项策略表述，都要问：有什么实物材料可以证明它正在发生？如果答案是没有，那么只有两个诚实的选择：将表述改为描述您实际在做的事情，或者在文件提交董事会之前先建立相应流程。一个描述并不存在的组织的框架，比一个篇幅更薄但描述真实组织的框架更糟，因为第 6(3) 条要求您在主管机关提出请求时，提供关于该框架的完整且更新的信息。
🏛️
第 6 节
董事会批准与治理
第 5(2) 条开篇即规定，管理机构负责界定、批准、监督并实施与该框架相关的所有安排。随后列出了九项具体职责。大多数框架文件只引用开篇一句，而跳过该清单。以下是完整清单，并为每一项对应了正确的分项。
| 管理机构职责 | 来源 |
|---|---|
| 对管理金融实体的 ICT 风险承担最终责任 | Art. 5(2)(a) |
| 制定策略，以维持数据可用性、真实性、完整性和保密性的高标准 | Art. 5(2)(b) |
| 为所有 ICT 相关职能设定明确的角色和职责 | Art. 5(2)(c) |
| 制定并批准数字运营韧性战略，包括 ICT 风险容忍水平 | Art. 5(2)(d), citing Art. 6(8) and 6(8)(b) |
| 批准、监督并定期审查 ICT 业务连续性策略以及 ICT 响应和恢复计划 | Art. 5(2)(e), citing Art. 11(1) and 11(3) |
| 批准并定期审查 ICT 内部审计计划、ICT 审计及其重大修改 | Art. 5(2)(f) |
| 为数字运营韧性需求分配并定期审查预算，包括意识提升项目和培训 | Art. 5(2)(g), citing Art. 13(6) |
| 批准并定期审查关于使用 ICT 第三方服务提供商所提供 ICT 服务安排的策略 | Art. 5(2)(h) |
| 建立公司层面的报告渠道，覆盖第三方安排、其计划中的重大变更，以及至少重大 ICT 相关事件 | Art. 5(2)(i), points (i) to (iii) |
| 设立一个角色，或指定一名高级管理层成员，负责监控与 ICT 第三方服务提供商的安排（不包括微型企业的实体） | Art. 5(3) |
| 主动保持足够且最新的知识和技能，以理解和评估 ICT 风险，包括定期参加专项培训 | Art. 5(4) |
| 确保框架至少每年审查一次，并在发生重大事件、收到监管指示，或根据测试或审计结论时进行审查 | Art. 6(5) |
| 至少每年接收 ICT 高级人员关于 Art. 13(3) 所述审计发现的报告，并附建议 | Art. 13(5) |
第 5(4) 条应在框架中单独列明。管理机构成员“应主动持续更新并保持足够的知识和技能，以理解和评估 ICT 风险及其对金融实体运营的影响，包括定期参加与所管理 ICT 风险相称的专项培训”。这是针对个人的义务，并会产生一项文档产物：培训记录。这也是最容易被悄悄跳过的职责之一，同时也是成本最低的履行事项之一。为董事会安排一次简短的年度培训，形成会议纪要并留存材料，只需某位人员花费一个上午。不做这件事，则会留下审核人足不出户即可发现的缺口。
董事会治理日历有其必要性
这些职责具有周期性，法规也明确如此。“批准并定期审查”这一表述在第 5(2) 条中反复出现。框架审查包含第 6(5) 条规定的四个触发条件。根据第 13(5) 条，高级 ICT 员工至少每年报告一次。通过附录将每一项转化为带日期、指定负责人的董事会交付事项，可将抽象义务转化为公司秘书能够跟踪的事项，并转化为证明其已发生的会议纪要。
在首页放置正式批准区块：版本、批准日期、批准机构、下次审查日期。RTS 第 2(2)(b) 条要求 ICT 安全策略标明其由管理机构正式批准的日期，因此框架下一层文件也应采用同样的规范。
🔗
第 7 节
将框架连接到运营现实
框架是最高层级文件。它规定做什么以及为什么做。其下的所有内容则规定如何做。第 6 条第 2 款将框架描述为包括“战略、策略、程序、ICT 协议和工具”，这等于把一个文件层级压缩进了一句话。
建议的文件层级
第 1 级，ICT 风险管理框架。由董事会批准，具有战略性，并在第 6 条第 5 款触发情形下进行审查。
第 2 级，策略。信息安全、ICT 业务连续性、访问控制、ICT 第三方风险。
第 3 级，标准。密码学、补丁、日志记录、网络分段。
第 4 级，程序。事件响应运行手册、恢复切换程序、访问权限认证、漏洞扫描。
将框架映射矩阵作为附录加入：列明每个章节、实施该章节的下级文件、负责人以及审查周期。它能在一页内展示完整性，并且在适用第 6 条第 3 款、主管机关要求提供关于框架的完整且最新信息时，这就是您要拿出的材料。
⚡
第 8 节
Venvera 的适用位置
Venvera 是一个合规平台，覆盖欧洲、中东、非洲和北美的各类框架。欧盟《数字运营韧性法案》（DORA）是其中之一，其处理方式与其他框架相同：义务被建模，证据关联到这些义务，能够回应多个框架的同一项控制措施会被复用，而不是重新构建。以下能力与 ICT 风险管理框架相关，并且目前均已在产品中提供。
ICT 风险管理框架模板
映射至 DORA 第 5 条至第 16 条的框架策略模板，以及另外 10 个 DORA 策略模板，覆盖事件管理、韧性测试、第三方风险、业务连续性、资产管理、访问控制、变更管理、加密和信息共享。
DORA 差距评估
针对 DORA 的结构化差距评估，按评估进行评分，并根据答案生成补救路线图。
风险与控制措施关联
风险和控制措施是相互关联的记录，而不是两张电子表格。每项风险都带有关联的控制措施、可能性和影响评分、负责人、处置方式和审查日期，这正是 Article 13(3) 期望您能够展示的可追溯性。
信息登记册
第 28(3) 条登记册，基于从 B_01.01 到 B_99.01 的 15 个官方模板构建，包含完整性评分、导出前校验，以及按照 ITS (EU) 2024/2956 表结构构建的 xBRL-CSV 导出包。
事件截止期限跟踪
被归类为重大的事件会以带日期、可勾选步骤的形式承载其通知截止期限，而 NIS2 重大事件则有独立的计时机制。
韧性测试登记册
记录排期、单项测试和审计发现，使第 24(1) 条要求的测试计划拥有记录，而不仅仅是日历提醒。
董事会仪表板和 KRI 董事会材料包
面向董事会的视图，承载框架评分、未结事件、策略和任务，并提供可下载的 KRI 董事会材料包，用于管理机构的报告节奏。
跨框架控制措施复用
ICT 风险管理框架并不是孤立存在的。如果同一项控制措施满足您持有的多个框架中的要求，框架映射会将其带入各框架，而不是让您为同一事项重复提供证据。
这些能力都不会替您编写框架。文件必须描述您的组织、风险容忍度以及您实际运行的控制措施。平台所改变的是批准之后发生的事情：文件所描述的风险、控制措施、测试、事件和第三方安排，是带有负责人和日期的实时记录，还是在董事会签署后一周就开始过时的文件夹。
只需编写一次框架，然后持续保持其有效。
Venvera 将 ICT 风险登记册、控制措施、韧性测试、事件和信息登记册作为相互关联的记录来管理，因此您批准的框架，也就是您能够提供证据的框架。
预约演示 →主要来源
- Regulation (EU) 2022/2554 (DORA)。第 4 条，比例原则。第二章，第 5 至 16 条，ICT 风险管理。第 17 至 23 条，事件管理和报告。第 24 至 27 条，韧性测试。第 28 至 30 条，ICT 第三方风险。自 2025 年 1 月 17 日起适用。
- Commission Delegated Regulation (EU) 2024/1774。RTS 规定 ICT 风险管理工具、方法、流程和策略，以及简化版 ICT 风险管理框架。第 2 至 27 条，完整框架。第 28 至 41 条，简化框架。
- Commission Delegated Regulation (EU) 2024/1772。关于 ICT 相关事件和网络威胁分类标准、重大性阈值以及重大事件报告细节的 RTS。
- Commission Delegated Regulation (EU) 2025/301。关于报告内容以及初始通知、中期报告和最终报告时限的 RTS。第 5 条规定了上文引用的截止期限。
- Commission Delegated Regulation (EU) 2024/1773。关于使用支持关键或重要职能的 ICT 服务之策略的 RTS，依据 DORA 第 28(10) 条。
- Commission Delegated Regulation (EU) 2025/532。关于支持关键或重要职能的 ICT 服务分包的 RTS，依据 DORA 第 30(5) 条。
- Commission Delegated Regulation (EU) 2025/1190。关于威胁导向渗透测试 (TLPT) 的 RTS，依据 DORA 第 26(11) 条。
- Commission Implementing Regulation (EU) 2024/2956。关于信息登记册标准模板的 ITS，依据 DORA 第 28(9) 条。参见我们的15 个官方模板指南。
本文仅供参考，不构成法律或监管建议。条文引用已于 2026 年 7 月 14 日对照《欧盟官方公报》文本进行核验。技术标准会随时间修订，因此，在依赖本文所述任何截止期限或要求之前，请确认当前有效版本。
