The Statement of Applicability: How to Build One That Holds Up at Audit

The Statement of Applicability is a mandatory document under ISO 27001 and one of the first things a certification auditor will ask to see. It is also one of the most commonly misunderstood. Many organisations build their SoA by downloading a template, marking every control as applicable to avoid having to justify exclusions, and then treating it as a compliance artefact rather than a working document. That approach produces a SoA that technically satisfies the requirement but tells the auditor very little about the quality of the underlying risk assessment.

A well-constructed Statement of Applicability demonstrates that the organisation has genuinely assessed its risks, made deliberate decisions about which controls to implement and why, and can justify both its inclusions and its exclusions. Auditors who review SoAs regularly can tell the difference between a document built from genuine risk decisions and one built from a template. The former creates confidence. The latter invites follow-up questions about the risk assessment methodology.

What the SoA Must Contain

ISO 27001 requires the SoA to contain the necessary controls, justification for inclusions, whether controls are implemented or not, and justification for excluding any Annex A controls. The 2022 version of the standard (ISO/IEC 27001:2022) references 93 controls across four themes. For each control in Annex A, the SoA should document whether it is applicable, the reason for its inclusion or exclusion, and its current implementation status.

The justification for inclusion should be traceable to one or more of: a risk identified in the risk assessment and selected for treatment, a legal, regulatory, or contractual obligation, or an organisational policy decision. Controls included solely because they were in the template, with no link to a risk or requirement, are a red flag for auditors. They suggest the risk assessment did not genuinely drive the control selection. Conversely, controls excluded with a clear, documented rationale (such as "this control relates to physical media handling, which is not applicable to our fully cloud-based environment") are defensible and appropriate.

Building the SoA from the Risk Register Outward

The correct sequence for building a SoA is to complete the risk assessment first, identify the risks selected for treatment, determine the controls that will address each risk treatment, and then check those selected controls against Annex A to identify any controls that might be relevant but were not initially selected. The SoA is the output of that process, not the input to it.

This means the SoA cannot be finalised until the risk assessment is complete and the risk treatment plan has been drafted. Organisations that try to build the SoA early in the programme, before the risk assessment is done, are building it in the wrong order. The resulting document may look complete but will not be traceable to actual risk decisions. When an auditor asks "what risk does this control address?", the answer should be findable in the risk register. If it is not, the SoA and the risk register are not aligned, which is a finding.

Handling Exclusions

Many organisations are reluctant to exclude Annex A controls because they are not sure whether exclusions will be challenged at audit. The fear is understandable but misplaced. The standard explicitly anticipates that not all controls will be applicable to all organisations. A small, fully cloud-based company with no physical premises will legitimately exclude most of the physical controls. A software company with no manufacturing process will legitimately exclude controls related to physical media handling.

The test for exclusion is whether the absence of the control would leave an identified risk unaddressed. If there is no risk that the control would mitigate given the organisation's context, the control is not applicable and its exclusion is defensible. Document the rationale clearly: state what the control covers, why it does not apply to the organisation's scope and context, and confirm that no identified risk requires it. A SoA that excludes 20 controls with clear, well-reasoned justifications is more credible than one that includes all 93 with no differentiation.

Keeping the SoA Current

The SoA is a live document. Changes to the organisation's risk environment, scope, or business operations can make previously excluded controls relevant or previously included controls unnecessary. When a company moves from a shared office to a dedicated data centre, physical access controls that were excluded become applicable. When it outsources its entire infrastructure to a cloud provider, certain asset management controls may change in nature.

A SoA that was accurate at certification and has not been updated in two years is a surveillance audit finding waiting to happen. The SoA should be reviewed as part of the annual management review process and updated whenever a material change in scope or risk occurs. The version history of the document should be maintained so auditors can see when updates were made and what changed. We treat the SoA as one of the core ISMS maintenance documents for every client we support post-certification, and ensuring it remains aligned with the current risk register is a standard part of each management review cycle.

To discuss how to build or improve your Statement of Applicability, contact Cyberlinx at info@cyberlinx.com.au.