iso27001partnersThe Statement of Applicability, and how to read one
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. That is the question a certificate cannot answer.
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 the most common finding in this document. |
| 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 everything a reader tends to assume the standard is only about. |
| ISO/IEC 27001:2022 total | 93 | Four themes | |
| ISO/IEC 27001:2013 total | 114 | 14 clauses, A.5 to A.18. Withdrawn. | |
Where the clause number comes from, and what we could not read
The requirement sits at clause 6.1.3 d) of ISO/IEC 27001. We have not read that clause first-hand: the standard is paywalled and its publisher's site does not serve automated requests. So rather than quote a clause we have not opened, here is the document we did open — ISO/IEC 27006:2015/Amd 1:2020, which is an ISO/IEC document about certifying ISMSs, referring to:
“the organisation’s Statement of Applicability in accordance with ISO/IEC 27001:2013, 6.1.3 d)”
Note the edition in that sentence. The amendment names ISO/IEC 27001:2013, because that is the edition it amends. The requirement sits at the same clause in ISO/IEC 27001:2022, and we are telling you which document our citation came from rather than implying we read the current standard. A site that spends a page telling readers to check which edition a number belongs to does not get to be loose with its own.
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 the ones that come up most and what usually decides them.
| The exclusion | Does it hold? | What decides it |
|---|---|---|
| Physical controls, because the company is fully remote | Usually wrong 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 | Usually holds | 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 if true, and it rarely is | Check the whole estate first. One SaaS tool inside the scope brings the cloud control back. |
| Supplier controls, because there are no suppliers | Almost never holds | Almost every organisation has suppliers inside its scope. This exclusion usually means nobody has looked. |
| 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 where supplier assurance most often fails quietly.
We do not sell SoA templates, toolkits or consultancy, and the enquiry form below is the only thing on this page we are paid for — a fixed fee per enquiry, agreed in advance, unchanged by what you decide. Which is why this page can say that most organisations do not need help writing this document, and that the ones who do need 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
- 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 sits at clause 6.1.3 d) of ISO/IEC 27001. We have not read that clause first-hand, because the standard is paywalled; the clause number here is taken from ISO/IEC 27006:2015/Amd 1:2020, an ISO/IEC document that refers to “the organisation’s Statement of Applicability in accordance with ISO/IEC 27001:2013, 6.1.3 d)”.
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 is usually the more expensive mistake. 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 is usually not 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 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:
- Your answers go to ISO 27001 consultancies that advertise for your sector.
- No more than three of them may contact you, 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.