ISO 27001 Statement of Applicability: The Complete 2026 Guide

The ISO 27001 Statement of Applicability (SoA) is the mandatory document that lists all 93 Annex A controls, states whether each one applies to your organization, justifies every inclusion and exclusion, and records whether the control is actually implemented. Clause 6.1.3(d) of ISO/IEC 27001:2022 makes it mandatory — no accredited certification body will issue a certificate without one. It is the first document most auditors open, because it is the bridge between your risk assessment and the controls you really operate. If your risk assessment is already finished, budget two to four working days to produce a defensible first version.

What the ISO 27001 Statement of Applicability must contain

Clause 6.1.3 of the standard covers information security risk treatment. Sub-clause (d) is the one that creates the document. It requires you to produce a Statement of Applicability that contains the necessary controls, the justification for including them, whether they are implemented or not, and the justification for excluding any of the Annex A controls.

Translated into columns, every row of your SoA needs four things:

1. Control reference and name — all 93 of them, using the ISO/IEC 27001:2022 numbering.
2. Applicable — yes or no — a binary decision, not a maybe.
3. Justification — why this control is in scope, or why it is excluded.
4. Implementation status — implemented, partially implemented, or planned with a date.

Four columns is the legal minimum for an ISO 27001 Statement of Applicability. In practice, add four more that cost you nothing and save you hours in the audit room: the control owner, the risk IDs the control treats, a reference to the policy or evidence that proves it, and the date of last review. Auditors follow those references. Without them they ask you to find the evidence live, which is where most Stage 2 audits slow down.

One point that trips people up: the standard does not require you to implement all 93 controls. It requires you to consider all 93 and to explain the ones you drop. Annex A is a checklist for completeness, not a mandatory shopping list. You can read the official scope of the standard on the ISO/IEC 27001:2022 page at iso.org.

SoA vs risk assessment vs risk treatment plan

These three documents get confused constantly, and mixing them up is the fastest route to a nonconformity. They answer different questions and they have to be produced in a specific order.

Document	Question it answers	Clause	Mandatory?
Risk assessment results	What could go wrong, how likely is it, and how bad would it be?	6.1.2 / 8.2	Yes
Risk treatment plan	What are we going to do about each risk, who owns it, and by when?	6.1.3(e) / 8.3	Yes
Statement of Applicability	Which of the 93 Annex A controls apply, why, and are they live?	6.1.3(d)	Yes

The sequence is risk assessment, then treatment decisions, then SoA. Building the ISO 27001 Statement of Applicability first — opening Annex A and ticking boxes before you know what your risks are — is the single most common structural failure I see. It produces justifications that cannot survive a follow-up question, because there is nothing underneath them. All three sit inside the wider set of ISO 27001 mandatory documents your certification body will ask for.

How to build your ISO 27001 Statement of Applicability in seven steps

This is the order that survives an audit.

1. Finish the risk assessment first. You need a risk register with identified risks, owners, and treatment decisions. Everything in the SoA flows from it.

2. Lock the ISMS scope. Applicability is judged against your scope statement. If your scope covers only the SaaS platform and its supporting corporate IT, physical controls for a manufacturing floor are legitimately out. If your scope quietly includes an office you forgot about, your exclusions collapse.

3. Load all 93 controls. ISO/IEC 27001:2022 groups them into four themes: 37 organizational (A.5.1–5.37), 8 people (A.6.1–6.8), 14 physical (A.7.1–7.14), and 34 technological (A.8.1–8.34). Eleven of these are new in the 2022 revision, including threat intelligence, information security for cloud services, configuration management, data masking, data leakage prevention, and web filtering. Our breakdown of the ISO 27001:2022 Annex A controls covers each theme in detail.

4. Decide applicability against four triggers. A control is applicable if any one of these is true: it treats a risk in your register; a law or regulation requires it; a customer contract requires it; or a business requirement demands it. If none of the four applies, it is a candidate for exclusion — and you owe a reason.

5. Write justifications that mean something. “Required by ISO 27001” is not a justification. “Treats risks R-14 and R-22 (credential compromise on the customer portal); also required by clause 4.2 of the MSA with our largest enterprise customer” is.

6. Record implementation status honestly. Use three states: implemented, partially implemented, or planned with a target date. Overstating status is far more damaging than admitting a gap. Auditors expect an ISMS in its first year to have some controls still bedding in. They do not expect to be misled.

7. Approve, version, and date it. A finished ISO 27001 Statement of Applicability needs a version number, an approval by the person accountable for the ISMS, and a date. An undated SoA is treated as uncontrolled documented information.

What a good SoA row actually looks like

