合规指南
第 24 条很短，只有六款。许多被归因于它的内容其实并不在其中，因此本指南会引用原文，并明确说明其余内容来自哪里。
数字运营韧性测试计划位于Regulation (EU) 2022/2554第 IV 章，涵盖第 24 条至第 27 条。第 24 条规定计划义务，第 25 条列明测试类型，第 26 条和第 27 条规制威胁导向渗透测试。DORA 自 2025 年 1 月 17 日起适用。
在围绕这些说法建立计划之前，有三件您可能会在其他地方读到、且值得核查的事：第 24 条要求董事会批准测试计划，第 25 条强制规定十类测试的固定清单，以及每三年必须进行一次渗透测试。第一项只有通过一连串值得审视的推理才成立。第二项和第三项完全不成立。
| 计划义务 | 第 24 条第 1 款。适用于微型企业以外的金融实体。 |
| 第 24 条中唯一固定的频率 | 第 24 条第 6 款：至少每年一次，对支持关键或重要职能的所有 ICT 系统和应用开展适当测试。 |
| 谁执行测试 | 第 24 条第 4 款：由独立方执行，无论是内部还是外部。内部测试人员需要专门资源，并需要管理利益冲突。 |
| 测试类型 | 第 25 条第 1 款提供的是示例性清单，由“such as”一词引出。它不是十项强制检查清单。 |
| 威胁导向渗透测试 | 第 26 条第 1 款：至少每 3 年一次，但仅适用于由其主管机构根据第 26 条第 8 款确定的实体。 |
| DORA 对测试成本的规定 | 没有规定。它没有设定任何金额。请参见下文关于成本的部分。 |
第 24 条实际说了什么
第 24 条第 1 款要求金融实体，微型企业除外，“建立、维护并审查健全且全面的数字运营韧性测试计划，作为第 6 条所述 ICT 风险管理框架的组成部分”。最后这个从句才是关键，我们在讨论董事会时会回到这一点。
第 24 条是 DORA 中起草较好的部分之一：简短，没有交叉引用迷宫，并且坦诚承认测试计划需要判断。它造成的困难与通常情况相反。由于规定极少，您计划中的几乎所有内容都需要由您自行作出决定并加以辩护，而为一项决定提供证据比勾选清单更难。
本文其余部分，简要并按其自身表述如下：
| 段落 | 要求内容 |
| 24(1) | 建立、维护并审查该计划，将其作为 ICT 风险管理框架的组成部分。微型企业不在此范围内。 |
| 24(2) | 该计划包括按照第 25 条和第 26 条适用的一系列评估、测试、方法、实践和工具。 |
| 24(3) | 遵循基于风险的方法，考虑不断变化的 ICT 风险格局、特定风险，以及信息资产和服务的关键性。 |
| 24(4) | 测试由独立方开展，可以是内部或外部。内部测试人员需要有足够的专用资源，并在设计和执行环节避免利益冲突。 |
| 24(5) | 建立程序和策略，对测试揭示的所有问题进行优先级排序、分类和补救，并建立内部验证方法，以确认所有已识别的弱点、缺陷或差距均已得到充分处理。 |
| 24(6) | 至少每年对支持关键或重要职能的所有 ICT 系统和应用程序开展适当测试。 |
请注意缺失的内容。第 24 条并未提及管理机构。除 24(6) 中的年度测试外，它没有设定其他频率。它也没有授权制定监管技术标准。如果您见过有人引用“第 24(2) 条下的 RTS”，实际上并不存在；本章中相关的 RTS 是第 26(11) 条授权的 TLPT RTS。
董事会真的必须批准测试计划吗？
是的，但并不是因为第 24 条这样规定；当有人要求您指出具体句子时，这一区别很重要。第 24 条对管理机构保持沉默。该义务来自两项规定的结合解读：
第 24(1) 条：测试计划是“第 6 条所述 ICT 风险管理框架的组成部分”。
第 5(2) 条：“金融实体的管理机构应界定、批准、监督并负责实施与第 6(1) 条所述 ICT 风险管理框架相关的所有安排。”
该计划是框架的组成部分。董事会必须批准与框架相关的所有安排。因此，董事会必须批准该计划。
取得批准本身并不难：一个简短议程项和一份有会议记录的决议即可。真正的工作在于准备一份值得提交董事会的计划，并且能够在监管人员面前毫不迟疑地说明该义务的来源。
这是一条稳妥的逻辑链，监管机构也会这样理解。但它毕竟是一条推理链，您应当在一开始就清楚这一点，而不是在被质询时才发现。第 5(2) 条确实在 (a) 至 (i) 项列出了具体批准职责，而测试计划并不属于其中被点名的事项。该清单点名的事项，也就是您应预期需要单独提供证据的事项，包括 (d) 项的数字运营韧性战略、(e) 项的 ICT 业务连续性策略以及响应和恢复计划、(f) 项的 ICT 内部审计计划、(g) 项的预算，以及 (h) 项的 ICT 第三方策略。
还有两项规定值得直接提交董事会。第 5(4) 条要求成员“主动保持最新且充分的知识和技能，以理解并评估 ICT 风险”，包括定期接受专项培训。第 50(5) 条规定，成员国应赋予主管机关权力，在遵守本国法律的前提下，“对管理机构成员，以及根据本国法律对违规行为负有责任的其他个人”适用行政处罚和补救措施。
因此，个人责任暴露是真实存在的，但其存在方式是该法规特定构造出来的：通过本国法律，并依据第 50(5) 条。它不是一种泛泛而谈的威胁；向董事会准确描述这一点，比夸张渲染更有说服力。
第 25 条：示例性清单，而非强制十项
这是目前流传最广、后果也最严重的误读。第 25 条第 1 款规定，该计划“应规定……执行适当测试，例如漏洞评估和扫描、开源分析、网络安全评估、差距分析、物理安全审查、问卷和扫描软件解决方案、在可行情况下进行源代码审查、基于场景的测试、兼容性测试、性能测试、端到端测试以及渗透测试”。
“例如”是列举说明。义务是执行适当的测试，并按照第 24 条第 3 款要求的基于风险的方法进行选择。这不是一份必须勾选十个项目的合规清单；如果一个计划没有风险理由，却机械地把列出的每一种技术都用于每一个系统，可以说它反而比一个判断何为适当并记录理由的计划，更偏离第 24 条第 3 款。
写下这项理由并不费时，对于大多数环境来说，一个下午即可完成，而且这是整个计划文件中价值最高的一页。机械地把清单上的每一种技术都用于每一个系统，会花掉一整年的预算，看起来很忙，却仍然缺少第 24 条第 3 款真正要求的那一项。
下面是第 25 条第 1 款的完整清单，并附有节奏列。这些节奏是我们的建议，仅作为起点。 除第 24 条第 6 款中的年度义务外，欧盟《数字运营韧性法案》（DORA）并未为其中任何一项设定频率。如果您采用这些节奏，应将其作为您自己的决定，而不是监管要求。
| 测试类型（第 25 条第 1 款用语） | 示例节奏（我们的建议，并非 DORA 的要求） | 说明 |
| 漏洞评估和扫描 | 持续或每月 | 中央证券存管机构和中央对手方根据第 25 条第 2 款负有一项具体义务：在任何部署或重新部署之前执行这些测试。 |
| 开源分析 | 持续 | 尽管文本中明确列名，但在第 25 条的摘要中常常被完全遗漏。 |
| 网络安全评估 | 每季度或每半年 | 分段、防火墙规则、访问路径。 |
| 差距分析 | 每年 | 为第 6 条第 5 款的框架评审提供输入。 |
| 物理安全审查 | 每年 | 第 25 条第 1 款明确列名；在仅关注 ICT 的计划中经常被遗忘。 |
| 问卷和扫描软件解决方案 | 视情况而定 | 同样在文本中列名，也通常缺失于“十种类型”清单。 |
| 源代码审查，在可行情况下 | 每次发布 | 法规中包含“在可行情况下”这一表述。不可行时，应记录理由。 |
| 基于场景的测试 | 每半年或每年 | 桌面推演和模拟。 |
| 兼容性测试 | 每次重大变更 | 更新和迁移后的互操作性。 |
| 性能测试 | 每季度或每半年 | 负载、压力、容量。 |
| 端到端测试 | 每半年或每年 | 包括故障切换和恢复在内的完整流程链。 |
| 渗透测试 | 关键系统每年 | 普通渗透测试。它与 TLPT 不是同一回事，DORA 也没有为其设定单独频率。 |
应从您的方案文件中删除的两项说法。第一：“渗透测试必须至少每三年执行一次。”DORA 并未这样规定。第 26(1) 条中的三年周期属于威胁导向渗透测试，并且仅适用于根据第 26(8) 条确定的实体。普通渗透测试在 DORA 下没有自己的频率要求；适用的是第 24(6) 条，该条要求对支持关键或重要职能的系统至少每年进行适当测试。第二：“第 25 条使用了 shall include 的表述，因此所有类型都是强制性的。”它使用的是“such as”。
实际适用范围
这里值得谨慎，因为豁免范围经常被错误表述，而且它们并非同一种豁免。
- 第 24 条的方案义务适用于微型企业以外的金融实体。微型企业不在该方案要求本身的范围内。
- 第 25(3) 条说明微型企业应如何处理第 25(1) 条中的测试：将基于风险的方法与战略规划相结合，在资源和时间与紧迫性、风险类型及关键性之间取得平衡。因此，它们并非免于测试，而是适用不同的规则。
- 第 16(1) 条又是另一回事：它为一个特定的封闭实体清单规定了简化的 ICT 风险管理框架，包括小型且非互联的投资公司，以及某些获得豁免的支付机构和电子货币机构。它不是微型企业制度，将两者混为一谈是常见错误。
- 第 26(1) 条下的 TLPT同时排除了微型企业和第 16(1) 条实体，并且仅适用于主管机关根据第 26(8) 条确定的那些实体。
微型企业豁免和第 16(1) 条简化制度经常被混淆，这一错误在两个方向上都会带来高昂代价：企业要么将自己排除在本应履行的方案之外，要么构建了原本不需要的方案。仔细阅读这两个定义，一次即可厘清。
如果您不确定自己属于哪一类，这一判定本身就是监管机构可能要求提供的一项证据。请将其写下并注明日期。
构建年度方案
合规的方案是一份受治理的文件，将测试活动与您的 ICT 风险格局相连接，并明确负责人、时间线，以及从审计发现到补救再到董事会的路径。以下六个组成部分按其相互依赖顺序排列。
1. 范围
从关键或重要职能开始，因为第 24(6) 条正是将年度义务锚定在这些职能之上。DORA 在第 3(22) 条将关键或重要职能定义为：其中断“将实质性损害金融实体的财务表现，或其服务和活动的稳健性或连续性”的职能。支持这些职能的每个 ICT 系统和应用程序都属于至少每年测试一次的范围，包括由第三方提供支持服务的情形。
2. 日历
将每一种选定的测试类型映射到相应频率，并清楚标明哪些频率来自监管要求，哪些是您自行设定的。只有一项是监管要求：根据第 24(6) 条，对支持关键或重要职能的系统进行年度测试。对于根据第 26(8) 条确定的实体，TLPT 至少每三年运行一次。您日历上的其他所有内容，都是您基于风险作出的选择，并且必须能够根据第 24(3) 条加以证明。
3. 测试由谁执行
第 24(4) 条要求测试人员保持独立，可以是内部或外部人员。如果使用内部测试人员，您必须投入足够资源，并在测试设计和执行两个环节避免利益冲突。TLPT 对此要求明显更严格：根据第 27(2) 条，使用内部测试人员执行 TLPT 需要主管机关批准，并核实您已具备足够的专用资源且已管理利益冲突，同时威胁情报提供商必须是实体外部机构。第 26(8) 条还规定，使用内部测试人员的实体每三次测试必须聘请外部测试人员，而被分类为重要的信贷机构只能使用外部测试人员。
4. 优先级排序
第 24 条第 (3) 款要求采用基于风险的方法，并明确了需要权衡的因素：不断演变的 ICT 风险态势、实体所面临的具体风险、信息资产和服务的重要性，以及实体认为适当的任何其他因素。最后这一项给了您裁量空间，而如果您在使用裁量空间时没有写明理由，就无法为其辩护。
5. 审计发现
第 24 条第 (5) 款是最常被转述成并非原意的段落。其原文是：金融实体“应建立程序和策略，对测试过程中发现的所有问题进行优先级排序、分类和补救，并应建立内部验证方法，以确认所有已识别的薄弱点、缺陷或差距均已得到充分处理。”
这里有两项义务。对问题进行优先级排序、分类和补救；并且验证这些问题已得到充分处理。第二项往往是各类计划会跳过的环节，也正因如此，仅凭工程师的保证就关闭一项审计发现是不够的。按严重性设定分级以及相应的补救截止期限是合理做法，但如何设定由您决定：DORA 并未规定。
验证是测试计划悄然失效的地方。重新测试一项修复的成本，只是发现该薄弱点成本的一小部分；但当季度工作繁忙时，被删掉的往往正是这一步，而这也是监管机构最容易追问的内容：谁确认了这项关闭，他们实际查看了什么。
6. 董事会报告
明确哪些内容应提交管理机构，以及何时提交。第 5 条第 (2)(i) 项要求建立报告渠道，使董事会了解包括至少重大 ICT 相关事件及其影响，以及响应、恢复和纠正措施在内的信息。测试结果自然应与之配套。关键审计发现不应等到季度周期才上报。
测试成本是多少，以及为什么本文不再给出数字
本文早先版本曾引用过一些数字：外部渗透测试为 EUR 15,000 至 50,000，一次 TLPT 项目为 EUR 150,000 至 500,000，历时 6 到 12 个月。这些数字现已删除，值得说明原因，而不是悄悄删掉。
这些数字无法找到可靠来源。DORA 未设定任何金额。ECB 的 TIBER-EU framework 和 TLPT 技术标准描述了各阶段和所需角色，但没有公布成本。ESAs 也没有。市场上存在的是一些供应商和咨询机构的估算，彼此相差数倍，这说明它们是针对不同范围的报价，而不是对某项事务的衡量。把其中一个数字加上欧元符号再重复一遍，只会把猜测包装成事实；如果董事会据此编制预算，随后发现真实数字相去甚远，那就是对董事会的误导。
有来源可支持的说法更窄，但更有用。第 5 条第 (2)(g) 项将预算本身规定为董事会职责：管理机构必须“分配并定期审查适当预算，以满足金融实体在各类资源方面的数字运营韧性需求”，包括 ICT 安全意识计划、韧性培训以及员工 ICT 技能。因此，董事会被要求为韧性提供充分资金，并重新审视该资金安排。在您的情况下，“充分”需要多少成本，取决于您的范围、资产环境和服务提供商；唯一可靠的办法是界定项目范围并获取报价。
DORA 不规定价格是正确的。写入法规的数字一年内就会过时，并会把每个实体锚定在一个为他人资产环境设定的数字上。令人不适的结果是，整个预算负担都落在您身上，而第一年正是企业一贯低估成本的年份。
从法规中可以看出的成本驱动因素，是工作的形态。TLPT 在使用内部测试人员时要求外部威胁情报服务提供商参与，涉及主管当局，依据第 26 条第 (2) 款针对实时生产系统开展，并遵循 TLPT 技术标准中的各个阶段。这在结构上就比一次扫描更昂贵。您不需要编造一个数字，也能向董事会说明这一点。
在 Venvera 中管理该计划
Venvera 设有韧性测试模块，其功能如下。测试会记录类型、范围、方法、测试服务提供商、计划日期和状态；这些信息来自 DORA 测试类型库，该库为每种测试类型提供推荐频率和范围指引。系统支持循环测试排期，仪表板会显示已计划、正在进行和逾期的测试。
审计发现挂接在产生该发现的测试之下，每项发现都有严重性、被指派人、截止日期、补救计划和补救状态，因此未关闭的审计发现有负责人和日期，而不是报告中的一行文字。这正是第 24 条第 (5) 款在“优先级排序、分类和补救”这半项义务中要求的机制。
验证这一半，即用于确认某项弱点已被完全解决的内部方法论，仍然是一项需要您自行运行的纪律。该模块会跟踪您设置的状态；它不会替您判定某项修复已被证明有效，我们宁愿把这一点说清楚，也不愿让您误以为存在一个实际上并不存在的关口。
DORA 是大多数金融实体同时承担的多项制度之一，而韧性测试证据是在这些制度之间最可复用的材料之一。框架映射引擎让一次生成的证据可以用于其在 NIS2 或 ISO 27001 下的对应要求，而无需重新构建。关于 TLPT 方面，具体请参阅我们关于第 26 条和第 27 条下威胁导向渗透测试的指南。
常见问题
DORA 第 24 条是否要求董事会批准测试计划？
并未以这样的文字表述，而且第 24 条根本没有提到管理机构。该义务确实存在，但它是通过两项条款的链条产生的。第 24(1) 条将测试计划规定为“第 6 条所述 ICT 风险管理框架的组成部分”，而第 5(2) 条要求管理机构定义、批准、监督并负责实施与该框架相关的所有安排。因此，计划的批准是由这两条共同推出的。请注意，第 5(2) 条确实在 (a) 至 (i) 项列出了具体批准职责，而测试计划并不在这些明示事项之中，所以任何声称第 24 条本身即强制要求董事会批准的人，都没有读过第 24 条。
第 25 条中的十类测试是否全部为强制要求？
不是。第 25(1) 条以“例如”引出其清单，这使其成为示例性清单，而非穷尽性或强制性清单。实际义务是执行适当的测试，并根据第 24(3) 条要求的基于风险的方法进行选择。该清单也不止十项，并包括开源分析以及“问卷和扫描软件解决方案”，这两项在流传的“十类强制测试”表格中经常被遗漏。应选择与您的风险相适应的测试，并记录理由。
DORA 要求多长时间进行一次渗透测试？
DORA 没有为普通渗透测试设定频率。声称每三年必须进行一次渗透测试，是将其与威胁导向渗透测试混淆了；第 26(1) 条要求至少每三年开展一次威胁导向渗透测试，且仅适用于主管机关根据第 26(8) 条识别出的实体。真正约束您的频率在第 24(6) 条中：对于支持关键或重要职能的所有 ICT 系统和应用，至少每年进行一次适当测试。对于某一特定系统而言，适当测试是否为渗透测试，是第 24(3) 条下基于风险的判断。
DORA 如何规定韧性测试计划的成本？
没有规定。DORA 没有设定任何成本数字，ECB's TIBER-EU 框架和 ESAs 也没有发布任何此类数字。流传的渗透测试和 TLPT 项目费用数字来自供应商和咨询机构的估算，差异很大，因为它们定价的范围不同。该法规实际规定的是第 5(2)(g) 条：管理机构必须分配并定期审查适当预算，以满足实体在所有类型资源上的数字运营韧性需求。预算是董事会职责；具体数字来自范围界定工作。
测试计划是否适用于微型企业？
第 24 条的计划义务适用于微型企业以外的金融实体，因此微型企业本身不属于该计划要求的适用范围。它们并不免于测试：第 25(3) 条要求其通过将基于风险的方法与 ICT 测试的战略规划相结合，开展第 25(1) 条所述测试，并在所分配的资源和时间与信息资产和服务的紧迫性、风险类型及关键性之间取得平衡。请将这一点与第 16(1) 条区分开来，后者是完全不同的排除安排，为特定封闭清单内的实体提供简化的 ICT 风险管理框架。
第 24(5) 条对审计发现究竟有哪些要求？
有两项要求，其中第二项通常会被忽视。按法规原文，实体“应建立程序和策略，对测试执行过程中发现的所有问题进行优先排序、分类和补救，并应建立内部验证方法，以确认所有已识别的弱点、缺陷或差距均已得到充分处理。”因此，您需要有分流和整改流程，也需要有一套验证方法，用于确认某项审计发现确实已经关闭。设置严重性分级和按严重性确定的整改截止期限是合理做法，但这由您自行决定：DORA 并未规定。
主要来源
本指南中的每一处条款引用、引文和频率均已根据以下文本核对。本文此前包含的成本数字已删除，因为没有主要来源支持这些数字。
- Regulation (EU) 2022/2554 (DORA) - 第 3(22)、5、6、16、24、25、26、27 和 50 条。该法规包含 64 条，并自 2025 年 1 月 17 日起适用。
- Commission Delegated Regulation (EU) 2025/1190 - 关于威胁导向渗透测试的 RTS：标准、测试人员要求、范围、阶段和方法。
- Commission Delegated Regulation (EU) 2024/1774 - 关于 ICT 风险管理工具、方法、流程和策略的 RTS。
- ECB TIBER-EU framework - 支撑 TLPT、基于威胁情报的道德红队测试框架。未发布任何成本数字。
最后更新：2026 年 7 月。一般信息，并非法律建议。本文建议的测试节奏是 Venvera 的示例性默认设置，并非监管要求；DORA 在第 24 条中唯一固定的频率是第 24(6) 条中的年度测试。请根据现行文本和您主管机关的指南确认条款引用。
