Writing Statement of Applicability justifications an auditor will accept

The Statement of Applicability is the document that ties your risk treatment decisions to the controls in Annex A of ISO 27001:2022. In principle it is straightforward: for each of the 93 controls, you note whether it is included or excluded, and you provide a justification for that decision. In practice, the justification column is where certification audits most often slow down or produce nonconformity findings.

This article covers what a credible justification looks like for both included and excluded controls, the weak justification patterns that auditors flag every time, and how to link your rationale to the risk register in a way that survives detailed questioning.

What the standard requires from your justifications

Clause 6.1.3 of ISO 27001:2022 says the SoA shall contain the necessary controls, the justification for their inclusion, whether they are implemented, and the justification for excluding any Annex A controls. The standard does not specify how long justifications must be or what format they should take, but "justification" means something specific: a reason that is particular to your organisation and traceable to evidence.

The 2022 revision also changed the structure of Annex A from 114 controls across 14 clauses to 93 controls across 4 themes. ISO 27001:2013 was withdrawn when the transition period closed on 31 October 2025, so every current certificate is against the 2022 structure. If your SoA still uses the 2013 control list, it does not match the standard you are certified against, and it will be raised as a nonconformity.

What strong inclusion justifications look like

A strong inclusion justification does three things: it names the risk or obligation that makes the control necessary, it links to where that risk or obligation is documented, and it is specific to your environment.

Consider A.8.12 (Data leakage prevention). A weak justification: "Applicable. Required to protect sensitive data." This tells the auditor nothing about your organisation.

A strong justification: "Included. Risk ID R-047 (exfiltration of customer PII via removable media and email) assessed at High before treatment. DLP controls applied to managed endpoints and email gateway. Residual risk accepted by Head of Engineering, 2026-07-01."

That single sentence gives an auditor a risk reference to check in the register, a named treatment mechanism to verify in your technical controls, and a sign-off trail to sample. It takes about forty words and it holds up under questioning.

For controls justified by legal or contractual obligation rather than risk - for example A.5.31 (Legal, statutory, regulatory and contractual requirements) - the justification should name the specific obligation: "Included. Required under UK GDPR Article 32, contractual clause 8.4 of the MSA with [category of customer], and NIS Regulations 2018."

What strong exclusion justifications look like

Exclusions receive less attention in most SoA guides, but they carry at least as much audit risk as inclusions. An auditor who disagrees with an exclusion and finds evidence that the control scope applies to your organisation may raise a major nonconformity.

Strong exclusion justifications must explain why the control is not applicable and provide a basis for that claim that an auditor can verify. Consider A.7.3 (Securing offices, rooms and facilities). If your ISMS scope covers only cloud-hosted services with staff working remotely and no physical premises under scope, an exclusion might read: "Excluded. ISMS scope is limited to cloud-hosted services (AWS eu-west-1 and eu-west-2). No physical premises or offices are within scope as documented in the scope statement (Doc ref: ISMS-SCO-01). Physical security for AWS data centres addressed under supplier assurance programme."

That exclusion tells the auditor where to verify the scope boundary, where to check the supplier assurance rationale, and why the control does not apply to your operating model.

The weak justification patterns that auditors flag every time

These appear in almost every SoA that was built from a template and not properly tailored:

"Industry best practice." This is not a justification. Best practice for whom? Based on what risk? An auditor will ask what specific risk or obligation makes this control necessary for your organisation, and "best practice" does not answer that question.

"Required by policy." Your policy is downstream of your risk and control decisions, not the justification for them. If the justification for including A.8.5 (Secure authentication) is that your access control policy requires it, the auditor will ask why the policy requires it, and the answer should loop back to a risk.

"Not applicable." This appears as a full exclusion justification in a large number of SoAs. It is not a justification at all. The auditor needs to understand why it is not applicable.

"To be implemented." This appears in the implementation status column, which is valid - but if it also bleeds into the justification column, it suggests the justification was never written at all.

Identical justifications across multiple controls. If eight controls all read "Applicable. Required to maintain confidentiality, integrity and availability," the auditor knows the justifications were written generically rather than tailored. They will test several of them in detail.

Linking justifications to your risk register

The connection between the SoA and the risk register is the most scrutinised area in a well-run certification audit. The practical approach is to include a risk reference column in your SoA (or an embedded cross-reference in the justification text) that points to the specific risk IDs in your register that justify inclusion.

For controls justified by multiple risks - A.8.2 (Privileged access rights) might be justified by risks related to insider threat, credential compromise, and third-party access - list all the relevant risk IDs. This also serves as a useful diagnostic: if a control has no risk IDs attached to its justification, you have a gap to resolve before the audit.

For controls excluded on scope grounds, the justification should reference the scope statement document and version. Scope statements change; if the exclusion was valid under a previous scope but your scope has expanded, the exclusion needs to be reviewed and either maintained with updated rationale or converted to an inclusion.

Handling the eleven new 2022 controls

Annex A 2022 introduced eleven controls that did not exist in the 2013 version. For each of them - including A.5.7 (Threat intelligence), A.5.23 (Information security for use of cloud services), A.8.10 (Information deletion), and A.8.12 (Data leakage prevention) - your SoA needs a specific consideration, not just carryover from a 2013-era document.

Organisations that converted from ISO 27001:2013 without revisiting their SoA for these controls are particularly exposed. Auditors will specifically ask how each new control was considered. If the answer is that it was not, and the control is simply excluded without a documented rationale, that is a gap.

Practical writing process

The order that produces the best results: write your risk register first, complete treatment decisions with Annex A control references, then write the SoA justifications using the risk IDs as anchors. If you write the SoA first and the risk register second, you almost always end up with justifications that do not match the risk evidence - because the risk evidence was not yet available when you wrote them.

Review the SoA at each risk register update and whenever your scope changes. A document that was accurate at certification can become misleading within six months if controls have changed status and the justifications have not been updated.

Where Kellwick fits

Kellwick's readiness assessment includes a line-by-line SoA review against your risk register - identifying justifications that will not survive audit questioning and helping you rewrite them with the specificity and traceability that an ISO 27001 auditor looks for before they sign off on the control picture.