框架疲劳：选定一个枢纽框架，并将其他所有框架映射到它

问问任何一家成长型企业的合规负责人，他们的一年是什么样子，你会听到一长串清单：SOC 2 观察期、ISO 监督审核、新法规、PCI 评估，以及源源不断的客户问卷，每份都有自己的编号体系和术语。团队之所以精疲力竭，并不是因为某一个框架不合理，而是因为他们在同时运行好几个项目，而这些项目基本都在要求同样的东西。

结构性解决方案

选定一个枢纽。以你自己的语言定义你的控制措施，只需定义一次，并围绕该枢纽进行组织。然后将每个外部框架映射到它。新框架不再是一个新项目，而只是一次映射工作，外加少数真正新增的要求。

这正是 ControlMapping 自身的构建方式：NIST CSF 2.0 为枢纽，每个主题都以 CSF 成果进行定义，其余十个框架则映射到这些主题上。之所以可行，是因为 CSF 覆盖面广、结构稳定，并且 NIST 等机构已将其映射到几乎所有框架。

选择你的枢纽

• NIST CSF 2.0：如果你需要一个中立的、以成果为导向的结构，便于高管理解，并且已有指向 SP 800-53、ISO 27001 等众多框架的官方映射。
• ISO 27001：如果你无论如何都要按它认证，那么附录 A 加上你的适用性声明即可成为控制措施的主干。
• SP 800-53：如果你运营联邦系统；它最为全面，且能映射到大多数其他框架，正如我们的起点分析所衡量的结果。

避免把狭窄或规定性较强的框架作为枢纽：Essential Eight 或 PCI DSS 都是优秀的标准，但它们对其他框架的覆盖不足，无法用来组织整个项目。

拥有枢纽后会发生什么变化

• 新框架成本更低。从你的枢纽向新框架运行差距分析；大多数要求都能映射上，只有剩余部分才是新工作。
• 证据只收集一次，并标记到它所服务的每个框架。
• 问卷回复更快：从你的控制措施集中作答，并引用已映射的要求。
• 董事会报告保持一致，统一使用同一套术语，无论审计日程如何安排。

例如，以 NIST CSF 2.0 为枢纽时：

方向	已映射	弱相关	无映射
已有 NIST CSF 2.0 → 需要 NIS2	45 / 49 (92%)	3	1	报告 →
已有 NIS2 → 需要 NIST CSF 2.0	85 / 106 (80%)	12	9	报告 →

如何搭建

1. 以你自己的语言编写控制措施，每项对应贵组织做出的一项决策：谁负责、做什么、多久一次、需要什么证据。
2. 将每项控制措施映射到枢纽（例如其 CSF 2.0 子类别），然后再映射到你所对应的每个框架。
3. 将映射集中保存在一处，并注明每条链接的来源，以便核查和更新。
4. 按控制措施而非按框架指定负责人。
5. 任一框架变化时审查映射，而不是重建整个项目。

投入主要集中在前期：第一次映射需要实实在在的工作，但之后每个新框架和问卷都可以复用它。我们的下载资源中包含一份现成的、映射到 CSF 2.0 枢纽的映射表，可作为起点。

核心要点

• 框架疲劳源于为每个框架单独运行一个项目。
• 选择一个覆盖面广、映射完善的枢纽（NIST CSF 2.0、ISO 27001 或 SP 800-53），并将其他所有框架映射到它。
• 此后，新框架只需一次差距分析，外加真正新增的要求。

它无法解决的问题

枢纽并不能消除特定框架的要求：报告截止日期、特定频率、法律义务。它的作用只是让这些要求作为例外情况清晰可见，而不是埋没在重复工作之中。

框架疲劳是设计问题。修正设计，大部分疲劳也会随之消失。可以从覆盖矩阵开始，它一目了然地展示了一个枢纽与全部十一个框架的对应关系。

常见问题

哪个框架最适合作为枢纽？

应选择覆盖面广、结构稳定且映射完善的框架。NIST CSF 2.0 是很好的选择，因为 NIST 等机构已发布了指向它的映射；如果组织无论如何都要按 ISO 27001 认证，那么它也很适合。

什么是通用控制框架？

一套内部控制措施，每项都映射到组织所对应的每个外部框架中它所满足的要求。

GRC 工具能否充当枢纽？

GRC 工具可以承载枢纽和映射，但枢纽本身是一项设计选择：即你的控制措施所围绕的结构。应先选定它，再配置工具。