ISO 27001认证的适用性声明怎么写才能覆盖真实业务风险

ISO 27001认证的适用性声明怎么写才能覆盖真实业务风险

软件和互联网企业在准备 ISO 27001 认证时，适用性声明（Statement of Applicability，简称 SoA）几乎是最容易被审核员追问的文件。很多企业的 SoA 是从模板改出来的，控制项列得很全，但和自身的资产、风险、业务场景对不上。

审核员看 SoA，不是看篇幅，而是看它能不能解释清楚三件事：企业有哪些信息资产，面对什么风险，为什么选择这些控制措施、排除那些控制措施。

这篇按 ISO/IEC 27001:2022 的要求，说明 SoA 的编写顺序、常见漏洞和审核前怎么自查。同创云在做信息安全体系辅导时，通常会把 SoA 和风险处置计划放在一起评审，避免两份文件各说各话。

一、先说结论

一份能过审核的 SoA，必须是从风险评估长出来的，而不是从附录 A 抄出来的。

• 结论一：SoA 要覆盖附录 A 的全部控制项，每一项都要说明是否适用；不适用要给出理由，不能留空。
• 结论二：适用理由要能追溯到风险处置计划，写清楚对应哪个风险、采取什么措施、由谁负责。
• 结论三：SoA 是动态文件，资产、业务、威胁发生变化时要更新，版本和审批记录要留痕。
• 结论四：业务部门要参与确认，只有信息安全部门签字的 SoA，审核时很难证明已经落地。

二、审核关注的判断项

下面四类问题是 ISO 27001 审核中关于 SoA 的高频追问，企业可以逐项对照。

这四项里，完整性靠清单解决，风险对应靠方法解决，排除理由靠业务确认解决，落地证据则要靠平时运行。

三、SoA 的编写顺序

3.1 先从资产和风险评估开始

SoA 的第一层输入是资产清单和风险评估结果。企业要先把信息资产按业务过程梳理清楚，包括系统、数据、人员、场地、供应商和云服务。

资产清单不需要追求数量，但要覆盖关键业务。审核员常问的是：这套客户数据存在哪里、谁能访问、备份在哪里、供应商出了事谁负责。答不上来，SoA 里的控制措施就很难成立。

关于资产清单的颗粒度，可以参考站内《ISO27001认证的资产清单编制需要覆盖哪些信息类型》，先把资产和责任人对应起来。

3.2 按附录 A 四大主题逐项判断

ISO/IEC 27001:2022 的附录 A 共 93 项控制措施，分为组织、人员、物理和技术四个主题。SoA 要把 93 项全部列出，再逐项判断适用性。

适用项要写清楚控制目的和实现方式，排除项要写清楚为什么不适用。比如企业没有自建机房，物理环境相关控制可以说明由云服务商承担，同时保留对供应商的监督措施。

这里最容易犯的错误是“一刀切”。把云服务商的责任当成自己的免责理由，审核员通常会继续追问供应商评价、合同条款和监控记录。

3.3 和风险处置计划对齐

SoA 不是孤立文件，它要和风险处置计划、剩余风险接受记录对应。每一项适用控制，应该能找到它要处理的风险；每一个高风险项，也应该能找到对应的控制或接受决策。

审核时常见的追问是：这个高风险为什么只用了这么轻的控制？如果企业答不出风险评价准则和接受理由，就会被认为风险处置没有闭环。

建议在 SoA 里增加风险编号和处置措施编号两列，评审时按编号抽查，能很快发现断点。

3.4 业务确认、审批和版本管理

SoA 要由信息安全负责人编制，业务部门确认，管理层审批。只有信息安全部门闭门造车，落地的可能性很低。

版本管理要能看出每次变更的原因。资产上线、业务外包、系统上云、组织调整，都可能触发 SoA 更新。审核员会看版本记录和变更审批，判断文件是不是活的。

员工行为规范也是落地证据之一。站内《ISO27001认证对员工信息安全行为规范有哪些考核要点》可以作为培训和行为检查的补充。

四、常见误区

• 误区一：把 SoA 当成合规清单，只关心“有没有”，不关心“为什么”。审核更看重理由和证据。
• 误区二：排除项写“不适用”就结束。没有业务解释的排除，等于把问题留给审核员追问。
• 误区三：SoA 和风险处置计划分开维护。两份文件编号对不上，整改时很容易漏项。
• 误区四：一次编完就不再更新。业务变了、系统上云了，SoA 还是旧版本，现场自然对不上。

五、审核前的落地步骤

1. 第一步：核对资产清单、风险评估报告和风险处置计划，确认三份文件的版本和范围一致。
2. 第二步：按附录 A 四大主题建立 93 项控制清单，逐项填写适用性、理由、责任部门和证据位置。
3. 第三步：抽取高风险项，反向检查 SoA 是否有对应控制，现场是否能找到执行记录。
4. 第四步：组织业务部门评审排除项和云服务相关控制，确认责任边界写清楚。
5. 第五步：完成审批和版本记录，并把 SoA 纳入下一次管理评审的输入。

六、常见问题

Q1：SoA 必须列全 93 项控制吗？

按 ISO/IEC 27001:2022 的要求，SoA 应覆盖附录 A 的全部控制项，并说明每项是否适用及理由。不能只列适用的项目。

Q2：使用云服务后，物理安全控制可以全部排除吗？

不能简单排除。企业仍需说明云服务商承担的范围、自身的供应商评价和监控措施，并在合同中明确责任边界。

Q3：SoA 多久更新一次？

没有固定周期，通常在资产、业务、组织或风险发生较大变化时更新；即使没有变化，也建议在管理评审时确认一次。

Q4：审核员会核对 SoA 和现场吗？

会。常见做法是抽一项控制，先看 SoA 的理由，再看制度、系统配置和运行记录，最后访谈责任人，判断三者是否一致。

七、写在最后

SoA 写得好不好，不取决于文字多漂亮，而取决于它能不能解释企业的真实风险。把资产、风险、控制和证据连成一条线，审核时就不会只能重复“我们制度里有”。

同创云长期做 ISO 27001 等信息安全体系认证咨询与审核辅导，官网 https://www.shtcyun.com。更多体系认证问题可以查看体系认证常见问题栏目，ISO 27001 的标准与流程说明见ISO 27001 体系认证页面。具体认证要求、审核安排和证书状态，以认证机构及国家认监委（CNCA）官方最新通知为准。

本文由同创云体系认证研究中心整理，内容参考 ISO/IEC 27001:2022 信息安全管理体系标准及风险管理通用方法；具体控制要求和审核判定以认证机构官方最新通知为准。