将一套政策映射到多个框架，无需重写

一种常见情况：某公司为 ISO 27001 编写了一套政策，随后客户要求提供 SOC 2，有人又购买了第二套模板包，接着 PCI DSS 又带来了自己的要求。结果是三套内容重叠的政策，每套都已略显过时，且没有一套与员工的实际做法相符。政策不必针对特定框架编写，而应针对组织本身量身定制，并建立映射关系。

结构：三层

1. 一份信息安全政策：内容简明，经管理层批准，载明目标、范围、职责及承诺。ISO 27001 第 5.2 条和 PCI DSS 12.1.1 均要求具备此文件。
2. 主题政策（约十余份）：访问控制、可接受使用、资产管理、密码学、事件响应、业务连续性、供应商安全、安全开发、漏洞与补丁管理、日志与监控、物理安全、人力资源安全。
3. 其下的程序与标准，其中包含频率、配置和步骤等具体内容。这些内容变动更为频繁，不应每次都需要管理层签批。

将框架特定的细节放在程序中，而非政策中：“每六个月审查一次访问权限”应写入访问审查程序，PCI DSS 的频率要求可以放在那里，而不会让政策变得臃肿。

映射，而非重写

维护一份映射表：每个政策条款占一行，列出各框架中该条款所对应的要求。治理政策主题展示了各框架在顶层对治理的期望：

框架	治理政策	链接
NIST CSF 2.0	GV.PO-01GV.PO-02	主题定义
ISO 27001	A.5.1A.5.37Clause 5.2	对照映射
CIS v8.1	—	本站数据中无映射
SOC 2	CC5.3CC1.1	编辑说明
PCI DSS	12.1.112.1.2	对照映射
CMMC	—	本站数据中无映射
800-53	PM-1PL-1	对照映射
HIPAA	§164.316(a)§164.316(b)(2)(iii)	对照映射
GDPR	Art.24(2)	编辑说明
NIS2	1.1	对照映射
Essential Eight	—	本站数据中无映射

完整详情及每条关联的依据： 治理政策 跨框架对照 →

当新框架出现时，开展差距分析，并查看治理与政策相关的要求：大多数要求可以映射到您已有的政策上；其余的则需形成新的章节或程序。

各框架对书面文件的具体要求

• ISO 27001：信息安全政策（5.2）及按需制定的主题政策（A.5.1），并须予以传达和评审。
• SOC 2：制定明确预期的政策，并通过程序加以落实（CC5.3）。
• PCI DSS：针对其十二项要求中的每一项，须具备有文档记录、保持更新的政策和程序（x.1.1）以及已指定的角色（x.1.2），且至少每年评审一次。
• NIS2：关于网络和信息系统安全的政策，以及主题政策（《实施条例》第1点）。
• NIST CSF 2.0：政策已建立、已传达并得到执行（GV.PO）。

最小化政策集

对于大多数中小型组织而言，以下文件即可涵盖 ISO 27001、SOC 2、NIST CSF、PCI DSS 和 NIS2 的政策要求：

1. 信息安全政策（顶层，经管理层批准）
2. 可接受使用政策
3. 访问控制政策
4. 资产管理与数据分类政策
5. 密码学政策
6. 安全开发与变更管理政策
7. 漏洞与补丁管理政策
8. 日志与监控政策
9. 事件响应政策（含报告义务）
10. 业务连续性与备份政策
11. 供应商安全政策
12. 人力资源安全政策
13. 物理安全政策

共十三份文件，多数篇幅仅几页，每份均需指定负责人和评审日期。细节由程序承载，程序的变更也更为频繁。

要点总结

• 政策应针对组织本身量身定制并建立映射，而非针对特定框架。
• 频率和配置应写入程序。
• 十三份简明政策即可覆盖大多数框架。
• PCI DSS 要求其政策和程序至少每年评审一次。

保持政策有效

• 如实记录实际做法，而非模板中的内容。审计师会将政策与实际执行进行对照测试。
• 每年评审，并在发生重大变更后进行评审，且留存评审批准记录。
• 简明胜于完整：一份员工真正阅读的两页访问控制政策，胜过二十页无人问津的文件。

如需了解基于同一理念构建的完整通用控制集，请参阅SOC 2 与 ISO 27001 通用控制集。

常见问题

您需要多少份安全政策？

比多数模板建议的要少。一份顶层信息安全政策加上十余份主题政策（如访问、可接受使用、事件响应、供应商安全等），通常即可覆盖 ISO 27001、SOC 2、NIST 和 PCI DSS。

PCI DSS 是否要求特定政策？

是的。PCI DSS 的每项要求都首先要求针对相关领域具备有文档记录、保持更新的政策和程序（x.1.1），以及角色与职责（x.1.2）。