The Statement of Applicability isn't a list of controls. It's the argument for all of them.

Ask most people preparing for their first ISO/IEC 27001 certification audit what the Statement of Applicability is, and the answer is some version of: the list of the 93 Annex A controls, with a column marking each one applicable or not. That's a common shorthand, but it's technically incomplete. Clause 6.1.3 requires an organisation to determine the controls it needs to treat its risks — which can include controls that aren't in Annex A at all — and only then compare that list against Annex A to check nothing necessary has been missed. Under 6.1.3(d), the resulting Statement of Applicability has to record a justification for every control that's in, a stated implementation status for each one, and a justification for every Annex A control that's been left out. A yes/no column against a fixed list of 93 items is a checklist. What the clause describes is closer to a documented, examinable argument, with the risk assessment and risk treatment process as its evidence.

That gap between the two readings is not academic. Published auditor guidance — including ISO/IEC JTC 1/SC 27's own auditing practice notes on the Statement of Applicability and on Annex A — repeatedly identifies weak, outdated or poorly justified SoAs as a recurring source of audit findings. The issue is rarely a missing control. It's usually that the reasoning behind the list doesn't hold up under examination: a control marked applicable with no traceable basis, an exclusion recorded as "not applicable to our business" rather than a documented reason, or an implementation status describing an intention rather than the organisation's actual position.

None of that requires a new development to be worth setting out — it's a standing pattern, which is exactly why it's worth being precise about outside the pressure of a booked audit. What follows sets out what clause 6.1.3(d) requires, what an accredited audit examines at each stage under ISO/IEC 27006-1, and why that independent scrutiny is worth more than the paperwork it produces.

Where the SoA sits in the ISMS

The Statement of Applicability is not produced in isolation, and in an established ISMS it is rarely produced only once. It sits in a sequence that repeats as the organisation's risk position changes, and that a certification body examines at more than one point:

‍

‍

Most of the failure patterns below trace back to treating the SoA as a document produced once, straight from Annex A, rather than as something that has to keep answering to the risk treatment behind it.

What clause 6.1.3(d) actually requires

It isn't only a copy of Annex A

Annex A groups its 93 controls into four themes: organisational (37 controls), people (8), physical (14) and technological (34). Annex A itself is not a requirements list to work through line by line — ISO/IEC JTC 1/SC 27's own auditing guidance is explicit that a control's presence in Annex A does not, on its own, make it necessary to a given organisation, and describes Annex A as an aide-memoire for checking completeness rather than a checklist to satisfy. The correct order reverses how many organisations actually work: determine the controls necessary to treat the risks identified in the risk assessment — which can include controls outside Annex A — compare that list against Annex A to confirm nothing necessary was missed, and only then produce the SoA recording the result.

"Applicable" needs a reason, regardless of the count

Including all 93 Annex A controls is not, on its own, a problem. ISO/IEC 27001 does not reward exclusions, and an audit shouldn't infer weak risk analysis merely from how many controls are marked applicable. What gets examined is whether each one has a stated reason — and SC 27's own guidance is direct that simply appearing in Annex A is not itself that reason. The same logic runs the other way for exclusions: "not applicable to our business" is not, on its own, a justification. A justification ties the decision to the organisation's assessed risk, a legal or contractual obligation, or another documented, independently justifiable basis.

It has to trace back to something — not only a risk register

Clause 6.1.3(d) asks for a justification, not a specific document format, and ISO/IEC 27001 doesn't require an organisation to keep something literally called a "risk register." Necessity most often comes from the organisation's assessed risks, but it can equally come from legal or contractual obligations, or, exceptionally, another independently justified basis where the underlying risk is hard to quantify. What every necessary control needs is a traceable rationale in the organisation's risk-treatment arrangements — which a Statement of Applicability copied from a previous cycle, a template, or another organisation's document, without being revisited, generally will not have. Reused, unrevisited SoAs are a consistently flagged source of avoidable inconsistency.

"Implemented" is a status, not an aspiration

Clause 6.1.3(d) requires the SoA to state whether each necessary control is implemented or not — not whether it's intended, planned, or scheduled. An SoA that accurately distinguishes implemented controls from ones that aren't yet is more useful, and more accurate, than one that records intentions as facts. That accuracy is necessary but not sufficient on its own: Stage 2 goes on to test whether the controls recorded as implemented actually are, and whether they're effective — not simply whether the document says so.

What weak SoAs have in common

• A copy-pasted or reused SoA is a common, avoidable source of inconsistency. Language that hasn't been adapted to the organisation's actual risk treatment is straightforward to identify against the rest of the evidence during an audit.
• Marking everything "applicable" doesn't add assurance on its own. What an audit tests is whether each entry has a genuine, traceable basis — not how many controls happen to be included.
• An SoA that stays static while the organisation changes invites closer examination. New systems, suppliers, obligations or organisational changes can shift which controls are necessary; when they do, the audit looks for a corresponding update, or a documented reason there isn't one.

Where ISO/IEC 27001 certification fits — and its limit

