合规指南
DORA 从未使用“关键风险指标”这个说法。不过，它确实要求您定义阈值并据此采取行动，这其实是同一项工作，只是名称不同。
欧盟《数字运营韧性法案》（DORA），即 Regulation (EU) 2022/2554，已自 2025 年 1 月 17 日起适用。它共有 64 条。搜索“DORA KRIs”，您会看到一些指标清单，声称某条或某条要求这些指标；令人意外的是，其中相当多清单引用的条款并没有表达其所声称的内容，少数情况下甚至引用了不存在的条款。因此，本指南的目标很明确，也可核验：14 项指标，每一项都对应到其实际可帮助您提供证据的条款，并在关键之处引用条款原文。
先说明两点，以便您正确理解下文。第一，阈值是我们设定的，不是监管机构设定的。 DORA 在任何地方都没有设定数字化 KRI 阈值。本文中的每个百分比和数量，都是说明性的起点，您应根据自身风险偏好进行调整。任何把某个阈值说成 DORA 要求或行业基准的人，都是在自行编造。第二，与阈值最接近的文本依据是第 10(2) 条，其中要求检测机制“定义警报阈值和标准，以触发并启动 ICT 相关事件响应流程”。这正是 KRIs 所服务的义务。
| DORA 是否要求 KRIs？ | 并未点名要求。该术语没有出现在法规中。第 6(1) 条要求持续监测 ICT 风险，第 10(2) 条要求设置可触发事件响应的警报阈值。KRIs 是实现这两者的标准工具。 |
| DORA 是否设定 KRI 阈值？ | 没有。对任何指标都没有设定一个数字阈值。本文中的所有数字都是我们的说明性默认值。 |
| 哪些数字来自法律 | 事件报告时限。那些小时数是固定的，并且由 Commission Delegated Regulation (EU) 2025/301 设定，而不是由 DORA 本身设定。 |
第 5 条：治理与组织
第 5(2) 条要求管理机构亲自参与：其必须“定义、批准、监督并负责实施与 ICT 风险管理框架有关的所有安排”。第 5(2)(i) 条随后要求其建立报告渠道，确保其充分知悉第三方安排、重大变更以及至少重大事件。
由此产生的监管问题并不是“您是否有指标？”，而是“董事会实际看到了什么，以及当某项指标为红色时，董事会采取了什么行动？” 单一指标无法回答这个问题。汇总视图可以。
在本指南中，第 5 条是在纸面上最容易满足、但要真实满足最困难的义务。制作一份董事会材料只需要一个下午。让董事会对红色指标提出质询，并留下该质询的书面痕迹，则是需要几个周期才能形成的习惯改变。请尽早开始，因为这是本清单中您无法购买或自动化的一项。
KRI 1：综合领域健康评分
针对每个风险领域给出一个 0 到 100 的单一评分，由其下的组成指标构建而成，使董事会看到整个环境的态势，而不是 14 个彼此割裂的数字。这一汇总视图让第 5(2)(i) 条的报告渠道能够在董事会层面发挥作用。
方向：越高越好。示例阈值：我们的默认区间为：80 及以上为绿色，60 到 79 为琥珀色，低于 60 为红色。请设定您自己的阈值。
第 6 条：ICT 风险管理框架
第 6 条第 (1) 款要求建立健全、全面且有充分文档记录的 ICT 风险管理框架，使您能够“快速、高效、全面地处理 ICT 风险”。第 6 条第 (5) 款要求对该框架进行文档记录，并至少每年审查一次，同时在发生重大事件、收到监管指示，或根据测试和审计结论后进行审查。第 6 条第 (8) 款要求该框架包含数字运营韧性战略，其中包括 (b) 项下的 ICT 风险容忍水平。
这个风险容忍水平就是关键。一旦您写明了容忍度，“我们是否已经超出容忍度？”就变成了一个可衡量的问题；而有文档记录的容忍度却没有任何指标去衡量，是整个框架中最薄弱的一环。
撰写容忍度声明只是较容易的一半，大多数公司其实已经完成。真正的阻力在于就什么情况算作突破容忍度达成一致，因为一旦某个数字让容忍度变得真实，就必须有高级管理人员对越线后的后果负责。预计这场讨论会比起草文本花更长时间。
KRI 2：高于容忍度的关键风险
剩余评级超过第 6 条第 (8) 款 (b) 项下所设定并记录的 ICT 风险容忍水平的关键级 ICT 风险数量。如果该数值高于零而无人升级处理，那么容忍度声明就只是装饰。
方向：越低越好。示例阈值：绿色 0，琥珀色最高 2，红色高于 2。
KRI 3：已超过审查日期的策略
下一次审查日期已过期的已批准策略占比。第 6 条第 (5) 款将框架年度审查规定为一项义务，而组成该框架的策略如果已经悄然过期，就经不起审计师的检验。
方向：越低越好。示例阈值：绿色为 5 percent 或以下，琥珀色最高 15 percent，红色高于 15 percent。
KRI 4：审查逾期的风险
下一次审查日期已过但未记录更新审查的风险数量。这是上一个指标的配套指标，但对象是风险登记册，而不是策略集合。
方向：越低越好。示例阈值：绿色最高 2，琥珀色最高 10，红色高于 10。
第 9 条和第 10 条：保护、预防和检测
第 9 条要求采取保护和预防措施。第 10 条才是指标设计中最重要的条款，也是 KRI 指南中最常被错误归因的条款，这些指南往往把其内容归到第 6 条第 (8) 款。准确地说：第 6 条第 (8) 款是数字运营韧性战略。异常检测属于第 10 条。
第 10 条第 (1) 款：“金融实体应建立机制，以便根据第 17 条及时检测异常活动，包括 ICT 网络性能问题和 ICT 相关事件，并识别潜在的重大单点故障。”
第 10 条第 (2) 款：检测机制应“实现多层控制，定义警报阈值和触发及启动 ICT 相关事件响应流程的标准，包括针对负责 ICT 相关事件响应的相关员工的自动警报机制。”
“定义警报阈值和触发及启动 ICT 相关事件响应流程的标准”几乎就是欧盟《数字运营韧性法案》（DORA）对 KRI 计划的描述。它还告诉您阈值的用途是什么：不是幻灯片上的一种颜色，而是启动响应的触发条件。
KRI 5：平均控制措施有效性
在最近一次测试中被评定为有效的已实施控制措施占比。第 9 条问的是保护措施是否存在；该指标问的是它们是否有效，这是更难、也更有用的问题。
方向：越高越好。示例阈值：绿色为 85 percent 或以上，琥珀色为 70 percent 或以上，红色低于 70 percent。
KRI 6：超过 30 天仍未关闭的高危或严重漏洞
发现时间超过 30 天且仍未关闭的高严重性漏洞数量。它可以直接反映检测结果是在推动修复，还是只是在填满一个队列。
方向：越低越好。示例阈值：绿色最高 5，琥珀色最高 20，红色高于 20。
第 17 至 19 条：事件管理与报告计时
第 17 条要求建立 ICT 相关事件管理流程。第 18 条规定了将事件分类为重大事件的标准。第 19(4) 条要求提交三项材料，即初始通知、中期报告和最终报告，但它完全没有规定任何截止期限：它将时间限制交由技术标准规定。
这一点很重要，因为几乎到处都在错误引用这只“时钟”，包括一些其他方面相当严谨的指南。截止期限载于 Commission Delegated Regulation (EU) 2025/301 第 5(1) 条：
| 提交项 | 截止期限，引自 RTS 2025/301 第 5(1) 条 |
| 初始通知 | “within four hours from the classification of the ICT-related incident as a major ICT-related incident and no later than 24 hours from the moment the financial entity has become aware of the ICT-related incident” |
| 中期报告 | “at the latest within 72 hours from the submission of the initial notification” |
| 最终报告 | “no later than one month after either the submission of the intermediate report, or, where applicable, after the latest updated intermediate report” |
您自己的运行手册中需要检查的错误。72 小时对应的是中期报告。它非常普遍地被说成是最终报告的截止期限，同时 24 小时又被错误描述为中期报告的期限。24 小时这个数字是初始通知的外部上限，按知悉事件的时间起算，而不是按分类时间起算。如果您的事件程序把这些顺序对调了，那么您的升级时点就是错的，而且这种错误往往只会在已经来不及补救时才暴露出来。
真正让人吃痛的是初始通知窗口。它看起来可执行，直到您开始计算其中必须容纳哪些事项：有人要对事件进行分类，有高级人员要同意该分类，还要有人起草一份法律部门愿意背书的提交材料。现在就以书面形式决定，谁有权在半夜无需召集任何人会议的情况下，将事件分类为重大事件。这个单一决定对报告及时性的帮助，比任何仪表板都更大。
KRI 7：未关闭的重大事件
根据第 18 条被分类为重大事件且仍未关闭或仍在处理中的事件数量。这是董事会最先会询问的数字。
方向：越低越好。示例阈值：绿色 0，琥珀色最高 2，红色高于 2。
KRI 8：错过监管报告截止期限的事件，滚动 90 天
过去 90 天内违反法定报告截止期限的事件数量。这个指标绝不应处于琥珀色。错过截止期限本身就是一项需要报告的失效，因此该指标衡量的是合规违规。
方向：越低越好。示例阈值：绿色 0，琥珀色 1，红色高于 1。这里完全不设置琥珀色区间也有充分理由。
KRI 9：严重 ICT 风险的平均修复时间
严重 ICT 风险从识别到关闭的平均天数。第 6(1) 条要求“quickly, efficiently and comprehensively”处理 ICT 风险；在这个短语中，只有这个词可以量化。
方向：越低越好。示例阈值：绿色为 45 天或以下，琥珀色为 90 天或以下，红色高于 90 天。
第 24 至 27 条：韧性测试
第 24(1) 条要求金融实体将测试计划作为 ICT 风险管理框架的组成部分，微型企业除外。第 24(6) 条是其中带有明确数字的条款：对于支持关键或重要职能的所有 ICT 系统和应用，必须至少每年开展一次适当测试。第 25(1) 条列出了可采用的测试类型。
在本指南涉及的所有内容中，测试计划是最容易被悄悄交付不足的要求。编写计划并不复杂。真正容易滑落的，是让业务部门每年为每个关键或重要职能背后的每个系统释放人员和环境来执行测试。如果您的计划与已完成测试之间已经出现偏离，应在监管机构替您发现差距之前修正计划，并记录变更原因。
关于威胁导向渗透测试 (TLPT)，有一点值得纠正，因为它被反复误传：第 26(1) 条下的 TLPT 至少每三年开展一次，但并非针对“最大型实体”或“重要机构”。它适用于主管机关根据第 26(8) 条认定的实体。规模与此相关，但触发条件是被指定，而不是规模，且由主管机关作出决定。
KRI 10：韧性测试按计划完成
计划内韧性测试在其计划窗口内完成的比例，包括恢复演练和场景测试。第 24 条中的计划是一项测试义务，而无人执行的计划，是最常见的悄然失败方式。
方向：越高越好。示例阈值：90 percent 或以上为绿色，75 percent 或以上为琥珀色，低于 75 percent 为红色。
第 28 至 30 条：ICT 第三方风险
这是最消耗日程的部分。信息登记册本身是繁琐而非困难，直到您必须描述分包外包，并发现您的服务提供商不愿告诉您其自身服务提供商是谁。合同要素更难：重新打开正在履行的合同以加入审计和访问权，对于每个重要供应商都需要一个月的追踪推动；而您的规模越小，可用于推动的议价能力就越弱。应先处理支持关键或重要职能的服务提供商，并接受这样一个现实：当信息登记册提交时，长尾部分仍会处于未完成状态。
第 28 条要求对 ICT 第三方风险进行持续管理，第 28(3) 条要求建立信息登记册。第 28(8) 条要求为支持关键或重要职能的服务制定退出策略。第 29 条要求对 ICT 集中度风险进行初步评估，包括某一服务提供商是否“不易替代”。第 30(2) 条在 (a) 至 (i) 项中列明每项 ICT 安排必须包含的九项合同要素，第 30(3) 条则对关键或重要职能增加了更多要求。
KRI 11：存在逾期风险评估的关键供应商
最近一次风险评估已超过一年的关键或重要 ICT 服务提供商比例。第 28 条下的持续监控是一项连续性义务。
方向：越低越好。示例阈值：5 percent 或以下为绿色，15 percent 或以下为琥珀色，高于 15 percent 为红色。
KRI 12：前 5 大供应商支出集中度
年度 ICT 支出中流向五大服务提供商的比例。这是一个粗略工具，但也是以最低成本暴露第 29 条所关注的可替代性问题的指标。
方向：越低越好。示例阈值：低于 50 percent 为绿色，低于 70 percent 为琥珀色，70 percent 或以上为红色。
第 31 条：关键 ICT 第三方服务提供商与集中度
第 31 条赋予 ESAs 权力，可指定关键 ICT 第三方服务提供商，并将其纳入监督框架。该章节的整体设计反映了一种系统性担忧：少数服务提供商服务于 EU 金融业的大部分机构。在您的实体层面，与这种担忧相对应的事项，应通过集中度指标来衡量。
KRI 13：供应商支出 HHI
ICT 供应商支出的赫芬达尔-赫希曼指数，即各供应商支出占比百分数的平方之和。它能反映前 5 大占比无法反映的问题：集中度是集中在一个服务提供商身上，还是分散在多个服务提供商之间。
方向：越低越好。阈值示例：低于 1,500、1,500 至 2,500、高于 2,500。请参见紧随其后的说明，因为这些数字是借用的，并非监管要求。
KRI 14：由单一服务提供商支撑的关键职能
统计背后恰好只有一个服务提供商支撑的关键或重要职能数量。每一项都是单点故障，且第 10(1) 条明确要求您识别潜在的重大单点故障。
方向：越低越好。阈值示例：最高 1 为绿色，最高 3 为琥珀色，高于 3 为红色。
HHI 分段实际来自哪里。DORA 并未规定 HHI 阈值，欧洲监管机构也未发布任何阈值。1,500 和 2,500 这两个分段来自竞争政策：它们是美国司法部和联邦贸易委员会发布的 2010 US Horizontal Merger Guidelines 中的集中度阈值，该指南将低于 1,500 的市场视为非集中，1,500 至 2,500 视为中度集中，高于 2,500 视为高度集中。它们只是一个合理借用的衡量尺度，仅此而已。它们不是 EU 标准，不是 DORA 标准，而且 European Commission's 自身的并购指南使用的是完全不同的分段。请将其作为起始尺度，而不是合规目标。
指标转为红色后会发生什么
转为红色并发送电子邮件的指标，是一个仪表板。转为红色并启动流程的指标，才是一项控制措施。主管机构询问您会据以采取行动的阈值时，关注的正是这种差别；第 10(2) 条也明确规定，阈值的存在是为了“触发并启动 ICT 相关事件响应流程”。
就条文本身而言，第 10(2) 条是 DORA 中起草得较好的规定之一。它没有陷入规定具体指标的诱惑，而是说明了阈值的用途。这让您可以自由选择适合自身环境的指标，同时也消除了您的借口，因为法规已经清楚说明了什么才是良好做法。
设计原则很直接。当一个指标进入红色区间时，应当无需任何人再作决定，就自动发生三件事：记录该违规情况，包括触发它的数值以及负责的负责人；如果该违规意味着存在应报告事件，应立即开立事件，而不是等到会议之后；报告截止期限应从检测时刻开始计算，而不是从某个人想起来时开始计算。
最后一点正是上一节中的时钟不再只是细枝末节的地方。如果您的工具计算出的截止期限错误，它会告诉您仍然稳稳处在时间窗口内，而事实上您已经错过了期限。无论您使用什么工具，包括下文描述的任何工具，都请您自行根据 RTS 2025/301 第 5(1) 条核对其生成的截止期限计算。
常见问题
DORA 是否明确要求关键风险指标？
没有。“关键风险指标”这一术语并未出现在 Regulation (EU) 2022/2554 中。法规要求的是其底层功能：第 6(1) 条要求建立一个 ICT 风险管理框架，使您能够快速、高效、全面地应对 ICT 风险；第 10(2) 条要求检测机制定义警报阈值和标准，以触发并启动事件响应流程。KRI 是履行这一要求的常规工具。因此，诚实的表述是，DORA 要求完成这项工作，而不是指定某个工具；任何告诉您该法规按名称强制要求 KRI 的人，都没有读过该法规。
本文中的阈值是监管要求还是行业基准？
都不是。本文中的每一个数字，无论是 70%、85%、90%，还是各项计数和 HHI 分段，都是我们为了让这些指标足够具体、便于讨论而选定的示例性默认值。欧盟《数字运营韧性法案》（DORA）在任何地方都没有设定数值化的 KRI 阈值，欧盟也没有为这些指标发布过任何基准数据集。请根据您自己的风险偏好和 IT 环境的规模对它们进行调整。如果某个供应商或顾问向您介绍某个阈值时，称其为“DORA 要求”或“行业标准”，请让他们给出出处，而且要做好得不到出处的准备。
DORA 真正的事件报告截止期限是什么？
四小时、72 小时、一个月。准确地说：初始通报须在将事件归类为重大事件后四小时内提交，且无论如何不得晚于知悉该事件后 24 小时；中期报告最迟须在初始通报后 72 小时内提交；最终报告不得晚于中期报告提交后一个月，如适用，则不得晚于最近一次更新的中期报告提交后一个月。这些期限由委员会授权条例 (EU) 2025/301 第 5(1) 条规定，而不是由 DORA 本身规定，因为 DORA 第 19(4) 条只列明了这三项报送，并将时限交由技术标准来规定。常见的错误是把 24 小时说成中期报告的期限、把 72 小时说成最终报告的期限。这两种说法都是错的。
哪一条要求进行异常检测：第 6(8) 条还是第 10 条？
第 10 条。之所以要直截了当地说明这一点，是因为在 KRI 指南中，这种张冠李戴的情况很常见，而本文的早期版本也犯过同样的错误。第 10(1) 条要求建立能够及时检测异常活动、并识别潜在的重大单点故障的机制，第 10(2) 条则要求这些机制设定告警阈值。第 6(8) 条完全是另一回事：它要求 ICT 风险管理框架包含一项数字运营韧性战略，并在 (b) 项中确立 ICT 风险容忍度水平。
1,500 和 2,500 的 HHI 分段是 DORA 的官方数值吗？
不是。DORA 没有规定任何 HHI 阈值，欧洲监管机构（ESAs）也从未发布过任何此类阈值。这些分段来自美国司法部和联邦贸易委员会发布的 2010 年《横向合并指南》，其中 HHI 低于 1,500 的市场为非集中市场，1,500 到 2,500 为中度集中，高于 2,500 为高度集中。它们是从竞争政策中借用的衡量尺度，而不是欧盟的监管标准，而且欧盟委员会在其自己的合并指南中使用的是不同的分段。请把它们当作推理时使用的参考刻度，不要在内部把它们说成合规阈值。
威胁导向渗透测试实际上适用于哪些主体？
适用于主管机关根据第 26(8) 条、在对影响、系统性特征以及 ICT 风险状况和成熟度进行评估后所认定的主体。它并不是笼统地适用于“规模最大的主体”或“重要机构”这一类别，也不是您可以通过自我评估纳入其中的。随后，第 26(1) 条要求这些被认定的主体至少每三年开展一次 TLPT。未被认定的主体仍需根据第 24 条和第 25 条执行一般测试计划，包括第 24(6) 条要求的、对支持关键或重要职能的系统至少每年进行一次的测试。
一手资料来源
本指南中的每一个条款编号都已对照条例原文进行了核对。条款数量、截止期限以及阈值的来源，全部来自以下资料。
- 条例 (EU) 2022/2554（DORA）：第 5、6、9、10、13 条，第 17 至 19 条，第 24 至 27 条，第 28 至 31 条。该条例共有 64 条，自 2025 年 1 月 17 日起适用。
- 委员会授权条例 (EU) 2025/301：第 5(1) 条规定了四小时、72 小时和一个月的报告截止期限。
- 委员会授权条例 (EU) 2024/1774：关于 ICT 风险管理工具、方法、流程和策略的监管技术标准（RTS）。
- 2010 年《横向合并指南》（美国司法部和联邦贸易委员会）：1,500 和 2,500 这两个 HHI 集中度分段的真正出处。
在 Venvera 中如何运作
上述十四项指标中，有十三项作为预置条目随 Venvera 的 KRI 目录一同提供。第十四项，即综合领域健康评分，根本不是目录条目：它是董事会材料根据十个风险领域下的各项指标汇总计算出的结果。其余部分也值得说得准确一些，因为这个目录并不是一个专门针对欧盟《数字运营韧性法案》（DORA）的目录。它提供 23 项指标，并针对多个监管制度打上了标签，其中包括 DORA 和 ISO 27001，这就是为什么本文中的映射是作为我们自己的映射来呈现的：我们把每项指标关联到了它有助于提供证据的 DORA 条款，而不是假装产品为每一项指标都标注了某个 DORA 条款。
每项指标都带有一个方向（让系统知道数值上升是好是坏）、一个琥珀色阈值和一个绿色阈值、一名负责人、一个测量频率以及历史记录。其中十四项会根据平台中已有的数据按计划自动计算，数据来自风险登记册、事件记录、控制措施库和第三方数据，因此这个数字并不是某人凭记忆每季度往表单里填一次的结果。
每项指标还有一个设置，可以在其进入红色区间时自动创建一个关联事件，该事件会记录此次越限及其触发值和责任负责人，并将报告截止期限交给一个后台任务，由它每五分钟重新检查一次，而不是等待有人注意到。董事会材料也是根据同样的数据生成的：十个风险领域的领域健康状况、自上次快照以来出现退步的指标，以及仍未关闭的越限事项。
我们不会告诉您的是，这样就免除了您核对计算的义务。截止期限的逻辑恰恰是那种会悄无声息地出错的东西，在工具和操作手册中都是如此，因此无论您使用什么，都请对照 RTS 2025/301 第 5(1) 条进行验证，而不是轻信某个标签。
DORA 是大多数金融实体同时需要承担的多项监管制度之一，而指标是这些制度之间最可复用的工件之一。框架映射引擎的作用，就是让某项指标背后的证据无需重新构建即可服务于欧盟 NIS2 指令或 ISO 27001。如果您想快速了解自己的现状，请运行一次免费合规检查。
最后更新：2026 年 7 月。本文为一般性信息，不构成法律意见。本文中的所有阈值均为 Venvera 选定的示例性默认值，而不是监管要求或行业基准。请对照现行条文和您所在主管机关的指引，核实所引用的条款。