Abstract advice is easy to nod at and hard to apply, so here are four rows written the way an auditor wants to read them.

Control	Applicable	Justification	Status
A.5.7 Threat intelligence	Yes	Treats R-08 (undetected exploitation of internet-facing services). Feeds from CISA advisories and our cloud provider bulletins are reviewed weekly by the security lead.	Implemented
A.5.23 Information security for use of cloud services	Yes	Treats R-03 and R-19. The entire production platform runs on a single IaaS provider; also required by the security schedule of two enterprise contracts.	Implemented
A.7.4 Physical security monitoring	No	The organization is fully remote and leases no premises. No physical perimeter falls inside the ISMS scope; data centre monitoring is the provider responsibility and is verified via their ISO 27001 certificate.	Not applicable
A.8.11 Data masking	Yes	Treats R-27 (exposure of production personal data in test environments). Required to support GDPR data minimisation obligations.	Partially implemented — masking live for the primary database, staging pipeline scheduled for Q4

Notice what the exclusion row does. It does not say “not applicable” and stop. It names the reason, ties it to scope, and closes the obvious follow-up question about the data centre before the auditor asks it.

Six mistakes auditors flag in the ISO 27001 Statement of Applicability

1. Justifications that restate the control name. “Access control is applicable because we control access” tells the auditor you copied a template without thinking.
2. Exclusions with no reason. A blank cell next to “Not applicable” is a guaranteed finding under 6.1.3(d).
3. An SoA that predates the risk assessment. The dates on the two documents are visible. If the SoA is older, the decisions in it cannot have been risk-driven.
4. Applicability that contradicts the scope statement. Excluding physical controls while your scope names a head office is an immediate contradiction.
5. “Implemented” with nothing behind it. Every implemented row should point at a policy, a procedure, a ticket, or a log the auditor can sample.
6. A document that never changes. An SoA with a 2023 version number and no review history says the ISMS stopped running.

Most of these get caught at Stage 1, which is precisely what Stage 1 is for. Our guide to the ISO 27001 audit process walks through what the certification body examines at each stage.

How often should you update the ISO 27001 Statement of Applicability?

At minimum, review it annually and take it through management review. Update it sooner whenever any of these happen: the ISMS scope changes, you launch a product or adopt a significant new cloud service, you acquire or merge with another entity, a new legal or contractual requirement lands, a security incident exposes a gap, or an internal audit raises a finding against a control.

Two dates matter right now. The transition from ISO/IEC 27001:2013 to the 2022 edition closed on 31 October 2025, so any SoA still built on the old 114-control structure is no longer certifiable. And Amendment 1:2024 — a free amendment published by ISO — added a requirement to determine whether climate change is a relevant issue for the organization. Where it is relevant, the risks it drives belong in your risk assessment, and anything you do about them belongs in the SoA like any other treatment.

If you want a head start rather than a blank spreadsheet, the ISO 27001 Toolkit ($99, 175 editable templates) includes a pre-built ISO 27001 Statement of Applicability for the 2022 edition with all 93 controls already loaded, alongside the risk assessment worksheet, risk register and risk treatment plan it has to align with. It is the same document set used to take organizations through ISO 27001 certification.

ISO 27001 Statement of Applicability FAQ

Is the ISO 27001 Statement of Applicability mandatory?

Yes. Clause 6.1.3(d) of ISO/IEC 27001:2022 requires it by name, and it is one of the documents a certification body checks at Stage 1. There is no route to certification without one.

Do I have to implement all 93 Annex A controls?

No. You have to consider all 93 and document a justification for each one you exclude. A fully remote software company with no premises will legitimately exclude several physical controls. What you cannot do is drop a control silently.

How long is a typical SoA?

It is normally a spreadsheet of 93 rows. Exported to a document, expect roughly 10 to 25 pages depending on how much detail you put in the justification column. Length is not the measure of quality — specificity is.

Can I share my ISO 27001 Statement of Applicability with customers?

Many organizations do, because it answers a due-diligence questionnaire faster than almost anything else. Treat it as confidential and consider a redacted version: a detailed SoA reveals which controls are only partially implemented, which is useful intelligence for an attacker as well as a prospect.

Who should approve it?

The person accountable for the ISMS — typically the CISO, security lead, or a nominated director — with visible top-management endorsement. Record the approver, the version and the date on the document itself.

What is the difference between the SoA and the risk treatment plan?

The ISO 27001 Statement of Applicability says which controls apply and whether they are in place. The risk treatment plan says what work is outstanding, who owns it and when it will be done. The SoA is a statement of position; the treatment plan is a schedule of action.