ISO/IEC 27001 FAQ SoA Exclusions

Start with the risk-treatment process, not the Annex A table. Clause 6.1.3 requires the organization to determine every control necessary for its chosen treatments, compare those controls with Annex A to verify that none were overlooked, and then explain any Annex A exclusions in the Statement of Applicability.

An excluded Annex A control is defensible when the organization can show why that reference control is not necessary in the scoped ISMS. The reason may follow from scope, technology, locations, information handled, interfaces, dependencies, assessed risks, or applicable requirements. Another control may contribute to the explanation, but naming an alternative alone does not show that the Annex A control is unnecessary.

The exclusion should trace back to the documented ISMS scope, risk-assessment results, selected treatment options, necessary-control determination, and the comparison with Annex A. A short rationale can be sufficient when that chain is clear; a generic 'not applicable' label is not self-explanatory.

Keep evidence proportionate to the decision. For example, an organization that does not operate its own data centre should not automatically exclude every physical control: its scope and supplier interfaces must still show which physical risks and responsibilities remain with the organization and which are handled through the provider. A supplier performing the activity can change the implementation method without making the control unnecessary.

ISO/IEC 27001 explicitly requires risk-owner approval of the risk-treatment plan and acceptance of residual risks. It does not prescribe a universal job title that signs the SoA. The organization should define SoA approval so control selection, exclusions, treatment decisions, and residual-risk approvals remain consistent.

A practical review includes the ISMS owner, relevant risk owners, and control or service owners; legal, privacy, supplier, resilience, or technical specialists should be involved when their requirements or dependencies affect the rationale. This is governance guidance, not a certification rule that creates a mandatory committee.

Review exclusions when the underlying risk assessment or treatment changes. Clause 8.2 requires reassessment at planned intervals and when significant changes are proposed or occur, so the SoA should not remain frozen while scope, systems, suppliers, threats, contracts, or legal requirements change.

Also review an exclusion when audit evidence, an incident, a failed dependency, or a new service shows that the earlier applicability assumptions were incomplete. The result may be a revised rationale, a newly necessary control, or a changed implementation status.