ISO 27001 Statement of Applicability: how to write one auditors accept

What the standard requires

Clause 6.1.3 of ISO/IEC 27001:2022 describes the information security risk treatment process. After selecting risk treatment options and determining the controls you need, you must compare them with Annex A to verify that no necessary controls have been omitted (6.1.3 c). Then, under 6.1.3 d), you produce a Statement of Applicability that contains four things.

The SoA is mandatory documented information. There is no prescribed format: a spreadsheet, a table in a document or a view in a GRC tool all work, as long as it is controlled, versioned and approved.

• The necessary controls, whether taken from Annex A or from other sources.
• The justification for their inclusion.
• Whether the necessary controls are implemented or not.
• The justification for excluding any of the Annex A controls.

A practical column layout

A one-column yes or no list satisfies nobody. A layout that works for auditors and for your own team usually has the following columns, one row per Annex A control plus any extra controls you added. Keep the descriptions short; the SoA points to evidence, it does not replace policies and procedures.

• Control number and name, for example 5.15 Access control.
• Applicable: yes or no.
• Justification for inclusion: the risk IDs it treats, plus legal, contractual or business requirements.
• Justification for exclusion, if not applicable.
• Implementation status: implemented, partially implemented, planned with target date.
• Reference to the policy, procedure or record that demonstrates the control.
• Control owner.

Example entries

Example of an included control. 8.13 Information backup. Applicable: yes. Justification: treats risks R-07 (ransomware encrypts production database) and R-12 (accidental deletion of customer data); contractual requirement in customer master agreement. Status: implemented. Evidence: Backup and Restore Procedure v2.1, quarterly restore test records. Owner: Head of Infrastructure.

Example of a justified exclusion. 7.11 Supporting utilities. Applicable: no. Justification: the organisation operates no own server rooms; all production systems run in a public cloud region whose provider's power and cooling are covered by provider assurance reviewed under 5.22 and 5.23. Office workstations hold no data that is not synchronised to cloud services. Note that this kind of exclusion needs care: the auditor may still ask about office network equipment.

Example of a planned control. 8.12 Data leakage prevention. Applicable: yes. Justification: risk R-15 (customer data exported via unmanaged channels). Status: partially implemented; email DLP rules active, endpoint controls planned for Q1 with owner and budget approved in the risk treatment plan.

How to justify exclusions properly

Exclusions are where auditors focus. A control can be excluded only if no risk, legal requirement or contractual obligation needs it. 'Not relevant to us' is not a justification; a sentence explaining why the underlying situation does not exist is. Typical defensible exclusions are physical controls for fully remote companies without premises of their own, or 8.30 Outsourced development when no development is outsourced.

Be careful with controls that look irrelevant but are not. Small companies often exclude 8.28 Secure coding because they do not see themselves as software developers, while they write scripts, infrastructure as code and integrations. Remote-first companies exclude 7.7 Clear desk and clear screen, forgetting that screens in home offices and coffee shops are exactly where the risk lives. If a control applies to part of your operations, include it and describe the limited scope.

Linking the SoA to risk assessment and the treatment plan

The SoA should not be written first. The order in the standard is deliberate: assess risks, decide treatment, determine necessary controls, compare with Annex A, then document the result. If your SoA was filled in from a template before the risk assessment existed, the justifications will not match the risk register and the auditor will notice.

Traceability works in both directions. Every risk with a treat decision in the register should point to one or more controls, and every applicable control should point to at least one risk or requirement. Controls marked as planned must appear in the risk treatment plan required by 6.1.3 e) with owners, resources and target dates. When the risk assessment is updated, review the SoA in the same cycle and change the version number.

What auditors check in the SoA

In Stage 1 the auditor reviews whether the SoA exists, is complete for all 93 Annex A controls of the 2022 version, and contains justifications. In Stage 2 the auditor samples controls marked as implemented and asks for evidence, interviews control owners and checks that the claimed status is true. A control marked implemented with no working evidence becomes a nonconformity, while an honest partially implemented status with a credible plan usually does not.

• Is the SoA based on the 2022 Annex A structure, not the old 114 controls from 2013?
• Do justifications reference actual risks and requirements rather than generic phrases?
• Is implementation status accurate and dated?
• Is the document approved by management and under version control?
• Are the exclusions consistent with the scope statement and the reality of the site visit?

Keeping the SoA alive

Version control matters more than many teams expect. Certification bodies record the SoA version that was in force at the time of the audit, and the certificate itself often references it. If you change the SoA between Stage 1 and Stage 2 or between surveillance audits, keep the change history with a short reason for each change, for example a control moved from planned to implemented after a restore test, or a new control added because a customer contract introduced encryption requirements. That history is also the quickest way to show improvement during management review.

Treat the SoA as a living register. Review it after every risk assessment update, after significant changes such as a new office, a new product or a move to a different cloud provider, and before every surveillance audit. Record the review in the document history even when nothing changes, so you can show it was considered. Many teams also use the SoA as the master index for internal audit planning, sampling a set of controls each quarter.

Before writing your SoA, it helps to know which controls you already operate in practice. A free self-assessment on baltum.ai shows your current ISO 27001 readiness and the control areas with the largest gaps, which gives you a starting point for both the risk treatment plan and the SoA.

This article is for general information and is not legal advice. baltum.ai is independent software, not a certification body.