Clause 6.1.3 of ISO 27001:2022 requires organizations to produce a Statement of Applicability — a document identifying which Annex A controls the organization applies, the justification for applying or excluding each, and implementation status. In practice, we often find organizations produce this document merely to pass an audit, disconnected from any genuine risk assessment.
A Good SoA Must Flow From Real Risk Assessment
A quality SoA must be a direct output of the risk assessment process and the Risk Treatment Plan — not a copy of all 93 controls marked "applicable" without genuine consideration of necessity. Doing so signals a misunderstanding of the standard's intent and is frequently flagged by external auditors.
Justifying Excluded Controls
Where an organization determines a control is not necessary, it must provide a clear, reasonable justification — for example, an organization with no in-house software development does not need secure development lifecycle controls. Vague justifications such as "not applicable" with no further explanation are among the most common audit weaknesses we see.
Keeping the SoA a Living Document
The SoA is not a one-time document; it must be reviewed whenever organizational context changes, new technology is adopted, or risk assessment results shift. Mature organizations treat the SoA as a roadmap for the continual development of their information security system, not merely a document produced once a year for the audit.