iso27001partnersThe Statement of Applicability, and how to read one
The standard requires the organisation to “produce a Statement of Applicability that contains: the necessary controls (see 6.1.3 b) and c)); justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the Annex A controls”. In short, and in our reading: every Annex A control is either included, with a reason and an implementation status, or excluded, with a reason.
A certificate tells you that somebody was audited, against which edition, and within what scope. The Statement of Applicability tells you what they decided to do about security and why — including what they decided not to do. Every page on this site mentions this document. None of them, until now, told you how to read one. If you are being asked for an SoA, or you have been sent one and do not know what you are looking at, this is the page.
What an SoA contains, column by column
The shape is fixed by what the requirement asks for: which Annex A controls apply, the justification for including them, whether they are implemented, and the justification for excluding the ones you left out.
| Column | What it holds | What a reader gets from it |
|---|---|---|
| The control | Every Annex A control, by reference and name | All 93 of them in ISO/IEC 27001:2022. A list with gaps in the numbering is the first thing to notice. |
| Applicable? | Yes or no, for each one | The count of exclusions tells you how hard the organisation thought. Nought exclusions and ninety-three exclusions are both suspicious for opposite reasons. |
| Justification for inclusion | Why this control is necessary here | Should trace back to the risk assessment or to a legal, contractual or regulatory requirement — not to “it is in Annex A”. |
| Justification for exclusion | Why a control that is not applied is not applied | The column people under-do. “N/A” is a conclusion, not a reason, and it is not a justification on its own. |
| Implemented? | Whether the control is actually in place now | An SoA where everything is applicable and everything is implemented, with no dates and no owners, is a document written for the auditor rather than for the organisation. |
Read that table from the right-hand column and a useful thing becomes visible: four of the five columns are facts and one is reasoning. The reasoning column is the document. Everything else can be generated from a template.
The same diagram as a table
| Theme | Reference | Controls | Covers |
|---|---|---|---|
| Organisational | A.5 | 37 | Policies, supplier relationships, incident management, legal and contractual requirements, and the whole of how the ISMS is governed. |
| People | A.6 | 8 | Screening, terms of employment, awareness, disciplinary process, responsibilities after employment ends, and remote working. |
| Physical | A.7 | 14 | Perimeters, entry, equipment siting, clear desk and screen, secure disposal, and physical security monitoring. |
| Technological | A.8 | 34 | Endpoints, access rights, cryptography, logging, secure development and the other technical controls. |
| ISO/IEC 27001:2022 total | 93 | Four themes | |
| ISO/IEC 27001:2013 total | 114 | 14 clauses, A.5 to A.18. Withdrawn. | |
What clause 6.1.3 d) says, word for word
The requirement is clause 6.1.3 d) of ISO/IEC 27001:2022, inside the risk treatment clause. We quote it from the standard's official preview, which reproduces clauses 1 to 6.3 in full. The organisation shall define and apply a risk treatment process to:
c) “compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted”
d) “produce a Statement of Applicability that contains: the necessary controls (see 6.1.3 b) and c)); justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the Annex A controls”
ISO/IEC 27001:2022, clause 6.1.3, quoted verbatim
Two of the notes to that clause settle arguments that come up in every SoA review. “Organizations can design controls as required, or identify them from any source.” And: “The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.” Annex A is the checklist you compare against, not the limit of what you may include.
The clause number is corroborated by ISO/IEC 27006:2015/Amd 1:2020, the ISO/IEC document on certifying ISMSs, which refers to “the organization’s Statement of Applicability in accordance with ISO/IEC 27001:2013, 6.1.3 d)” — naming the 2013 edition because that is the one it amends. The requirement sits at the same clause in both editions.
The rule on certificates that almost nobody knows
From the same document, and this one is worth the whole page if you do supplier assurance:
“The certification documents may reference national and international standards as source(s) of control set for controls that are determined as necessary in the organization’s Statement of Applicability … The reference on the certification documents shall be clearly stated as being only a control set source for controls applied in the Statement of Applicability and not a certification thereof.”
ISO/IEC 27006:2015/Amd 1:2020, 8.2.1, quoted verbatim
In plain terms: a certificate may name another standard as a source of controls that the organisation selected in its Statement of Applicability, and when it does, it must say clearly that this is what the reference means — not that the organisation is certified to that other standard.
So if a supplier's ISO 27001 certificate carries the name of a second framework and somebody reads it as two certifications, the certificate is required to prevent exactly that reading. If it does not, that is a question for the certification body. And if the supplier is presenting it as two certifications, the SoA is where you find out which controls were actually taken.
Exclusions: the column that produces findings
An exclusion is legitimate. The standard expects you to select, and selecting means leaving things out. What is not legitimate is a conclusion with no reasoning behind it, and “N/A” is a conclusion.
The table below is our judgement, not a rule — no source says these exclusions are right or wrong. It is a list of exclusions and what decides them.
| The exclusion | Does it hold? | What decides it |
|---|---|---|
| Physical controls, because the company is fully remote | Weak as stated | Homes and devices are premises for this purpose. Equipment siting, clear desk and screen and secure disposal all have a remote answer. Excluding the specific controls with stated reasoning is fine; excluding the theme because there is no office is the finding. |
| Development controls, because the company buys all its software | Can hold | If nothing is developed inside the scope, secure development controls have nothing to attach to. Say that, and say who would notice if it changed. |
| Cloud controls, because everything is on-premises | Holds only if true | Check the whole estate first. One SaaS tool inside the scope brings the cloud control back. |
| Supplier controls, because there are no suppliers | Weak as stated | Any cloud service, IT support firm or payroll provider inside the scope is a supplier. Check before excluding. |
| A control, because “it is covered by another control” | Depends entirely on the sentence after it | A legitimate and common reason. It needs the other control named, so an auditor can follow it rather than take it on trust. |
The test to apply to your own exclusions
Read the justification aloud and ask whether it would still make sense to somebody who does not work here. “Not applicable” fails. “No software is developed within the certified scope; the scope covers the hosted platform only, and all application code is supplied by [X] under the supplier controls” passes, because it can be checked.
Reading somebody else's SoA
If you have been sent one as part of supplier assurance, you are looking for four things, in this order.
1. Does the row count match the edition?
93 rows for ISO/IEC 27001:2022. 114 rows means the document was written against the withdrawn ISO/IEC 27001:2013, whose certificates expired on 31 October 2025. This is the fastest single check in supplier assurance and it takes one glance. The same check on their certificate takes another.
2. What did they exclude, and is the reason checkable?
Go to the exclusions first, not the inclusions. The inclusions tell you what everybody does. The exclusions tell you what this organisation decided it did not need, and the quality of that reasoning is a reliable proxy for whether the management system is real.
3. Do the justifications trace to anything?
A justification that points at a risk, a contract or a legal obligation can be followed. One that restates the control title cannot. You are not auditing them — you are working out whether somebody thought about this.
4. Does it cover what you buy?
An SoA belongs to a scope, and the scope is on the certificate. If the certificate's scope does not cover the service you are buying, the SoA does not describe the thing you are buying either. The terminology page covers what scope means on a certificate and why it is the field to read first.
We do not sell SoA templates, toolkits or consultancy, and the enquiry form below is the only thing on this page we accept payment for — a fixed fee per enquiry, agreed in advance, unchanged by what you decide. Which is why this page can say that you may not need help writing this document, and that if you do, it is help with the reasoning rather than the spreadsheet.
Writing your own: what actually takes the time
The spreadsheet is an afternoon
A toolkit will give you one with 93 rows pre-filled, and that is genuinely useful as a starting structure. Nobody should be typing out Annex A by hand, and the structure is not where the value is.
The justifications are the work, and they are not delegable
Each justification is a decision about your organisation that somebody has to make and own. A consultancy can run the workshops, draft the wording and tell you when a justification will not survive an auditor. It cannot decide your risk appetite, and an SoA written entirely by somebody who does not work for you will read like one.
Do it after the risk assessment, not instead of it
The sequence the standard sets out runs risk assessment → risk treatment → compare the result against Annex A. Filling in the SoA first and reverse-engineering a risk assessment to match it is a recognisable pattern and it inverts the requirement. It also produces the version of this document that applies everything, because without a risk assessment there is no basis on which to exclude anything.
The failure mode
A document where every justification is a rephrasing of the control title. It passes a word count and fails the first question at Stage 2, which will be “why?”. If you want one test before the audit, hand three rows to somebody in another team and ask them what decision was made and why.
Where this sits in the rest of it
- ISO 27001 checklist
- ISO 27001 vs ISO 27002
- The Annex A controls
- The certification process
- Certified, compliant, accredited
- Checking a supplier's certificate
- What certification costs
- What a consultant can and cannot do
Common questions
What is a Statement of Applicability?
The document that connects your risk assessment to Annex A. For each Annex A control it records whether the control applies to you, the justification for that decision, and whether it is implemented — including, crucially, the justification for the controls you decided not to apply. The requirement is clause 6.1.3 d) of ISO/IEC 27001:2022: the organisation shall “produce a Statement of Applicability that contains: the necessary controls (see 6.1.3 b) and c)); justification for their inclusion; whether the necessary controls are implemented or not; and the justification for excluding any of the Annex A controls”. We quote it from the standard's official preview, which runs to clause 6.3.
Is the Statement of Applicability mandatory?
Yes. It is one of the documents an ISMS has to produce, and it is the first thing a Stage 1 auditor reaches for, because it is the only document that shows the reasoning behind the controls rather than the controls themselves. An ISMS without one is not ready to be audited.
How long should it be?
It has 93 rows in the ISO/IEC 27001:2022 edition, because Annex A has 93 controls. Length is not the variable; the justification column is. A one-line justification that names the risk or the obligation is worth more than a paragraph restating the control title, and auditors read a great many of both.
Can I just mark every control applicable and avoid the exclusion problem?
You can, and it can cost more than it saves. Applying all 93 without reasoning is itself a finding — it says the risk assessment did not drive the selection, which is the requirement. It also commits you to evidencing controls you did not need, every year, for as long as you hold the certificate.
Should we send our SoA to a customer who asks for it?
That is a commercial decision and worth taking deliberately, because the document is a fairly complete map of what you do and do not do about security. Many organisations share a redacted version, or share the control and applicability columns without the detailed justifications. What is worth knowing is why the customer is asking: an SoA answers questions a certificate cannot, which is why sophisticated buyers ask for it.
Our certificate mentions another standard. Does that mean we are certified to it?
No, and there is an explicit rule about this. ISO/IEC 27006:2015/Amd 1:2020 provides that where certification documents reference other standards as a source of controls used in the Statement of Applicability, that reference “shall be clearly stated as being only a control set source … and not a certification thereof”. So a named standard on a certificate can mean “we borrowed controls from this” rather than “we are certified to this”, and the certificate is required to make that distinction clear.
Does the SoA change when the standard changes?
It has to. The ISO/IEC 27001:2022 edition has 93 controls against 114 in the withdrawn ISO/IEC 27001:2013, and the numbering changed as well as the count. An SoA with 114 rows is an SoA against an edition whose certificates expired on 31 October 2025.
Who should write it?
Whoever can answer “why?” for each row, which may not be one person. The control owners supply the justification and the implementation status; somebody has to own the document itself. A consultancy can facilitate it and draft it, and the justifications still have to reflect your decisions — an SoA that reads like a template is transparently one, and it invites exactly the questions you least want at Stage 2.
Sources cited on this page
- ISO/IEC 27001:2022, official preview (clauses 1 to 6.3 and contents), read first-hand
- ISO/IEC 27006:2015/Amd 1:2020, Requirements for bodies providing audit and certification of information security management systems — Amendment 1
- ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements
- ISO/IEC 27002:2022, Information security controls
- BS EN ISO/IEC 17021-1:2015, clause 5.2 (Management of impartiality), full text
- IAF MD 26:2023, Transition requirements for ISO/IEC 27001:2022
Every figure above was read from the source it is attributed to on 20 September 2026. Figures that are our own arithmetic rather than a published rule are labelled as estimates wherever they appear. How we check this.
Stuck on the justifications rather than the spreadsheet?
Say where you are and what triggered this. That is the part a consultancy can genuinely shorten.
Your enquiry is ready to send
Here is what happens after you submit:
- We pass your answers only to ISO 27001 consultancies taking enquiries for your sector, when one is.
- No more than three may contact you, and only using the details you gave.
- You decide who, if anyone, you speak to. You are committed to nothing.
We are not a certification body and cannot issue, arrange or influence a certificate. Only a UKAS-accredited certification body can do that, and you appoint it yourself.