经得起审计的适用性声明编写方法

ISO/IEC 27001第6.1.3(d)条要求提供适用性声明：一份列明所需控制措施、纳入理由、实施状态，以及附录A中93项控制措施中任何被排除项的排除理由的文件。它听起来像是行政性工作，但实际上它是风险评估与控制措施之间的桥梁，认证审核员会仔细审读，因为适用性声明薄弱通常意味着背后的风险管理流程也薄弱。

必须包含的内容

对于附录A中的每一项控制措施，以及您自行增加的任何控制措施：

1. 是否适用。
2. 纳入理由：通常是其所应对的风险、法律或合同要求，或业务决策。
3. 实施状态：已实施、部分实施或计划中。
4. 排除理由（如被排除）。

大多数适用性声明还会简要说明每项控制措施的实施方式，并引用相应的政策或程序。这并非严格要求，但能大幅加快审计进程。

纳入理由的论证

将每项控制措施与具体事项相联系：风险登记册中的某项风险、法律要求（GDPR第32条、NIS2、行业监管规定）、合同或客户要求。“最佳实践”是较弱的理由；“应对风险R-12和R-17，并满足我们的NIS2义务要求”则是有力的理由。将控制措施与法律要求相联系，在您需要应对多个框架时也很有帮助：我们的要求页面会显示附录A的每项控制措施对应哪些其他框架，例如A.8.24 密码学的使用。

排除理由的论证

允许排除控制措施，但每项排除都需要审核员可以检验的理由。合理的理由包括：

• 相关活动不在范围内发生。无外包开发：排除A.8.30。
• 相关风险在范围内不存在。完全远程办公、没有办公场所的组织可以排除部分A.7物理控制措施，但对于无论位于何处的设备和介质相关的控制措施则不应排除。

较弱的理由包括：“不相关”、“由IT部门处理”、“云服务商负责”。如果供应商执行某项控制措施，该控制措施仍然适用；您应通过供应商控制措施对其进行管理。

常见审计发现

• 适用性声明与风险处置计划不一致。风险处置中选定的控制措施必须出现在适用性声明中，反之亦然。
• 已实施的控制措施缺乏证据。将某项控制措施标记为已实施，会引来对证明材料的要求。
• 套用模板的语言。从模板复制的描述与实际做法不符。
• 版本过时。适用性声明仍沿用2013版附录A的编号，或在重大变更后未更新。

实用结构

每项控制措施一行：编号和名称、是否适用（是/否）、理由（风险、法律和合同要求）、状态、一行式的实施方式说明、责任人，以及证据引用。将其保存在电子表格或您的GRC工具中并纳入文档控制，并在每次风险评估时进行审查。

保持适用性声明的有效性

为首次认证编写、此后从未更新的适用性声明，会在下一次审计中成为审计发现。请在以下情况下及时更新：

• 风险评估改变了所选控制措施；
• 范围发生变化（新产品、新办公室或新的云服务商）；
• 某项控制措施的实施状态发生变化；
• 出现新的法律或合同要求（例如NIS2或客户合同）。

每次更新都应记录版本、日期和批准人。

核心要点

• 附录A的每项控制措施都需要一个决定和一个理由，包括排除项。
• 将纳入项与具体风险以及法律或合同要求相关联。
• 保持适用性声明与风险处置计划一致，并保持其现行有效。

同时应对多个框架

如果您还需要应对SOC 2、NIS2或PCI DSS，请为每个框架增加一列对应要求。适用性声明便可成为通用控制集的骨架；我们关于SOC 2与ISO 27001共用一套控制集的文章介绍了该方法，而差距分析则列出了附录A的每项控制措施与任何其他框架的对照关系。ISO 27001指南涵盖认证的其余内容。

常见问题

ISO 27001中可以排除附录A的控制措施吗？

可以，前提是排除有充分理由，通常是因为风险在您的范围内不存在（例如您不外包开发时排除外包开发相关控制）。排除项必须在适用性声明中说明理由。

适用性声明必须包含哪些内容？

ISO 27001第6.1.3(d)条要求提供必要的控制措施、纳入这些措施的理由、它们是否已实施，以及排除任何附录A控制措施的理由。

适用性声明会与客户共享吗？

通常不会全文共享；它是由认证机构审阅的内部文件。部分组织会在保密协议下与客户共享摘要，以说明适用哪些控制措施。