An accredited ISO/IEC 27001 certificate is independent assurance that an organisation's risk assessment and risk treatment process, the controls it has determined as necessary, its Statement of Applicability, and the implementation and effectiveness of those controls have actually been examined against the standard — not merely that the organisation completed its own paperwork.

It does not guarantee that a security incident will never occur, and it does not mean there is only one valid way to treat a given risk. Its value is independent, competent scrutiny of whether an organisation's own risk-based decisions are coherent, implemented and effective — scrutiny that has to come from a party with no stake in how the ISMS was designed in the first place.

Checking your own SoA — and anyone else's certificate

Three questions are usually enough to tell whether a Statement of Applicability will hold up under that kind of examination: does every control marked applicable have a traceable basis in the organisation's risk treatment, legal or contractual obligations, or another documented reason; does every exclusion state a reason beyond a variant of "not applicable"; and does the implementation status reflect where the organisation actually is, not where a project plan expects it to be. An SoA that answers those honestly is doing what clause 6.1.3(d) asks of it, independent of its age or format.

The same standard of evidence is worth applying to anyone claiming certification: ask for the accreditation certificate itself, not the marketing claim, and check the relevant accreditation body's public register — DAkkS, UKAS, ANAB, RvA and equivalents — for the standard, edition and scope actually covered. Proks Certification GmbH is DAkkS-accredited for ISMS certification; our current scope, DAkkS document D-ZM-21201-01-02, covers DIN EN ISO/IEC 27001:2024-01 — the German and European adoption of ISO/IEC 27001:2022 — audited under DIN EN ISO/IEC 27006-01:2024-08, and forms part of our parent accreditation, D-ZM-21201-01-00.

Proks's role is deliberately different from an ISMS consultant's. ISO/IEC 17021-1 requires a certification body — together with any part of the same legal entity and any entity under its organisational control — to remain impartial, and prohibits offering management-system consultancy alongside certification. We can explain what clause 6.1.3(d) and the rest of the standard require, and clarify audit findings; we do not draft a client's Statement of Applicability or choose its controls. That separation isn't a limitation we work around — it's part of what makes accredited certification worth something a consultant can't independently provide.

What an accredited audit will look for

At Stage 1, or any documentation review

• Consistency between the SoA and the risk treatment plan it's meant to reflect is reviewed before any implementation evidence is sampled — a mismatch in dates or scope is often the first sign a document has fallen out of sync.
• Whether internal audit and management review have already covered the SoA factors into how much the external audit still needs to test directly.

At Stage 2, surveillance or recertification

• Whether controls recorded as implemented actually are, and are effective, is tested against sampled evidence, not against the SoA's own wording.
• Whether risk, scope, assets or obligations have changed since the last review, and whether the SoA changed with them, is examined at every subsequent visit — not assumed from the fact that nothing changed on paper.

Whenever something in the organisation changes

• A new system, supplier, regulatory obligation or organisational change is the kind of event a later audit expects to see reflected in the SoA within a reasonable, demonstrable cycle — not necessarily the same day, but not left for the next scheduled visit to surface either.

Why this is worth more than passing an audit

Underneath the documentation requirement, clause 6.1.3(d) asks an organisation to put something in writing: which risks it has decided to treat, which it has decided not to, and why — specific enough that someone else could examine the reasoning later. Explicit, reviewable risk decisions are useful in their own right, independent of certification, because they turn judgement calls into something that can be checked rather than assumed.

What accredited certification adds is a party with no stake in how the ISMS was designed, testing whether that reasoning actually holds up against the evidence — a different kind of value than help getting the paperwork in order, and why accredited certification is worth more than the sum of the documents it produces.

A well-designed Statement of Applicability belongs to the organisation that wrote it. An accredited certification body's role is to test, independently and competently, whether the reasoning behind it is consistent with the ISMS and supported by evidence. If you're considering ISO/IEC 27001 certification and want to understand Proks's accredited scope, certification process or audit stages, get in touch.

Sources

• ISO/IEC 27001:2022, clause 6.1.3 (risk treatment) and Annex A
• ISO/IEC JTC 1/SC 27/WG 1, "Auditing Practices Note — Statement of Applicability" (N3298)
• ISO/IEC JTC 1/SC 27/WG 1, "Auditing Practices Note — Annex A" (N3297)
• ISO/IEC 27006-1:2024, requirements for bodies providing audit and certification of ISMS
• ISO/IEC 17021-1:2015, clause 5.2.5 (impartiality and management-system consultancy), as summarised by European Accreditation
• NQA, "ISO 27001 SoA & Risk Register: Common Mistakes Explained," March 2026
• Cyberday, "10 Most Common Non-Conformities in ISO 27001 Audits"
• DAkkS, accreditation scope documents D-ZM-21201-01-00 and D-ZM-21201-01-02 (Proks Certification GmbH)

Last reviewed: 22 September 2026. This article explains what ISO/IEC 27001:2022 clause 6.1.3(d) requires of a Statement of Applicability, and what an accredited audit examines, in general terms; it is not accreditation, audit, or legal advice for any specific organisation's ISMS.

DEUTSCHE FASSUNG

22. SEPT. 2026  /  STANDARDS

‍