The Statement of Applicability: The ISO 27001 Document Auditors Open First

Executive Summary

The Statement of Applicability (SoA) is the document an ISO 27001 auditor reads before anything else. Required by clause 6.1.3 d), it lists every Annex A control, states whether each one applies to your organisation, justifies that decision, and records its implementation status. It is the map that connects your risk assessment to your actual controls. When the SoA is weak, the whole audit gets harder, because every other document is read against it.

What the Statement of Applicability actually is

In ISO 27001:2022, the SoA is a mandatory output of clause 6.1.3, the risk treatment step. It is your master control inventory. For each of the 93 Annex A controls, spread across the four themes (organisational 5.x, people 6.x, physical 7.x, and technological 8.x), the SoA has to record four things: whether the control is applicable, the justification for including or excluding it, its current implementation status, and the link back to the risk it addresses.

That last point is the one most teams underweight. The SoA is not a standalone checklist. It is the hinge between two other documents. On one side sits the risk assessment, which tells you what could go wrong. On the other sits the Risk Treatment Plan, which tells you what you are doing about it. The SoA is where those two meet and get reconciled against the Annex A catalogue. ISO does not require you to implement all 93 controls. It requires you to justify, control by control, why each one is in or out.

So the SoA answers a deceptively simple question for every control: did you think about this, and what did you decide? An auditor is not looking for 93 ticks. They are looking for evidence that you made deliberate, risk-based decisions and can defend them.

Why auditors open the SoA first

An experienced auditor opens the SoA first because it tells them, in a few minutes, how seriously the organisation has taken the standard. It reveals the scope of the ISMS, the decisions behind every control, and the quality of the thinking underneath. From there, the rest of the audit is a process of testing whether reality matches what the SoA claims.

In our practice, the SoA is the document that sets the tone for the entire engagement. A clean, well-reasoned SoA signals an ISMS that is genuinely operating. A vague or copy-pasted one signals the opposite, and it invites the auditor to dig harder everywhere else. The document is short relative to the work behind it, which is exactly why it is such an efficient diagnostic. An auditor can read the first page and form a working hypothesis about where the weak points will be.

The 90-second read tends to follow the same path. First the scope statement: what is actually inside the ISMS boundary. Then the applicability declarations: which controls are in and which are out. Then the justification column, especially for any control marked not applicable. Then the version date and the owner. By the time the auditor has scanned those four things, they already know where to spend their day.

The structure a good SoA has

A defensible SoA gives each Annex A control its own row, and each row carries the same fields. The control reference and name, so there is no ambiguity about which control is being addressed. An applicability decision, stated plainly as applicable or not applicable. A justification that is specific to your organisation. An implementation status, so the auditor knows whether the control is in place, partially in place, or planned. And a link to the risk or requirement that drives the decision, whether that is a risk assessment reference, a legal obligation, a contractual term, or a business need.

The fields are not the hard part. Most SoA templates already include them. The hard part is filling them with content that survives a question. A row that reads "A.8.16 Monitoring activities, Applicable, Implemented" is structurally complete and substantively empty. It tells the auditor nothing about what is monitored, how, or by whom. The structure is necessary, but on its own it is not what passes an audit.

The justification column: where most SoAs break

If there is one place where Statements of Applicability fail, it is the justification column. Across the engagements we run, the same patterns show up again and again, and they cluster around the controls that demand a real, organisation-specific answer.

Take A.5.23, information security for the use of cloud services, one of the controls introduced in the 2022 revision. We regularly see this marked "not applicable" by organisations that are visibly running on cloud platforms. That is an exclusion an auditor will challenge in the first ten minutes, because it contradicts what they can see. The reverse failure is just as common: the control is marked applicable with a justification that simply restates the control title, with nothing about which providers are in use or how the relationship is governed.

A.8.16, monitoring activities, is the second recurring weak spot. The justification often reads as a generic statement that "logging is in place," with no indication of what is monitored, what triggers a review, or who owns the response. When the auditor asks to see the monitoring in action, the gap between the SoA wording and the operational reality becomes the finding.

A.5.7, threat intelligence, also new in 2022, is the third. Because it is newer, it is frequently copy-pasted from a template or a peer's SoA, with a justification that describes threat intelligence in the abstract rather than how the organisation actually consumes and acts on it. A justification you could lift wholesale into any other company's SoA is, by definition, not a justification for yours.

The common thread is that a good justification is specific, tied to your risk assessment, and answers the question an auditor will ask next. A justification that could belong to any organisation belongs to none.

The version-control problem on the SoA itself

The SoA documents your control environment, but it is also a controlled document in its own right, and it is surprisingly often the one that slips. We see SoAs with no version number, no approval date, and no named owner. We see SoAs that were last updated before the most recent risk assessment, which means the document an auditor is reading no longer reflects the decisions the organisation has actually made.

This matters because the SoA is supposed to be a living reconciliation. Risks change, controls get implemented or retired, scope shifts when a new system or location comes in. If the SoA is not re-reviewed when those things happen, it drifts. An undated SoA tells an auditor that the reconciliation is not happening on a schedule, and that is a process finding before they have tested a single control.

