合规指南
您的风险登记册告诉您哪些事情可能出错。您的 KRI 告诉您，错误的事情是否正在此刻变得更有可能发生。
如果您曾坐在审计师对面，被问到“自上次评估以来，您如何知道 ICT 风险环境是否发生了重大变化？”，而您又没有量化答案，那么您就需要 KRI。本指南就是该答案的工作文档版本。它解释什么是关键风险指标、它与关键绩效指标 (KPI) 有何不同、为什么每一个现代合规框架都期望您具备这些指标，以及在第 1 天应为 ISO 27001、NIS2、DORA、NIST CSF 和 EU AI Act 具体设置哪些 KRI 作为起点。
无论您搜索的是“什么是 KRI”、“风险管理 KRI 示例”、“DORA KRI 指标”、“关键风险指标 ISO 27001”还是“KRI 与 KPI 对比”，这里都是您的统一参考。读完后，您将获得一套 14 项 KRI 入门包、每一项对应的监管引用，以及用于驱动可供董事会使用的红黄绿灯仪表板的阈值逻辑。
什么是关键风险指标？
关键风险指标是为预测或发现某一已定义风险的可能性、影响或变化速度而选择的量化指标。不同于衡量您是否达成目标的关键绩效指标 (KPI)，KRI 衡量的是您已经识别的风险是否正在变得更严重或更缓和。
KPI 与 KRI 的实务区别：
- KPI：按时发布的版本比例。回答的是“我们是否达到了交付目标？”
- KRI：部署后 7 天内触发安全事件的版本比例。回答的是“我们的变更管理流程是否正在削弱风险态势？”
同一个分子既可以作为 KPI，也可以作为 KRI，取决于您是在管理绩效，还是在监控风险。
一个好的 KRI 具备六个属性：
- 量化。计数、百分比、天数、货币金额。不是“高 / 中 / 低”，那是登记册中的内容。
- 具有预测性或同步性，而非滞后。“上一季度的泄露次数”是滞后的 KPI。“开放超过 30 天的高严重性漏洞数量”是前瞻性的 KRI。
- 绑定到登记册中的特定风险。没有锚定的指标只是虚荣数字。
- 方向明确。数值越低越好（例如开放的关键事件数量）或数值越高越好（例如 MFA 覆盖率）。阈值逻辑取决于这一点。
- 受阈值约束。数值落入的绿 / 黄 / 红区间。没有阈值，您拥有的只是数据，而不是信号。
- 有负责人。指定承担责任的角色（CISO、CRO、DPO、合规负责人）。
为什么每个现代合规框架都要求 KRI
“KRI”这个词并不总是写入法规，但相关义务确实存在。监管机构希望看到证据，证明您正在持续监测风险水平，并且当风险偏离容忍范围时，有相应的升级机制。带有阈值的量化指标，是通用的答案。
| 框架 | 条款 | 要求内容 |
|---|---|---|
| DORA (EU 2022/2554) | 第 6 条，第 16 条 | ICT 风险管理框架，包含有文档记录的战略、策略、程序和协议，包括对所有 ICT 风险的持续识别、评估和监测。第 29 条还增加了实体层面的 ICT 集中度风险监测。 |
| NIS2 (EU 2022/2555) | Art. 21(2)(f) | “用于评估网络安全风险管理措施有效性的策略和程序。”评估有效性的唯一可信方式，就是对其进行衡量。 |
| ISO 27001:2022 | 第 6.1.3 条，第 9.1 条 | 风险处置计划，并监测其有效性。第 9.1 条明确要求组织确定需要监测和测量什么、何时监测和测量，以及由谁执行。 |
| NIST CSF 2.0 | GV.RM-02, ID.IM-03 | 风险偏好和容忍度声明包含标准和度量。持续监测为改进提供依据。 |
| EU AI Act (EU 2024/1689) | 第 9 条，第 72 条 | 贯穿 AI 系统生命周期的风险管理体系。第 72 条引入了对高风险 AI 系统的上市后监测，并使用关于性能和事件的指标。 |
用直白的话说：过去五年出现的每一种监管制度，都逐渐汇聚到同一种监管预期：展示您的指标，展示您的阈值，展示趋势。KRI 正是对这三点的回答。关于上表需要提醒一点，因为它略微美化了监管机构。这些工具中没有一个会告诉您应该衡量什么，而这个空白需要您用自己的判断来填补。好处是，没有审计师能够因为您的 KRI 集合“选错了”而否定它。他们只能因为它没有锚点、没有测量，或者在变红时被忽视而否定它，而这正是薄弱 KRI 计划的真实样子。
每位风险经理都应在 2026 年跟踪的 14 个 KRI
下面是一套按风险领域分组的可用入门包。每一项都包括方向、示例阈值区间，以及该 KRI 有助于提供证据的框架条款。在复制清单之前，先说明一下投入。大约一半指标可以直接从您已运行的系统中读取，启用它们只是配置工作，一周内即可完成。第三方这一组成本最高，因为供应商支出集中度和单一服务提供商依赖都需要底层有一份干净的供应商清单，而建立这份清单才是真正的项目。如果您的供应商数据混乱，请从那里开始，并在修复之前将这些指标保持为琥珀色。
关于下面的阈值。绿色/琥珀色/红色区间，是我们为典型中端市场金融服务或 B2B SaaS 组织选择的示例性初始默认值。它们不是监管要求，也不是行业基准。请根据您声明的风险偏好设定自己的阈值；这里的数字只是起点。
监管与合规
1. 超过审核日期的策略占比
方向：越低越好 · 绿色：≤ 5% · 琥珀色：≤ 15% · 红色：> 15% · 频率：每月
映射至：ISO 27001 A.5.1, A.5.5 · DORA Art. 9 · NIS2 Art. 21(2)(a)
2. 超过 30 天未确认的监管动态
方向：越低越好 · 绿色：0 · 琥珀色：≤ 3 · 红色：> 3 · 频率：每周
映射至：ISO 27001 4.2 · DORA Art. 13
运营
3. 超出容忍度的关键风险
方向：越低越好 · 绿色：0 · 琥珀色：≤ 2 · 红色：> 2 · 频率：每月
映射至：DORA Art. 6, Art. 16 · ISO 27001 6.1.2, 6.1.3 · NIS2 Art. 21(2)(a)
4. 审查逾期的风险
方向：越低越好 · 绿色：≤ 2 · 琥珀色：≤ 10 · 红色：> 10 · 频率：每月
映射至：ISO 27001 6.1.3, 9.1 · DORA Art. 6
5. 平均控制措施有效性
方向：越高越好 · 绿色：≥ 85% · 琥珀色：≥ 70% · 红色：< 70% · 频率：每季度
映射至：ISO 27001 6.1.3, 8.1 · DORA Art. 9
网络与 ICT
6. 未关闭的重大事件
方向：越低越好 · 绿色：0 · 琥珀色：≤ 2 · 红色：> 2 · 频率：每日
映射至：DORA Art. 17, Art. 19 · NIS2 Art. 23 · ISO 27001 A.5.24
7. 未满足监管机构截止期限的事件（过去 90 天）
方向：越低越好 · 绿色：0 · 琥珀色：≤ 1 · 红色：> 1 · 频率：每月
映射至：DORA Art. 19（初始 4h，中间 72h，最终 1 个月）· NIS2 Art. 23（24h/72h/1 个月）· GDPR Art. 33（72h）
8. 超过 30 天未关闭的漏洞（高 / 严重）
方向：越低越好 · 绿色：≤ 5 · 琥珀色：≤ 20 · 红色：> 20 · 频率：每周
映射至：ISO 27001 A.8.8 · DORA Art. 9 · NIS2 Art. 21(2)(e)
9. 平均补救时间（MTTR）：关键风险
方向：越低越好 · 绿色：≤ 45 d · 琥珀色：≤ 90 d · 红色：> 90 d · 频率：每季度
映射至：ISO 27001 8.1, 10.1 · DORA Art. 6, Art. 9
第三方
10. 逾期评估的关键供应商占比
方向：越低越好 · 绿色：≤ 5% · 琥珀色：≤ 15% · 红色：> 15% · 频率：每月
映射到：DORA Art. 28, Art. 29 · ISO 27001 A.5.19, A.5.20 · NIS2 Art. 21(2)(d)
11. 供应商支出赫芬达尔-赫希曼指数 (HHI)
方向：越低越好 · 绿色：< 1,500 · 琥珀色：< 2,500 · 红色：≥ 2,500 · 频率：每季度
映射到：DORA Art. 29（实体层面的 ICT 集中度风险）
1,500 / 2,500 区间是借鉴 US DOJ/FTC 2010 Horizontal Merger Guidelines 的示例性默认值。DORA Art. 29 要求您评估集中度风险，但并未规定具体的 HHI 数值。
12. 依赖单一服务提供商的关键职能
方向：越低越好 · 绿色：≤ 1 · 琥珀色：≤ 3 · 红色：> 3 · 频率：每季度
映射到：DORA Art. 29
人员与意识
13. 完成年度安全培训的员工占比
方向：越高越好 · 绿色：≥ 95% · 琥珀色：≥ 80% · 红色：< 80% · 频率：每季度
映射到：NIS2 Art. 21(2)(g) · ISO 27001 A.6.3 · DORA Art. 13
14. 钓鱼模拟点击率
方向：越低越好 · 绿色：≤ 10% · 琥珀色：≤ 20% · 红色：> 20% · 频率：每季度
映射到：ISO 27001 A.6.3 · NIS2 Art. 21(2)(g)
请把它视为清单中最弱的指标。点击率会随模拟编写难度而变化，因此它衡量您的模拟供应商的程度，几乎不亚于衡量您的员工。它仍保留在清单中，是因为报告率和报告用时可以从同一次演练中免费获得，而这两项才是真正预测真实攻击活动能否被及早发现的指标。
如何真正运行 KRI 计划：五个实用步骤
让 KRI 失败最快的方式，是设计一套漂亮的目录，然后从不收集任何测量值。让 KRI 成功最快的方式，是尽可能将更多 KRI 接入您的平台已有的系统数据，然后为每一个剩余的手工 KRI 指定一名人工负责人，让其在同一个页面上每月录入一次数字。第二快的失败方式，是在数字已经不再说明任何问题后仍持续收集。一个自创建之日起每个月都是绿色的指标，要么是在监控一个您并不存在的风险，要么是以一种不会变化的方式在监控它。停用它，并记录停用原因。一份有人会阅读的简短清单，胜过一份所有人都会划过的冗长清单。
- 将每个 KRI 锚定到一项风险和一项法规。“未关联”的 KRI 会变成无人更新的孤项。标记该指标所满足的框架条款或控制措施，当监管机构询问您为何跟踪它时，答案就在屏幕上。
- 先设定阈值，再开始衡量。否则，第一次读数就会成为新的“正常值”，您也会失去客观性。凡是存在可辩护的外部参考，就将其作为起始默认值，并明确标注。1,500 / 2,500 HHI 集中度区间来自 US DOJ/FTC 2010 Horizontal Merger Guidelines，而不是 DORA（Art. 29 要求进行集中度风险评估，但未设定数字）；30 天补丁 SLA 是一种常见的内部 PCI DSS 风格惯例。预计这一步会涉及组织政治。您设定的每个区间，都是对组织愿意容忍什么的隐含表态，而拥有底层流程的经理会把红色阈值解读为对其团队的评价。应在一次会议中，将这些区间与风险偏好一并签署确认，并且在任何人看到与其姓名关联的实时数字之前完成。
- 尽可能自动化每个 KRI。如果数据存在于您的平台中（风险登记册、控制措施库、供应商清单、事件表、集成发现），就应当能够一键自动计算。自动化是默认方式，手动才是例外。
- 在显示今日数值的同时显示趋势。一个过去一个季度每月都在恶化的绿色 KRI，比一个刚刚转红的 KRI 更重要。迷你趋势线加上回归告警规则（连续三次测量朝不利方向移动）可以同时捕捉这两类情况。
- 将突破阈值与升级联动。当 KRI 越过红色阈值时，必须自动触发某种动作，至少应向具名负责人发送通知。对于受监管实体，突破还应启动法定时钟（DORA Art. 19：在将事件归类为重大事件后 4 小时内提交初始通知；NIS2 Art. 23：24 小时早期预警）。没有升级机制的 KRI 只是装饰。
Venvera 如何实现 KRI
Venvera 在标准风险管理工作区中提供 KRI 模块。系统预置了包含 22 个 KRI 的目录，覆盖 9 个企业风险领域，每个 KRI 都锚定到具体的 DORA、NIS2、ISO 27001 和 NIST CSF 条款或控制措施。其中 14 个可从风险登记册、控制措施库、事件表和 TPRM 供应商数据自动计算，无需手动收集。其余 8 个为手动项：由具名负责人在单一页面记录数值并补充背景信息。
在静态 KRI 清单之上，Venvera 叠加了以下能力：
- 与监管时钟联动的突破阈值处理。可在任意 KRI 上开启“突破阈值时自动创建监管事件”；当其越过红色阈值时，Venvera 会按照正确的法定时钟创建事件（DORA Art. 19：4h 初始、72h 中期、1-month 最终；或 NIS2 Art. 23：24h、72h、1 month），通知相应人员，并且事件时钟工作程序每 5 分钟重新检查截止日期。
- 基于快照的回归告警。仪表板会显示过去 3 次快照中轨迹持续恶化的 KRI，即使当前状态仍为绿色。这正是监管机构期望您监控的早期预警信号。
- 复合领域健康分数。10 个企业风险领域各自获得 0-100 的健康分数，并按监管锚定进行加权（标记到更多条款的 KRI 权重更高）。可直接呈现在董事会材料中。
- 控制措施失效传播。可将任意 KRI 关联到对其有效性有重大影响的控制措施。当某项控制措施失效时，KRI 会在下一次测量记录之前即被标记为存在风险。
- 董事会材料 PDF 导出。一键生成可提交董事会的 PDF，整合整体健康状况、各领域复合指标、回归告警、带时钟状态的未关闭突破事项，以及按框架划分的监管就绪度分数，并锚定到条款级引用。
在您的组织中试用
打开 风险管理 → KRI，点击 Seed catalogue。不到一秒钟，带有完整框架锚定的 22 个 KRI 就会出现。点击 Auto-compute，仪表板将根据您的实时数据填充。
关于关键风险指标的常见问题
KRI 和 KPI 有什么区别？
KPI 衡量您是否正在实现绩效目标。KRI 衡量您已识别的风险是在上升还是下降。同一个原始数字既可以作为 KPI，也可以作为 KRI，关键在于如何界定。“部署时间”是 KPI；“披露后修补关键漏洞所需时间”是 KRI。因此，阈值逻辑和责任链也不同。
一个组织应跟踪多少个 KRI？
对于遵循 ISO 27001、欧盟 NIS2 指令、欧盟《数字运营韧性法案》（DORA）及相关制度运营的中型金融服务、B2B SaaS 和医疗健康实体，15-30 个活跃 KRI 是一个健康区间。少于 15 个，您几乎必然会遗漏关键信号；超过 40 个，每月收集的成本就开始超过边际洞察价值。Venvera 的种子目录为 22 个，大多数受监管的中型实体只需少量调整即可运行。
小型组织需要 KRI 才能符合 NIS2 或 DORA 吗？
NIS2 Art. 21(2)(f) 要求制定“用于评估网络安全风险管理措施有效性的策略和程序”。没有量化指标，评估就会变得主观，并且在主管机关检查中无法自证。DORA 更为明确：Art. 6 要求建立有文件记录的框架，并对所有 ICT 风险进行持续监测。小型实体可以使用更少的 KRI，但拥有 KRI 的义务并不取决于规模。
KRI 与风险偏好是什么关系？
风险偏好是组织愿意接受的风险水平的定性表述。KRI 是用于告诉董事会组织是否在风险偏好范围内运行的量化工具。KRI 阈值（绿色/琥珀色边界）是风险偏好的运营化表达。当某个 KRI 进入红色，说明组织正在其声明的风险偏好之外运行，需要升级处理。
KRI 应该向董事会报告吗？
是的，而且多数现代董事会材料都会包含一页式 KRI 仪表板，显示绿/琥珀/红状态、展示趋势的迷你折线图，并标记期间发生的任何 KRI 违限。DORA Art. 5 尤其要求管理机构对 ICT 风险管理框架承担个人问责，包括监测。KRI 仪表板是董事会正在履行该监督职责的主要证据。
哪里可以找到可供调整的 KRI 模板？
Venvera 随附一个包含 22 个 KRI 的参考目录，覆盖 ISO 27001、NIS2、DORA、NIST CSF 和欧盟《人工智能法案》（EU AI Act），您可以一键将其种子导入任何组织。文档见此处。如果您更愿意自行构建，本文中的 14 个 KRI 入门包可为您提供一个可自证的基础，并按您自己的风险偏好进行调整。
主要来源
本指南中的每一处监管引用都可追溯至主要来源。条款编号指向相应义务；KRI 阈值是我们自定义的示例性默认值，并非要求。
- DORA - Regulation (EU) 2022/2554：Art. 5（治理）、6/16（ICT 风险管理框架）、9（保护与预防）、13（学习与培训）、17（事件管理）、19（重大事件报告）、28/29（ICT 第三方和实体层面的集中度风险）。EUR-Lex。
- DORA 事件截止期限 - Commission Delegated Regulation (EU) 2025/301 规定了报告时限：在将事件分类为重大事件后 4 小时内提交初始通知（最迟不得超过知悉后 24 小时），72 小时内提交中期报告，一个月内提交最终报告。EUR-Lex。
- NIS2 - Directive (EU) 2022/2555：Art. 21(2)（风险管理措施，包括关于评估有效性的第 (f) 点）、Art. 23（24 小时早期预警、72 小时通知、1 个月最终报告）。EUR-Lex。
- ISO/IEC 27001:2022 - 第 6.1.3 条和第 9.1 条，以及所引用的 Annex A 控制措施。标准文本可从 iso.org 获取。
- NIST CSF 2.0 - GV.RM-02（风险偏好与容忍度）和 ID.IM-03（持续监测为改进提供信息）。nist.gov。
- GDPR - Regulation (EU) 2016/679，Art. 33：泄露通知“不得晚于 72 小时”。EUR-Lex。
- EU AI Act - Regulation (EU) 2024/1689，Art. 9（风险管理体系）和 Art. 72（高风险 AI 系统的上市后监测）。EUR-Lex。
- HHI 集中度区间（1,500 / 2,500） - US Department of Justice 和 Federal Trade Commission，《Horizontal Merger Guidelines》（2010）。此处仅作为示例性默认值使用。
准备好从电子表格转向体系化方案了吗？
启动一个 Venvera 组织，种子导入 20 个 KRI 目录，并运行自动计算。不到五分钟，您就能获得一个可提交董事会的仪表板，并且已附上相关监管引用。开始免费试用 →
