The Statement of Applicability is not a checkbox exercise
What clause 6.1.3 d actually requires, and how to justify inclusions and exclusions in a way that survives Stage 1 scrutiny.
The Statement of Applicability is often treated as administrative overhead: a document you produce to satisfy clause 6.1.3 d of ISO/IEC 27001:2022 and then file away. Auditors at Stage 1 see it differently. The SoA is the clearest window into whether your risk treatment decisions are reasoned or reflexive.
An SoA that excludes A.6.7 (Remote working) without a documented justification, in an organisation where half the workforce works from home, is not just a finding. It is a flag that the entire risk treatment process may not have been applied honestly, and it tends to shape how hard the auditor looks at everything else.
What clause 6.1.3 d asks for
Paraphrasing, clause 6.1.3 d requires a Statement of Applicability that sets out:
- The controls you have determined are necessary, from your risk treatment under 6.1.3 b and c
- The justification for including each of them
- Whether each necessary control is implemented or not
- The justification for excluding any Annex A control
Two things follow from this that are often missed.
First, inclusions need justifying too, not only exclusions. “Included” with no reason attached tells an auditor nothing about why the control is there. The usual reasons are risk treatment, legal or regulatory obligation, contractual requirement, or a business decision, and the SoA should say which.
Second, the SoA comes out of risk treatment, not the other way round. Clause 6.1.3 c asks you to compare the controls you’ve chosen against Annex A to check nothing necessary has been missed. Annex A is a cross-check, not a menu. You can, and sometimes should, include controls that aren’t in Annex A at all.
The two-sentence test
A justification for exclusion needs to meet a simple test: could it be explained to an auditor in two sentences without reference to convenience or cost?
“We are a single-site organisation with no remote access to the internal network, as documented in our network diagram” is a defensible exclusion. “We considered the control but determined it was not applicable” is not. The difference is the presence of an objective basis.
For each exclusion, identify the characteristic of your organisation or scope that makes the control genuinely inapplicable, and make sure that characteristic is documented somewhere other than the SoA itself: the scope statement, an asset inventory, a network diagram, a contract.
| Control | Weak justification | Defensible justification |
|---|---|---|
| A.6.7 Remote working | Not applicable to our business | All staff work on site; remote access to internal systems is disabled at the firewall (see network diagram v4) |
| A.8.28 Secure coding | We don’t do much development | No software is developed in-house or commissioned; scripting and configuration changes are covered under A.8.9 and A.8.32 (see asset inventory) |
| A.7.4 Physical security monitoring | Our office is small | The ISMS scope excludes physical premises; all in-scope systems are hosted by cloud providers assessed under A.5.23 (see scope statement) |
| A.8.11 Data masking | Too costly to implement | No production data is used in testing or shared outside production; this was confirmed in the risk assessment (risk ref. R-14) |
Notice that none of the defensible versions mention cost. Cost can legitimately influence how you implement a control, or which risks you accept, but “it would be expensive” is not a reason a control does not apply. If cost is the real reason, the honest route is to record a risk acceptance by the risk owner under 6.1.3 f, not to exclude the control.
Exclusions that are rarely defensible
Some controls describe things every organisation does in some form, which makes them very hard to exclude. Auditors commonly push back on exclusions of:
- A.5.1 Policies for information security. Clause 5.2 requires an information security policy regardless.
- A.5.24 to A.5.28, incident management. Every organisation has incidents, even if it has never written one down.
- A.6.3 Information security awareness, education and training. Clause 7.3 requires awareness of the policy anyway.
- A.8.7 Protection against malware and A.8.13 Information backup, for almost any organisation using IT at all.
The same logic applies to physical controls in fully remote organisations. It is tempting to exclude most of the A.7 theme, but staff still use laptops at home and in transit, so A.7.9 (Security of assets off-premises) and A.7.10 (Storage media) usually remain relevant.
The new 2022 controls
For the 2022 revision, particular scrutiny falls on the 11 controls added to Annex A: A.5.7, A.5.23, A.5.30, A.7.4, A.8.9, A.8.10, A.8.11, A.8.12, A.8.16, A.8.23 and A.8.28. Auditors commonly probe these during transition and first-certification audits, so excluding any of them should be treated as a high-documentation-burden decision.
Several of them scale down well, which weakens the case for exclusion. If you exclude A.5.7 (Threat intelligence) on the grounds that it is disproportionate to your organisation’s risk profile, expect the auditor to point out that subscribing to your national cyber security centre’s advisories and recording what you did about them is a modest implementation. If you still exclude it, document the risk profile that supports the conclusion, and make sure it is consistent with your information security risk assessment.
Keeping it honest over time
An SoA that was accurate at certification drifts. A common surveillance finding is an SoA that no longer matches reality because the organisation changed and the document didn’t. Triggers for review include:
- A change to the ISMS scope, such as a new site, product, or business unit
- A change in working pattern, such as moving to hybrid or remote working
- Adopting a new cloud service or outsourcing a function
- Starting software development, or stopping it
- New legal, regulatory or contractual obligations
- The annual risk assessment review
Each of these can turn a defensible exclusion into an indefensible one. Add an SoA check to whatever change process you already run, and keep a version history so you can show an auditor when and why a decision changed.
Where StayEvident fits
In StayEvident the SoA is generated from the scope decisions you have already made, rather than maintained as a separate document. Exclusions carry their justification, which inherits down the clause tree when you exclude a whole theme, and included Annex A controls record why they are included. The on-screen view and the PDF export are built from the same data. See Statement of Applicability for details.