ISO 27001 Statement of Applicability Template: The Document Auditors Check First

Someone tells you the business needs a “Statement of Applicability” for ISO 27001, and the name alone doesn’t explain much. It isn’t a policy. It isn’t the risk register. It isn’t a certificate. But ask any accredited ISO 27001 auditor which document they reach for first on Stage 2 day one, and the answer is almost always the same one: the Statement of Applicability, or SoA. [1]

The short version: the SoA is a mandatory document required by clause 6.1.3(d) of ISO/IEC 27001:2022. [1] It lists all 93 controls in Annex A, states whether each one applies to your organization, and records whether it has actually been implemented and why. It is built directly from your risk assessment output, not copied from a checklist — and that single distinction is where most first-draft SoAs fall apart. This guide covers what the SoA actually is, how it gets built control by control, the three things every row must state, the mistakes that get it rejected, and how it differs from a gap analysis.

What the Statement of Applicability Actually Is

The SoA is a declaration, not a maturity score. For every one of the 93 Annex A controls — spanning the Organizational, People, Physical, and Technological control themes — it records a decision your organization has already made: is this control relevant to how we manage our actual risks, and if so, is it live and operating today? [1][2] It doesn’t grade how well a control performs, and it doesn’t benchmark you against other companies. It states a position and backs that position with a reason an auditor can trace back to a specific risk, asset, or requirement.

That’s what makes the SoA read differently from every other ISMS document. A policy tells people how to behave. A procedure tells them the steps. The SoA tells an outside auditor exactly where to look for the evidence that those policies and procedures exist and actually cover the risks the organization identified. [1] It sits inside the broader certification process alongside the clause structure, the audit stages, and the realistic cost and timeline — covered in full in our ISO 27001 compliance guide.

Why Auditors Treat the SoA as the Audit’s Table of Contents

Every control the SoA marks “applicable” becomes a line item the auditor will sample for evidence during the audit. Every control marked “not applicable” becomes a line item they will interrogate for justification. Nothing in the document is decorative — every row is a promise the rest of the ISMS has to keep. [1][2]

This is what “table of contents” means in practice: the SoA doesn’t just summarize your security posture, it sets the literal agenda for what gets checked, in what order, and against what evidence. If the SoA says control 8.24 (Use of cryptography) is applicable and implemented, the auditor will ask to see the encryption standard, the key management procedure, and evidence it is actually enforced — not a policy that merely mentions cryptography in passing. An SoA that overstates implementation status isn’t a shortcut through the audit; it manufactures findings against your own document. Our internal audit checklist covers how to pressure-test your own evidence before an external auditor does it for you.

How the SoA Is Built From Your Risk Assessment

An SoA isn’t something you free-write from the Annex A list top to bottom. It’s the last step of a sequence: identify assets and the risks affecting them, decide how each risk will be treated (accept, avoid, transfer, or reduce via a control), then map every risk-treatment decision back onto the 93 Annex A controls, one control at a time. [1][3] If a control’s “applicable” status doesn’t trace back to a risk-treatment decision, a legal or regulatory obligation, or a contractual commitment, there is nothing behind it — and an auditor will find that out by asking “why.”

In practice, the SoA gets built as one working pass across all four Annex A themes: Organizational controls (37 controls, numbered 5.1–5.37), People controls (8, numbered 6.1–6.8), Physical controls (14, numbered 7.1–7.14), and Technological controls (34, numbered 8.1–8.34). [3][4] Working the list theme by theme, rather than jumping around, keeps the exercise from missing a control that a single risk touches indirectly — a cloud-hosting risk, for example, has knock-on implications for supplier controls in the Organizational theme, access controls in the Technological theme, and awareness training in the People theme, all at once.

For the methodology that should already exist before you sit down to build the SoA — how assets, threats, and treatment decisions get scored in the first place — see our ISO 27001 risk assessment methodology guide.

The Three Things Every Control Row Must State

Every row in a Statement of Applicability answers exactly three questions, and a competent auditor checks all three independently rather than taking a confident “yes” at face value: [1][2]

• Applicable or not? Does this control address a risk, asset, or requirement identified in the risk assessment, in a legal or regulatory obligation, or in a contractual commitment to a customer or partner?
• Implemented or not? If applicable, is the control actually live and operating right now — not planned, not “in progress since last year,” but observably in place today?
• Justification. A short, specific reason tied to the organization’s real environment: why the control is or isn’t applicable, and — for applicable controls — a pointer to the policy, procedure, or system that implements it.

Skip any one of the three and the row is unusable to an auditor, no matter how confident the “yes” or “no” looks on the page.

Worked Example: 5 Sample Annex A Controls in Mini-SoA Format

The structure is easier to see than to describe. Below is a compact excerpt — five controls out of the full 93 — showing what a properly justified row actually looks like, spanning three different theme types and all three possible answer combinations: applicable and implemented, applicable but only partially implemented, and genuinely not applicable.

