供应商无法核验的对照映射问题

合规自动化平台让多框架项目的运行变得轻松许多。大多数平台都主打一个核心承诺：实施一项控制一次，即可满足 SOC 2、ISO 27001、NIST、HIPAA 等多项要求，因为平台的对照映射是这么说的。若询问平台某条具体映射的来源、对应的是哪个版本，以及两项要求为何等效，得到的答复往往是沉默。

这是一个问题，而且不是吹毛求疵的问题。

无法核验的映射会把风险转嫁给你

当平台告诉你，你的访问控制满足你刚纳入适用范围的某个框架中的某项要求，而结论有误时，审计发现由你承担，而非供应商。你依赖的是一条无法核查的映射。审计人员不接受“工具是这样映射的”作为理由；他们会阅读要求原文，并测试你的控制是否满足该要求。

映射会悄无声息地过时

框架会变化。CSF 2.0 撤销了 79 个 CSF 1.1 子类别（去向说明）；ISO 27001:2022 重新编排了附录 A；PCI DSS v4.0 新增了数十项要求。未标注版本、也未对照现行条目目录验证的对照映射会逐渐失效。没有标注的对照映射，失效过程悄无声息。

“已映射”掩盖了映射的类型

两项要求之间的一条连线，可能意味着二者等效，也可能意味着其中一项是另一项的子集，或仅仅是二者涉及同一主题。我们自己对映射有多少依托于公开证据所作的分析发现，各类映射中有很大一部分属于判断性映射，而非公开发布的对照映射：

框架	映射关系	对照映射	编辑说明	对照覆盖占比
NIS2	65	64	1	98%
ISO 27001	105	99	6	94%
800-53	120	106	14	88%
CMMC	72	60	12	83%
HIPAA	47	36	11	77%
PCI DSS	95	70	25	74%
CIS v8.1	163	40	123	25%
SOC 2	66	0	66	0%
GDPR	34	0	34	0%
Essential Eight	62	0	62	0%
全部	829	475	354	57%

判断性映射本身并无问题，问题在于未加标注的判断性映射。

对任何对照映射都应提出的要求

1. 每条连线的来源：官方对照映射（NIST、ENISA、框架所有方），或供应商的判断。
2. 每项判断性映射都附有理由，并且对你可见。
3. 两个框架的版本，以及最近一次验证的日期。
4. “已映射”的含义：等效、部分对应或相关。
5. 导出功能：能够导出映射结果，以便自行核查。

如果供应商无法提供上述内容，请把其映射当作参考线索，而非确定答案。

如何测试你拿到的对照映射

你无需审核整份对照映射即可判断其质量。抽样检查即可：

1. 从你最熟悉的框架中随机选取十条连线。
2. 逐条阅读两端的要求原文。
3. 对每条连线分类：等效、部分重叠、仅相关，或错误。
4. 检查两个对版本敏感的案例，例如某个 CSF 1.1 标识符或某个 ISO 27001:2013 控制编号。

如果大多数连线经得起检验，且版本均为现行版本，则该对照映射大体可作为参考指南。如果多条连线有误或已过时，应将整份对照映射视为未经验证。我们自己的数据同样可以接受这一测试：每个要求页面（例如 ISO 27001 A.8.8）都显示了各条连线的依据和理由。

要点总结

• 无法核验的映射会把审计风险转嫁给你。
• 对每条连线，都应要求提供来源、版本、含义和理由。
• 在依赖任何对照映射之前，先进行抽样测试。

我们为何公开发布自己的数据

ControlMapping 的存在，部分正是为了解决这一问题。每条连线都标注为对照映射或编辑说明，每条编辑说明都附有理由，每个编号都会在每次构建时对照官方目录进行验证，整个数据集也可在开放许可下下载。这并非唯一的做法，但我们认为这是业界应当自我要求达到的标准。请参阅方法论和下载页面。

常见问题

合规平台的对照映射准确吗？

有些映射经过精心维护，有些则没有。若看不到每条映射的来源、版本和理由，你就无从分辨；而审计人员也不会接受“工具是这么说的”作为依据。

一份值得信赖的对照映射应当展示什么？

对每条连线，应展示：来源（官方对照映射或供应商的判断）、两个框架的版本、该连线的含义（等效还是仅相关），以及判断性映射的理由。

NIST OLIR 是什么？

NIST 的在线参考信息（Online Informative References）计划：一个收录 NIST 框架与其他标准之间对照映射的目录。第三方提交的内容只检查格式，不核验正确性。