ISO 27001适用性声明常见错误

理解适用性声明的目标

首先，有必要了解为何需要适用性声明。这不是为了走形式的文书工作，而是一份关键文件，构成了审计人员在检查合规性时将审查的基础。

ISO 27001 附件A概述了93项被认为对企业安全至关重要的安全控制措施。从资产管理、事件响应等组织控制，到数据中心安全等物理控制，再到多因素认证和数据备份等技术控制，信息安全的每个要素都经过考量并浓缩在此列表中。

然而，没有一种完美的框架适合所有人。如果你的企业没有实体办公地点，如何遵守办公室或数据中心的物理安全控制？如果你的企业不处理公司技术资产，如何进行资产管理？

适用性声明是你为企业创建的指南。它评估你所使用的系统和流程带来的风险、适用的安全控制措施，以及这些控制措施如何实施以应对这些风险。从某种意义上说，它就像是你的整体信息安全管理体系的概要。

适用性声明有多种用途：

它识别某项控制何时适用于你的业务，以及你如何理解该控制所要应对的风险。
它识别不适用于你业务的各项控制，并包含排除该控制的理由。
它记录每项控制的持续实施状态。
当你的业务发生变化时，它可作为指南，说明风险如何变化以及需要调整哪些控制措施。

最常见的失败点之一就发生在这里：当企业不了解适用性声明的深度和效用，只提供部分信息时。

适用性声明包含的内容

适用性声明是一份综合性文件，包含大量信息。它也可以是可变的；一份最低限度的SoA与一份完整且健全的SoA可能大不相同。

通常，拥有一份更全面的SoA会对你更有益。仅满足最低要求的企业往往发现，随着业务增长和变化，他们需要重复大量工作，而那些在一开始就投入工作的企业则发现更容易维护这份“活文件”的更新。

最低限度的适用性声明必须包括：

ISO 27001 附件A中93项控制措施的逐项列示，无论你是否认为它们适用于你的业务。请注意，第4-10节中的核心强制性控制不属于SoA的一部分。
说明该控制措施是否适用于你的业务并已实施。
如果上述答案为“是”，则需评估该控制为何必要。
如果上述答案为“否”，则需提供该控制不适用的理由。

一份更健全、更有用的适用性声明还应包括：

控制的负责人，即负责监督该控制的角色或具体人员。
对该控制应对的风险及其方式的评估。
某项控制计划实施但尚未完成的情况。
与实施和更新控制相关的日期。
实施和证据的参考文档。

考虑到审计员将在其初始步骤中查看此文档，并会分析你是否为所有声明提供了充分的理由。许多ISO 27001审核在这里就失败了，甚至在实际实施评估开始之前。

ISO 27001适用性声明中的常见错误

现在让我们深入探讨适用性声明中常见的错误。虽然其中一些可能是次要的，不会中止审计过程，但许多错误可能导致审核失败，并耗费时间和金钱来修复。因此，最好在审计员指出它们之前解决，这就是我们编写本指南的原因。

1. 未能包含所有控制项

适用性声明未能通过审核的最常见原因之一是它不完整。总的来说，我们看到这种情况发生有三个原因。其中两个源于对适用性声明目的的错误理解，而第三个更像是文书错误。

你只包含了适用的控制项，而遗漏了不适用的。这忽略了审计人员需要看到你为何有理由排除某项控制的事实。
你只包含了不适用的控制项，而遗漏了你已实施的控制。很容易认为其他ISMS文件（如你的风险评估）涵盖了这些内容，但SoA仍然至关重要。
你遗漏了看似随机的控制项。在极少数情况下，创建初始文档的人可能会意外跳过或忽略某个单一控制项，未将其包含在文档中。虽然这很容易修复，但它确实表明你的流程存在缺陷，导致本应验证数据的利益相关者持续忽略了它。

所有这些原因都可能导致你的适用性声明被拒绝，这可能使整个审计暂停，直到你完成该文件。将适用性声明视为ISMS内其他文档和成果的“操作目录”或“索引”会有所帮助。如果SoA中的内容不完整，则表明你其余的实施也存在更深层次的问题。

2. 排除控制的理由无效