The fix is unglamorous and reliable: give the SoA a version history, an owner, and a review trigger tied to the risk assessment cycle and to any significant change. The point is not the metadata for its own sake. It is that the metadata is evidence the document is alive.

Reconciling the SoA with the Risk Treatment Plan

Clause 6.1.3 produces both the SoA and the Risk Treatment Plan, and auditors check that the two agree. The Risk Treatment Plan says how identified risks will be treated and which controls will be applied. The SoA says which controls are applicable and implemented. When a control is named in the treatment plan as the response to a risk but is marked not applicable in the SoA, that contradiction is a finding waiting to happen.

In our experience, these mismatches are rarely deliberate. They accumulate because the two documents are maintained on different cycles by different people, and nobody runs the cross-check. The discipline that prevents it is simple to describe and easy to skip: every time the Risk Treatment Plan changes, walk the affected controls through the SoA, and every time the SoA changes, confirm the treatment plan still agrees. Auditors will do that walk for you if you do not.

The gap between the SoA and operational reality

The most consequential SoA failure is not a formatting problem. It is the gap between what the SoA claims and what is actually happening in the business. An SoA can be beautifully structured, fully justified, and version-controlled, and still describe an organisation that does not exist anymore.

This is the gap auditors are built to find. They take a control marked applicable and implemented, and they ask for the evidence. If the SoA says access reviews happen quarterly and the last one was nine months ago, the document is no longer telling the truth, and the auditor now reads every other claim more sceptically. The SoA sets an expectation on every line, and the audit is the test of those expectations.

Keeping the document honest is less about writing and more about cadence. The SoA should be reviewed against operational reality, not just against the standard, on a regular schedule and whenever something material changes. A SoA that matches the business is the single strongest signal that the ISMS is real.

Common mistakes we see

Pulling the patterns together, these are the recurring failures we encounter when we review a Statement of Applicability before a surveillance or recertification audit:

• Justifications that restate the control title instead of explaining the organisation's specific decision.
• Cloud services (A.5.23) marked not applicable by organisations that clearly use cloud platforms.
• Monitoring (A.8.16) justified with generic "logging is in place" wording and no operational detail.
• Newer controls such as threat intelligence (A.5.7) copy-pasted from a template, with no tie to how the organisation actually works.
• No version number, approval date, or named owner on the SoA itself.
• An SoA last updated before the most recent risk assessment, so the two no longer agree.
• Contradictions between the SoA and the Risk Treatment Plan that nobody reconciled.
• Implemented claims that operational evidence cannot support on the day of the audit.

None of these require a fabricated example to illustrate, because they are structural. They come from treating the SoA as a one-time deliverable rather than a living reconciliation.

How to keep your SoA audit-ready

The work that keeps an SoA strong is mostly about treating it as a process rather than a document. Write justifications that a stranger to your organisation could not have written, because they are anchored in your risks, your systems, and your obligations. Give the document a version history, an owner, and a review trigger. Reconcile it against the Risk Treatment Plan every time either one changes. And review it against what is actually happening in the business, not only against the Annex A list, on a schedule you can defend.

A useful test before any audit: read your own SoA the way an auditor would. Start with the scope statement, scan the applicability decisions, stop on every not-applicable justification, and check the version date. If anything on that first read makes you pause, the auditor will pause there too.

If you want a second pair of eyes on your SoA before your next surveillance audit, book an ISO 27001 gap assessment and our team will review it against the structure auditors expect and flag the rows most likely to draw a question. You can also read our companion pieces on picking up after the ISO 27001:2022 transition deadline and on the difference between internal and external ISO 27001 audits.

Frequently asked questions

What is the Statement of Applicability in ISO 27001? It is the mandatory document, required by clause 6.1.3 d), that lists every Annex A control and records whether it applies to your organisation, the justification for that decision, and its implementation status. It connects your risk assessment to the controls you have chosen.

Is the Statement of Applicability mandatory? Yes. It is a required output of the risk treatment process in clause 6.1.3 of ISO 27001:2022. An ISMS cannot be certified without one.

Do I have to implement all 93 Annex A controls? No. You have to consider every control and justify whether it is applicable. You implement the controls that your risk assessment and business context call for, and you justify any exclusions.

What is the difference between the SoA and the Risk Treatment Plan? The Risk Treatment Plan sets out how identified risks will be treated and which controls will be applied. The SoA records, for the full Annex A catalogue, which controls are applicable and implemented. Both come from clause 6.1.3, and auditors check that they agree.

Why do auditors look at the SoA first? Because it shows the scope of the ISMS and the reasoning behind every control in a few minutes, which lets the auditor plan where to test reality against the document.

How often should the SoA be updated? Whenever the risk assessment changes, when scope shifts, when controls are implemented or retired, and on a regular review cycle. An SoA that has not changed since before the last risk assessment is usually out of date.

This article is general information about ISO 27001, not legal or certification advice. Your certification body's requirements and your own risk context determine what your Statement of Applicability needs to contain.