How to Write a Statement of Applicability That Passes Audit

The Statement of Applicability is one of those documents that looks straightforward on paper and consistently produces audit findings in practice. It is explicitly required by ISO 27001:2022 Clause 6.1.3, it is one of the first documents your auditor will request, and it is cross-referenced against your risk register, your policies, and your actual evidence throughout the Stage 2 audit. Getting it wrong is costly — at best it is an observation, at worst it is a major nonconformity that delays certification.

This guide covers what the SoA must contain, how to construct justifications that satisfy auditors, and the specific mistakes that organisations make repeatedly.

What the SoA Actually Is

Clause 6.1.3 of ISO 27001:2022 states that the organisation shall produce a Statement of Applicability that contains the necessary controls and justification for inclusions, whether they are implemented or not, and the justification for exclusions of any of the Annex A controls.

In plain terms: the SoA is a spreadsheet or structured document that lists every one of the 93 controls in Annex A (organised across 4 themes: Organisational, People, Physical, and Technological), records whether each control applies to your organisation, and explains why for every decision — both inclusions and exclusions.

The SoA is not a checkbox exercise. Auditors treat it as a window into your security thinking. A well-written SoA demonstrates that your team has genuinely considered each control in the context of your environment and made deliberate, risk-informed decisions. A poorly written SoA — one that marks controls as not applicable without justification, or one that marks everything as applicable without evidence of implementation — signals that the ISMS is superficial.

The 3 Things Every SoA Must Include

1. All 93 Annex A Controls Listed

ISO 27001:2022 reorganised the controls from the previous version's 114 controls across 14 domains into 93 controls across 4 themes. Every control must appear in your SoA. Omitting a control — even one you consider irrelevant — is a gap. The absence of a row for a control will be flagged by the auditor as an incomplete SoA.

The four themes are:

• Organisational controls (37 controls, 5.1 to 5.37)
• People controls (8 controls, 6.1 to 6.8)
• Physical controls (14 controls, 7.1 to 7.14)
• Technological controls (34 controls, 8.1 to 8.34)

A pre-built SoA template ensures you have all 93 rows from the start, eliminating the risk of accidentally omitting a control. Download the free SoA template at isoready360.gumroad.com/l/free-soa to start from a complete structure.

2. An Applicable / Not Applicable Decision for Each Control

For every control, you must make an explicit decision: is this control applicable to your ISMS or not? This is a binary decision, though some organisations add an "implementation status" column alongside it (see below).

The applicable/not applicable decision should be driven by two inputs: your risk assessment and the legal, regulatory, contractual, and business requirements you have identified. If a risk in your risk register is treated by a specific control, that control is applicable. If no risk, requirement, or business need connects to a control, it may be a candidate for exclusion — but only with documented justification.

In practice, the large majority of controls will be applicable for most organisations. For a software company with cloud infrastructure, physical controls like "physical security perimeters" (7.1) and "securing offices, rooms, and facilities" (7.3) are genuinely applicable — you have an office and you process data there. Controls like "clear desk and clear screen" (7.7) are applicable even for a remote-first company.

3. Written Justification for Every Exclusion

This is where most SoA documents fail. Marking a control as "not applicable" without a written justification is a major nonconformity. The standard is explicit: exclusions require justification.

A valid justification is specific. It explains why the control does not apply given your scope, your environment, and your risk landscape. "Not relevant" is not a justification. "Our organisation does not have physical media (tapes, drives) in transit, and all data transfers occur over encrypted network connections, making Control 8.12 (Data masking for physical media transfer) not applicable" is a justification.

Acceptable grounds for exclusion include: the control relates to a physical environment or technology your organisation does not use within scope; the associated risk has been treated by an alternative control that achieves the same objective; or the control is genuinely irrelevant to your business model and no risk in your register points to it.

Implemented vs. Planned: The Status Column

Beyond the applicable/not applicable decision, your SoA should record the implementation status of each applicable control. The standard allows for controls to be marked as "planned" at Stage 1 — meaning you have decided to implement them but have not yet completed implementation. By Stage 2, however, controls that remain in "planned" status must have a documented timeline and a clear reason why they are not yet fully operational.

The distinction matters for auditors. A control marked as "implemented" is subject to evidence verification at Stage 2 — the auditor will ask to see proof. A control marked as "planned" is subject to scrutiny about why it is not yet implemented and whether that gap represents a risk that has been accepted by management.

A common mistake is marking controls as "implemented" when they are only partially in place. If your access control review process exists in policy but has not been performed yet, the control is not implemented — it is planned. Overstating implementation status leads to audit findings when evidence cannot be produced.

How Risk Treatment Maps to the SoA

Your risk register and your SoA must be consistent. This is one of the primary cross-references auditors perform. For each risk where the treatment decision is "mitigate," your risk register should name the specific Annex A controls being used to mitigate it. Those same controls must appear as "applicable" in your SoA.

If Control 8.2 (Privileged access rights) is listed as the treatment for your "unauthorised system access" risk, it must be marked applicable in the SoA. If it is marked "not applicable" in the SoA, the auditor will ask how that risk is being addressed — and if there is no clear answer, that is a nonconformity.

Build your SoA and risk register in parallel, or build the risk register first and use it to populate the applicable column of your SoA. The two documents should reference each other directly — your SoA can include a column citing the risk IDs that justify each inclusion.

What Auditors Check in the SoA

During Stage 1, the auditor reviews the SoA for completeness and logical consistency. They are looking for:

• All 93 controls present
• No unexplained exclusions
• Alignment between the SoA and the scope document (applicable controls match what is in scope)
• Management approval signature and date
• Version control — the SoA must show its revision history

During Stage 2, auditors select a sample of applicable controls — typically 15 to 25 — and request evidence of implementation for each. They will specifically target controls where your risk register shows a high-rated risk, and controls that are commonly misimplemented (access reviews, logging and monitoring, supplier security assessments).

Auditors also look for internal consistency. If your Information Security Policy references certain controls as mandatory, those controls must appear as applicable in the SoA. If your supplier security questionnaire process is described in your Supplier Security Policy, Control 5.19 (Information security in supplier relationships) must be applicable and implemented.

Practical Tips for Writing Justifications

For inclusions, your justification column should cite at least one of the following: a specific risk ID from your risk register, a legal or regulatory requirement (GDPR Article 32, a contractual obligation), or a business requirement (customer security requirement, industry standard practice). A one-sentence citation is sufficient.

For exclusions, write a two-to-three sentence justification that names the specific reason the control does not apply. Reference your scope and your environment. If you are excluding a physical control because you do not have an on-premises data centre, say so explicitly: "Control 7.8 (Equipment siting and protection) is excluded because all computing infrastructure operates in a third-party cloud environment (AWS). No physical server equipment is owned or operated by the organisation within the ISMS scope."

Avoid generic language. "Not applicable to our business" is not a justification. "We do not use this technology" requires elaboration — which technology, why not, and what alternative control (if any) addresses the underlying risk.

Once written, have the SoA reviewed by someone who did not write it. Common errors — missing controls, inconsistent applicability decisions, missing justifications — are easier to spot with fresh eyes. Your internal auditor should review the SoA as part of the internal audit process.

Finally, treat the SoA as a living document. When your environment changes — a new technology platform, a new office location, a significant change in your service offering — review the SoA and update it. An SoA that does not reflect your current environment is a finding waiting to happen at your next surveillance audit. Keep the version history updated and retain prior versions.