适用性声明未能通过审查的一个最常见原因是，你认定某项控制不相关，但你的理由不成立。显然，某些理由是根本行不通的。时不时会有公司试图以实施过程太耗时或成本太高为由放弃某项控制。对此，审计员会说：无论如何都要做。如果成本太高，也许ISO 27001并不适合你。另一方面，有效的理由需要深思熟虑。有效理由的例子可能包括：

某项控制所要应对的风险，你已通过其他方式缓解了。现有的缓解措施必须等同或更好地应对该风险，并且必须是你主动采取的。
附件A要求你实施的控制，如果按照标准执行，在你的情况下将无效。你需要具体的证据和经验数据来支持这一说法。
法律要求或例外情况意味着某项控制不适用于你的业务。这种情况非常罕见，但偶尔会出现在边缘案例中。

许多用于排除控制的理由最终都经不起推敲。这是一个非常高的门槛，因此请确保你对你希望排除的任何控制都有极其充分的理由，并做好准备以防万一，即使那样可能还不够。

3. 对控制适用性的评估过于狭隘

与理由相对的另一方面是解释。对于你知道适用并且正在实施的控制，你需要评估它们适用于你业务的哪些部分以及如何适用。这是整个安全和风险评估及范围界定的一部分。当你界定一项控制的应用范围时，有可能过于狭隘。如果是这样，则可能表明你没有全面考虑整个场景，并在该安全控制的实施中留下了缺口。这是实施ISO 27001最棘手的部分之一，使其也成为SoA的常见失败点之一。这也是为什么风险评估如此重要；它需要尽可能全面。范围界定帮助你缩小一项控制整体适用性的广度，这是减少控制需要覆盖范围的合理方式。仅仅缩小控制的理由则会让你在防御体系中留下漏洞。

4. 未能包含控制实施的参考和证据

从技术上讲，适用性声明不需要包含一个专门列出实施参考和证据的部分。然而，大多数审计员会希望看到这一部分，或者一份汇集了所有相同信息的辅助文档（在这种情况下，只需将其添加到SoA中）。再次强调，SoA经常充当引用根据附件A规则实施的安全工作的索引或目录。可以添加到适用性声明中的有用信息越多，审计员需要寻找它的工作量就越少，跟踪所有这些信息的可靠性也就越高。

5. SoA与其他ISMS文件之间存在严重脱节

尽管适用性声明是一份核心参考文件，但它也需要成为整体实施包的一部分。如果你进行了整体风险评估并记录了它（这是实施ISO 27001所必需的），那么用于证明和实施附件A控制措施的风险应该是一致的。如果这些文件之间存在严重脱节，就很难确定哪一个是规范信息，哪一个是过时或不正确的。这也与下一个原因相关联。

6. 未能保持适用性声明的更新

你的整体ISMS以及作为其一部分的文件不是静态的。它们不是申请过程中一次性的工作。它们是反映你安全实施状态的活文件。这意味着它们需要随着你的进展而不断更新。当你进行内部审计或接受外部再认证审计时，这些文件需要是最新的。保留版本历史也很有帮助，可以进一步证明你不是仅仅为了审计而用新数据重做它们，而是一直在保持更新。有些控制不会频繁变化，或根本不变。其他控制的变化则更频繁，因为它们所处的法律、监管或安全环境发生了变化。你还需要确保你使用的是ISO 27001:2022框架，而不是旧的27001:2013，后者有更多控制项且不够简化。到目前为止，每个人都应该已经更新了，但如果你是少数尚未更新的，现在是时候适应了。

简化ISO 27001适用性声明的编制过程

ISO 27001适用性声明中的许多信息至少可以部分自动化。你也可以使用像Ignyte Assurance Platform这样的平台来跟踪和维护文档、成果和证据，这些可以作为你的SoA实施记录中引用的来源。我们设计的Ignyte Assurance Platform是框架无关的，因此它适用于NIST框架、ISO框架以及其他如SOC和HIPAA等框架。它帮助你跟踪实施情况，记录你的ISMS，并将所有相关文档集中存储在一个地方，无论负责这些工作的团队分布多么广泛或分散。要了解我们的平台如何帮助你，请预约电话并预订演示以查看实际操作。除了平台，我们还可以利用对ISO 27001的深入了解为你提供帮助，并帮助你确保第一次审核就能通过。