Control	Applicable?	Implemented?	Justification
5.9 — Inventory of information and other associated assets	Yes	Yes	Risk assessment identified untracked SaaS accounts and cloud storage as a top asset-visibility gap; asset register now covers all information assets with named owners.
5.23 — Information security for use of cloud services	Yes	Partially	Risk assessment flagged reliance on three unmanaged SaaS vendors handling customer data; cloud security policy drafted, vendor risk reviews not yet complete for all three.
6.3 — Information security awareness, education and training	Yes	Yes	Risk assessment ranked phishing and human error as the top-scoring risk category; mandatory annual training plus quarterly phishing simulations rolled out to all staff.
7.4 — Physical security monitoring	No	N/A	Organization is fully remote with no company-owned or leased office, data center, or server room in scope of the ISMS; no physical premises exist to monitor.
8.24 — Use of cryptography	Yes	Yes	Risk assessment identified customer data in transit and at rest as a high-impact risk; TLS 1.2+ enforced for transit and AES-256 enforced for storage per the cryptography policy.

Two details in that table matter more than the individual rows. First, “partially” isn’t a fourth official SoA category — ISO 27001 only asks for applicable/not-applicable plus implementation status — but tracking a partial state honestly, with a specific completion gap named, is far more defensible to an auditor than rounding a half-finished control up to “implemented.” Second, notice that the “not applicable” row still carries a justification as specific as the “yes” rows. That specificity is exactly what separates a real SoA from the copy-paste version covered next. [1][2]

Common Mistakes That Get an SoA Rejected

Two mistakes account for most of the pushback auditors give on a first-draft SoA:

Marking a control “not applicable” without a real justification. “N/A” or “Not relevant to our business” is not a justification an auditor can trace to anything. A defensible exclusion names the specific reason the risk doesn’t exist for this organization — no physical premises to monitor, no outsourced development activity, no remote-access requirement — in language that maps back to the risk assessment or the ISMS scope statement. [2] A vague exclusion is often the first thing an auditor flags, because it suggests the control was never actually considered.

Copy-pasting a generic SoA template without tailoring it to actual risk assessment results. A template gives you the 93 control names and numbers for free — the structure isn’t the hard part. The hard part, and the part that can’t be templated, is the applicability decision and the justification for each row, because both have to reflect this organization’s actual assets, threats, and risk-treatment decisions. An SoA that reads identically to a competitor’s, control for control, is a strong signal to an auditor that the risk assessment behind it was never really connected to the document in front of them. [1]

Statement of Applicability vs. Gap Analysis: Not the Same Document

These two get confused constantly, and the confusion is understandable — a gap analysis is often run before the SoA and feeds into it. But they answer different questions. A gap analysis measures how close current practice sits to the ISO 27001 requirements: what’s already in place, what’s partially there, and what’s missing, usually expressed as a maturity score or a percentage. [5] The Statement of Applicability is not a maturity assessment at all — it’s a declaration of applicability and implementation status, control by control, with no scoring scale.

Put another way: the gap analysis is diagnostic, and the SoA is declarative. You typically run a gap analysis first to see where the organization stands, then build the SoA as the formal, audit-facing record of which controls apply and whether they’re in place. Our ISO 27001 gap analysis guide covers how to run that diagnostic step, including the maturity scoring that never appears in the SoA itself. If you’re arriving at this from NIS2 compliance and want the full technical control-by-control mapping between the two frameworks, our NIS2 vs. ISO 27001 comparison covers that separately.

FAQ

Is the Statement of Applicability actually mandatory for ISO 27001 certification?
Yes. It’s required by clause 6.1.3(d) of ISO/IEC 27001:2022, and no organization can obtain or maintain certification without one. [1]

How many controls does the SoA need to cover?
All 93 controls in Annex A: 37 Organizational, 8 People, 14 Physical, and 34 Technological. [3][4] Every single one needs an applicability decision, even the ones that end up marked not applicable.

Can a control be “applicable” but not yet implemented?
Yes, and this is common early in a certification project. The applicability decision and the implementation status are two separate answers — a control can be correctly marked applicable while implementation is still in progress, as long as the SoA and the risk treatment plan both reflect that honestly rather than rounding up. [1]

Who should actually write the SoA — IT, compliance, or a consultant?
Whoever owns the risk assessment output should own the first draft, because every justification has to trace back to it. In practice that’s usually a compliance lead or ISMS manager working control-by-control with input from IT, HR, facilities, and legal for the controls that touch their areas.

Does the SoA need to be updated after certification?
Yes. It’s a living document, not a one-time deliverable — it should be reviewed whenever the risk assessment changes, when new systems or suppliers are added, and at minimum as part of the annual management review cycle.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• [1] ISO 27001:2022 — The Statement of Applicability (SoA), ISMS.online
• [2] How to Write an ISO 27001 Statement of Applicability: Free Template + Example, Secureframe
• [3] ISO 27001:2022 Annex A Controls List, Scrut
• [4] ISO 27001 Controls: Overview of All Measures From Annex A, DataGuard
• [5] ISO 27001 Gap Analysis: What Is It and How to Perform One?, Drata