How to Write Your ISO 27001 Statement of Applicability (SoA)
The Statement of Applicability is the central ISMS document an ISO 27001 auditor reaches for first. It records every one of the 93 Annex A:2022 controls, whether each applies, why, and where it stands — and it follows directly from your risk assessment and treatment plan under clause 6.1.3.
Reviewed by Dor Israel, Founder · Updated
Free: The ISO 27001:2022 Starter Checklist (9 steps) →
What the Statement of Applicability actually is
The Statement of Applicability (SoA) is a single document that lists every control in Annex A of ISO/IEC 27001:2022 and states, for each one, whether it applies to your organization, the justification for including or excluding it, and — in practice — its implementation status. It is not an optional artifact.
Clause 6.1.3 d) of the standard names the SoA explicitly as documented information you must produce and maintain, which makes it one of a small number of documents ISO 27001 requires by name. If your information security management system (ISMS) were a map, the SoA would be the legend: it ties your assessed risks to the specific controls you have decided to operate.
Annex A:2022 contains 93 controls grouped into four themes — Organizational (A.5, 37 controls), People (A.6, 8 controls), Physical (A.7, 14 controls), and Technological (A.8, 34 controls). The SoA walks through all 93.
That completeness is the point: an auditor opening your SoA should be able to see, control by control, that you considered the entire reference set and made a deliberate decision about each, rather than cherry-picking the ones you found convenient.
It helps to be clear about what the SoA is not. It is not your risk assessment, and it is not your risk treatment plan — those are separate, upstream documents under clauses 6.1.2 and 6.1.3.
The SoA is the consolidated statement that results from them. It is also not a place to record only the controls you implemented; it must account for every Annex A control, including those you legitimately exclude, with a defensible reason for each exclusion.
Why the SoA follows from risk assessment and treatment
The SoA does not stand on its own — it is the output of a chain. ISO/IEC 27001:2022 clause 6.1.2 requires you to assess your information security risks; clause 6.1.3 requires you to treat them.
Treatment means choosing, for each risk you decided to act on, how you will modify, avoid, share, or retain it, and then determining the controls necessary to carry out those decisions. Only after you have determined the controls your treatment requires do you compare that set against Annex A.
The standard uses Annex A as a completeness check — a reference list to confirm you have not overlooked a necessary control — not as a menu you shop from in isolation.
This ordering matters because it shapes how you justify each line of the SoA. A control is "applicable" because your risk assessment and treatment decisions call for it, or because a legal, regulatory, or contractual obligation requires it — not simply because it appears in the standard.
A control is "excluded" when no risk you identified and no obligation you carry depends on it, and you can say why. A classic defensible exclusion is in the Technological theme: an organization that performs no software development can reasonably exclude the secure-development controls (around A.8.25 to A.8.30), provided that is genuinely true and stays true.
Get the direction of travel right and the SoA writes itself as a summary of work you have already done. Get it backward — picking controls off Annex A first and reverse-engineering risks to fit — and an experienced auditor will usually notice. Clause 6.1.3 also requires risk owners to approve the treatment plan and accept the residual risks that remain; that sign-off is what authorizes the program the SoA describes.
Building the SoA, step by step
Start with a workbook that already lists all 93 Annex A:2022 controls, each tagged with its theme, so you are reviewing a complete set rather than transcribing the standard by hand. For every control, you will resolve a small number of fields: the control ID and title, its theme, whether it is applicable (Yes/No), the justification for inclusion or exclusion, the implementation status, and a reference to the documents or evidence that demonstrate it.
Those columns are the working spine of a usable SoA.
Work through the controls in order. For each, decide applicability against your risk assessment, treatment plan, and obligations, then write a justification specific to your organization — "required to mitigate the access-control risks identified in our risk register" is defensible; a generic restatement of the control title is not.
Most organizations find that nearly all 93 controls apply to them; broad exclusions are a red flag unless the reason is concrete and verifiable. Set the implementation status honestly: auditors expect a mix, and a status of "Planned" backed by a dated implementation plan is acceptable at a Stage 1 audit, where the assessor is largely checking documentation and readiness.
Then connect each applicable control to proof. In the evidence column, reference the relevant policy or procedure and, where it exists, the record that shows the control actually operates — a log, an access review, a ticket, a signed acknowledgment.
This is where the SoA stops being a list of intentions and becomes a navigable index into your ISMS. Finally, version and date it.
Auditors ask for SoA history, and the standard treats it as documented information you control, so update it after every risk assessment cycle and whenever a significant change alters which controls you need.
Common mistakes that cost you at audit
The most frequent failure is excluding controls to reduce the workload rather than because they genuinely do not apply. Each exclusion needs a justification that would survive a follow-up question.
Excluding the physical-security controls because you are fully remote can be reasonable — but only if you truly hold no physical assets and process nothing on premises, and you should expect to be asked. Excluding a control simply because implementing it is inconvenient is not a justification; it is a finding waiting to happen.
A second common mistake is leaving the placeholder justifications that come with any template. Generic wording such as "applies to company systems" tells an auditor you populated a spreadsheet but did not connect it to your environment.
The justification should trace back to a specific risk in your register or a specific obligation you carry. A related error is an SoA that disagrees with the rest of the ISMS — controls marked applicable with no supporting policy, or policies that describe controls the SoA omits.
Internal consistency is exactly what an auditor samples for.
Third, treating the SoA as a one-time deliverable. It is living documented information.
When you adopt a new system, take on a major supplier, change what you process, or respond to a serious incident, your control needs can shift — and an SoA that still reflects last year's environment undermines the credibility of the whole management system. Finally, conflating editions: an SoA built on the 2013 structure (114 controls across 14 domains, A.5 to A.18) is out of date.
Certification audits are conducted against ISO/IEC 27001:2022, so your SoA must reflect the 93-control, four-theme Annex A. Confirm specifics against the official 2022 text rather than older summaries.
How auditors read your SoA
For a certification body, the SoA is often the first document opened and the spine of the rest of the audit. It tells the auditor what you claim to be doing, and it becomes the worklist they sample against.
They will look for completeness — that all 93 controls are accounted for — and then probe the seams: an exclusion with a thin justification, an "implemented" status with no evidence behind it, or an applicable control whose referenced policy does not actually exist.
A typical line of questioning starts at the SoA and moves outward. The auditor picks a control marked applicable and implemented, follows your evidence reference to the policy, and then asks to see the records that prove the control operates in practice — the access review that was actually performed, the log that was actually kept, the supplier assessment that was actually completed.
The SoA is the index; the audit is the auditor checking that the index points to something real. This is why the evidence column is not busywork: it is the path the auditor will walk.
The relationship runs the other way too. Because the SoA is required by clause 6.1.3 d) and is referenced throughout the audit, an SoA that is accurate, specific, internally consistent, and current does a great deal to set a confident tone for the whole assessment. A vague or stale one signals that the management system may be more paper than practice — and invites deeper sampling.
Using a toolkit to get a usable starting point
Building an SoA from a blank page is slow and error-prone: you have to transcribe all 93 Annex A:2022 controls, assign each to the right theme, and lay out columns for applicability, justification, implementation status, and evidence before you can do any of the actual thinking. That setup work adds nothing unique to your organization, which is exactly the kind of task a documentation toolkit is meant to remove.
The ComplianceDocs ISO 27001 toolkits include a 93-control Statement of Applicability workbook pre-populated with every Annex A:2022 control, its theme, and starter justification wording, alongside a matching risk register and an audit evidence checklist — and the policies the SoA's evidence column points back to. That gives you an editable starting point: a complete, correctly structured SoA you adapt to your environment, rather than a structure you build from scratch.
It is the documentation layer, designed to speed readiness.
What the toolkit cannot do is the judgment that makes the SoA valid. The applicability decisions, the organization-specific justifications, the honest implementation statuses, and the evidence that proves each control operates all have to reflect your actual ISMS — and only your organization can supply them.
Just as important, no template, workbook, or document set makes an organization "ISO 27001 certified." Certification is issued only by an accredited certification body after it audits a working management system.
A toolkit accelerates and structures the documentation; the certification, and the operating controls behind it, remain yours to earn. (Any cost or time references here are illustrative estimates, not quotes; actual figures vary by organization, scope, and certification body.)
Which Annex A controls a policy set actually names
Everything above describes how to build a Statement of Applicability. This section is a measurement of the documents ComplianceDocs sells, published because it is not something a buyer can check from the outside.
Every Word document in a ComplianceDocs toolkit carries a line naming the provisions it was written against. For ISO 27001 that line lists Annex A control identifiers. Read across all 24 documents in the ISO 27001 Complete Toolkit, 66 of the 93 Annex A controls in ISO/IEC 27001:2022 are named by at least one document and 27 are not. Measured 2026-09-02.
What that measure is, precisely: a control counts as named when its identifier appears on that line. Document body text was not scanned, so a control discussed inside a document but left off its line counts as not named — every figure in this section is a floor rather than a total. Named is not the same as covered, and none of these counts says anything about what your organization has to document. That is settled by your risk assessment and your own Statement of Applicability, which is the subject of the rest of this page.
A control that no document names is not missing from the toolkit. The same edition ships a Statement of Applicability workbook with one row for each of the 93 controls, so those controls arrive as rows you complete yourself rather than as drafted policy text. This section measures the Word documents only.
The 27 controls that no document in the ISO 27001 Complete Toolkit names, by theme:
- Organizational: A.5.5, A.5.6, A.5.8, A.5.31, A.5.32, A.5.35, A.5.36, A.5.37
- Physical: A.7.3, A.7.5, A.7.6, A.7.11, A.7.12, A.7.13
- Technological: A.8.4, A.8.6, A.8.7, A.8.9, A.8.11, A.8.12, A.8.18, A.8.20, A.8.21, A.8.22, A.8.23, A.8.30, A.8.34
They are listed as identifiers because ISO/IEC control titles are copyrighted text this site does not reproduce, and deliberately without any characterization of what kind of control each one is.
By Annex A theme
Annex A groups its controls into four themes. Splitting the same measurement across them shows where the named controls concentrate. All 8 People controls are named; the Physical and Technological themes hold most of the not-named list.
Counts, not shares — a share would invite a reading about proportional completeness that a floor measurement cannot support.
Annex A controls named on a document's Addresses line, by theme (ISO 27001 Complete Toolkit, 24 documents, 2026-09-02)
| Annex A theme | Controls in the theme | Named by at least one document | Not named by any document |
|---|---|---|---|
| Organizational | 37 | 29 | 8 |
| People | 8 | 8 | 0 |
| Physical | 14 | 8 | 6 |
| Technological | 34 | 21 | 13 |
The theme totals (37 / 8 / 14 / 34) are the published structure of ISO/IEC 27001:2022 Annex A and are typed, not measured — they are the only figures in this section that do not come from the documents. Every other cell is computed from the shipped files.
Which document names how many controls
The references are not spread evenly. Counting one control identifier on one document's line as one reference, the 24 documents carry 70 Annex A references between them, and the 7 documents that name five or more controls carry 43 of those. The median document names 2 controls. 7 documents name exactly one control. 2 documents name none: ISMS Internal Audit Procedure (Clause 9.2) and Management Review Procedure (Clause 9.3) — both point at management-system clauses instead, which are reported separately below.
4 controls are named by two documents rather than one (A.5.10, A.8.19, A.7.10, A.7.14), which is why the reference count runs above the 66 distinct controls named.
Annex A controls named on each document's Addresses line (ISO 27001 Complete Toolkit, 2026-09-02)
| Document | Annex A controls named | Count |
|---|---|---|
| Physical and Environmental Security Policy | A.7.1, A.7.2, A.7.4, A.7.7, A.7.8, A.7.9, A.7.10, A.7.14 | 8 |
| Access Control Policy | A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3, A.8.5 | 7 |
| Secure Development Policy | A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.31, A.8.33 | 7 |
| Information Security Incident Response Procedure | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.6.8 | 6 |
| Asset Management and Information Classification Policy | A.5.9, A.5.11, A.5.12, A.5.13, A.5.14 | 5 |
| Human Resources Security Policy | A.6.1, A.6.2, A.6.4, A.6.5, A.6.6 | 5 |
| Supplier and Cloud Services Security Policy | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 | 5 |
| Data Retention and Secure Disposal Policy | A.5.33, A.8.10, A.7.10, A.7.14 | 4 |
| Business Continuity and ICT Readiness Plan | A.5.29, A.5.30, A.8.14 | 3 |
| Logging and Monitoring Policy | A.8.15, A.8.16, A.8.17 | 3 |
| AI Acceptable Use Policy | A.5.10, A.8.19 | 2 |
| Information Security Policy | A.5.1, A.5.4 | 2 |
| Information Security Roles and Responsibilities | A.5.2, A.5.3 | 2 |
| Remote Working and Mobile Device Policy | A.6.7, A.8.1 | 2 |
| Vulnerability and Patch Management Procedure | A.8.8, A.8.19 | 2 |
| Acceptable Use Policy | A.5.10 | 1 |
| Backup and Recovery Policy | A.8.13 | 1 |
| Change Management Procedure | A.8.32 | 1 |
| Cryptographic Controls Policy | A.8.24 | 1 |
| Privacy and PII Protection Policy | A.5.34 | 1 |
| Risk Assessment and Treatment Procedure | A.5.7 | 1 |
| Security Awareness and Training Procedure | A.6.3 | 1 |
| ISMS Internal Audit Procedure | — | 0 |
| Management Review Procedure | — | 0 |
A count is the number of distinct Annex A identifiers on that document's own line. Management-system clause references are excluded from every count in this table and reported in their own section. Document names are as shipped in the toolkit.
Control by control: all 93 rows
The full crosswalk, for the ISO 27001 Complete Toolkit and the ISO 27001 Policy Pack — Core side by side. The Core pack names 53 of the 93 controls across its 16 documents; the 8 documents the Complete toolkit adds name 13 controls the Core pack does not (A.5.33, A.5.34, A.8.8, A.8.10, A.8.24, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.31, A.8.32, A.8.33).
Not named means the identifier does not appear on any document's Addresses line in that edition. It does not mean the edition has nothing on the control — see the workbook note above. The same table is downloadable as a CSV below.
ISO/IEC 27001:2022 Annex A control-to-document crosswalk — ComplianceDocs ISO 27001 Complete Toolkit and ISO 27001 Policy Pack — Core (2026-09-02)
| Control | Theme | Named in the Complete toolkit (24 documents) | Named in the Core pack (16 documents) |
|---|---|---|---|
| A.5.1 | Organizational | Information Security Policy | Information Security Policy |
| A.5.2 | Organizational | Information Security Roles and Responsibilities | Information Security Roles and Responsibilities |
| A.5.3 | Organizational | Information Security Roles and Responsibilities | Information Security Roles and Responsibilities |
| A.5.4 | Organizational | Information Security Policy | Information Security Policy |
| A.5.5 | Organizational | Not named | Not named |
| A.5.6 | Organizational | Not named | Not named |
| A.5.7 | Organizational | Risk Assessment and Treatment Procedure | Risk Assessment and Treatment Procedure |
| A.5.8 | Organizational | Not named | Not named |
| A.5.9 | Organizational | Asset Management and Information Classification Policy | Asset Management and Information Classification Policy |
| A.5.10 | Organizational | Acceptable Use Policy; AI Acceptable Use Policy | Acceptable Use Policy; AI Acceptable Use Policy |
| A.5.11 | Organizational | Asset Management and Information Classification Policy | Asset Management and Information Classification Policy |
| A.5.12 | Organizational | Asset Management and Information Classification Policy | Asset Management and Information Classification Policy |
| A.5.13 | Organizational | Asset Management and Information Classification Policy | Asset Management and Information Classification Policy |
| A.5.14 | Organizational | Asset Management and Information Classification Policy | Asset Management and Information Classification Policy |
| A.5.15 | Organizational | Access Control Policy | Access Control Policy |
| A.5.16 | Organizational | Access Control Policy | Access Control Policy |
| A.5.17 | Organizational | Access Control Policy | Access Control Policy |
| A.5.18 | Organizational | Access Control Policy | Access Control Policy |
| A.5.19 | Organizational | Supplier and Cloud Services Security Policy | Supplier and Cloud Services Security Policy |
| A.5.20 | Organizational | Supplier and Cloud Services Security Policy | Supplier and Cloud Services Security Policy |
| A.5.21 | Organizational | Supplier and Cloud Services Security Policy | Supplier and Cloud Services Security Policy |
| A.5.22 | Organizational | Supplier and Cloud Services Security Policy | Supplier and Cloud Services Security Policy |
| A.5.23 | Organizational | Supplier and Cloud Services Security Policy | Supplier and Cloud Services Security Policy |
| A.5.24 | Organizational | Information Security Incident Response Procedure | Information Security Incident Response Procedure |
| A.5.25 | Organizational | Information Security Incident Response Procedure | Information Security Incident Response Procedure |
| A.5.26 | Organizational | Information Security Incident Response Procedure | Information Security Incident Response Procedure |
| A.5.27 | Organizational | Information Security Incident Response Procedure | Information Security Incident Response Procedure |
| A.5.28 | Organizational | Information Security Incident Response Procedure | Information Security Incident Response Procedure |
| A.5.29 | Organizational | Business Continuity and ICT Readiness Plan | Business Continuity and ICT Readiness Plan |
| A.5.30 | Organizational | Business Continuity and ICT Readiness Plan | Business Continuity and ICT Readiness Plan |
| A.5.31 | Organizational | Not named | Not named |
| A.5.32 | Organizational | Not named | Not named |
| A.5.33 | Organizational | Data Retention and Secure Disposal Policy | Not named |
| A.5.34 | Organizational | Privacy and PII Protection Policy | Not named |
| A.5.35 | Organizational | Not named | Not named |
| A.5.36 | Organizational | Not named | Not named |
| A.5.37 | Organizational | Not named | Not named |
| A.6.1 | People | Human Resources Security Policy | Human Resources Security Policy |
| A.6.2 | People | Human Resources Security Policy | Human Resources Security Policy |
| A.6.3 | People | Security Awareness and Training Procedure | Security Awareness and Training Procedure |
| A.6.4 | People | Human Resources Security Policy | Human Resources Security Policy |
| A.6.5 | People | Human Resources Security Policy | Human Resources Security Policy |
| A.6.6 | People | Human Resources Security Policy | Human Resources Security Policy |
| A.6.7 | People | Remote Working and Mobile Device Policy | Remote Working and Mobile Device Policy |
| A.6.8 | People | Information Security Incident Response Procedure | Information Security Incident Response Procedure |
| A.7.1 | Physical | Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.2 | Physical | Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.3 | Physical | Not named | Not named |
| A.7.4 | Physical | Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.5 | Physical | Not named | Not named |
| A.7.6 | Physical | Not named | Not named |
| A.7.7 | Physical | Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.8 | Physical | Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.9 | Physical | Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.10 | Physical | Data Retention and Secure Disposal Policy; Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.7.11 | Physical | Not named | Not named |
| A.7.12 | Physical | Not named | Not named |
| A.7.13 | Physical | Not named | Not named |
| A.7.14 | Physical | Data Retention and Secure Disposal Policy; Physical and Environmental Security Policy | Physical and Environmental Security Policy |
| A.8.1 | Technological | Remote Working and Mobile Device Policy | Remote Working and Mobile Device Policy |
| A.8.2 | Technological | Access Control Policy | Access Control Policy |
| A.8.3 | Technological | Access Control Policy | Access Control Policy |
| A.8.4 | Technological | Not named | Not named |
| A.8.5 | Technological | Access Control Policy | Access Control Policy |
| A.8.6 | Technological | Not named | Not named |
| A.8.7 | Technological | Not named | Not named |
| A.8.8 | Technological | Vulnerability and Patch Management Procedure | Not named |
| A.8.9 | Technological | Not named | Not named |
| A.8.10 | Technological | Data Retention and Secure Disposal Policy | Not named |
| A.8.11 | Technological | Not named | Not named |
| A.8.12 | Technological | Not named | Not named |
| A.8.13 | Technological | Backup and Recovery Policy | Backup and Recovery Policy |
| A.8.14 | Technological | Business Continuity and ICT Readiness Plan | Business Continuity and ICT Readiness Plan |
| A.8.15 | Technological | Logging and Monitoring Policy | Logging and Monitoring Policy |
| A.8.16 | Technological | Logging and Monitoring Policy | Logging and Monitoring Policy |
| A.8.17 | Technological | Logging and Monitoring Policy | Logging and Monitoring Policy |
| A.8.18 | Technological | Not named | Not named |
| A.8.19 | Technological | AI Acceptable Use Policy; Vulnerability and Patch Management Procedure | AI Acceptable Use Policy |
| A.8.20 | Technological | Not named | Not named |
| A.8.21 | Technological | Not named | Not named |
| A.8.22 | Technological | Not named | Not named |
| A.8.23 | Technological | Not named | Not named |
| A.8.24 | Technological | Cryptographic Controls Policy | Not named |
| A.8.25 | Technological | Secure Development Policy | Not named |
| A.8.26 | Technological | Secure Development Policy | Not named |
| A.8.27 | Technological | Secure Development Policy | Not named |
| A.8.28 | Technological | Secure Development Policy | Not named |
| A.8.29 | Technological | Secure Development Policy | Not named |
| A.8.30 | Technological | Not named | Not named |
| A.8.31 | Technological | Secure Development Policy | Not named |
| A.8.32 | Technological | Change Management Procedure | Not named |
| A.8.33 | Technological | Secure Development Policy | Not named |
| A.8.34 | Technological | Not named | Not named |
Control identifiers and themes only; ISO/IEC control titles are copyrighted text and are not reproduced here. Measured from the documents shipped in each edition, not inferred from one edition to the other.
Management-system clause references, counted separately
Some documents point at the management-system clauses in the body of ISO/IEC 27001 rather than at an Annex A control. Those references are reported here and are never added to any Annex A count on this page — the clauses are not part of the 93.
Management-system clause references on Addresses lines (ISO 27001 Complete Toolkit, 2026-09-02)
| Document | Clause reference | Annex A controls also named |
|---|---|---|
| Risk Assessment and Treatment Procedure | Clause 6.1.2, Clause 6.1.3 | 1 |
| ISMS Internal Audit Procedure | Clause 9.2 | 0 |
| Management Review Procedure | Clause 9.3 | 0 |
Reported separately so that a document naming no Annex A control is not read as a document mapped to nothing.
How this was measured, and what it is not
Measured from the self-declared "Addresses:" line of every Word document shipped in the ComplianceDocs all-access library. A control counts as named when its identifier appears on that line; document body text was not scanned, so every count is a floor. Figures describe the ComplianceDocs library only, and say nothing about what any standard requires an organization to document.
Scope and exclusions. Only the ISO 27001 editions were parsed for Annex A identifiers, selected by the catalog's framework field rather than by the shape of the identifier: the ISO 42001 toolkit reuses the same A.x.y numbering and twelve of its control strings fall inside the ISO 27001 range, so matching on pattern alone would silently merge two standards. Excel workbooks are excluded apart from the control-row count quoted above.
The four industry editions are excluded from this section: their physical security policy is a different document from the Core one and its control list differs, and whether that difference is intentional is an open question with the product, not something to publish a number on.
Freezing. The figures come from a snapshot of the shipped files, frozen to a dataset file that carries a fingerprint of the catalog's document counts, so the site's build fails if the catalog moves without the measurement being re-run. The snapshot this section describes is 1d5a217052de (261 documents, 676 provision references across every framework). One limitation stated plainly: an edit to an Addresses line that leaves document counts unchanged is invisible to that check, so the measurement is re-run whenever documents are edited, and the snapshot identifier changes visibly when it is.
What these numbers are not. They are not a survey, not a measurement of any other vendor's documents, and not a statement about what ISO/IEC 27001 requires an organization to document — this section quotes none of the standard's text and makes no claim about it. No template makes an organization certified or compliant on its own.
Charts, dataset and reuse
The charts and the underlying tabulated dataset on this page are published under CC BY 4.0: reuse them in your own article, report or deck, with attribution to ComplianceDocs — a link back to this page is the attribution form we ask for. The documents behind this tabulation are ComplianceDocs’ own; the license covers this tabulation, the CSV and these charts, not the documents themselves.
Dataset: Annex A control-to-document crosswalk (93 rows, two editions) (CSV; snapshot-dated, methodology above).
Cite this data
ComplianceDocs, “ComplianceDocs ISO 27001:2022 Annex A control-to-document crosswalk,” https://compliancedocshq.com/learn/iso-27001-statement-of-applicability. Measured from the shipped documents as described in the method note.
Embed a chart
Copy and paste — the snippet credits the source for you:
<a href="https://compliancedocshq.com/learn/iso-27001-statement-of-applicability"><img src="https://compliancedocshq.com/charts/iso-27001-annex-a-named-by-theme.svg" alt="Grouped bar chart of ISO/IEC 27001:2022 Annex A controls by theme, showing how many are named on a ComplianceDocs document's Addresses line and how many are not: Organizational 29 named of 37, People 8 of 8, Physical 8 of 14, Technological 21 of 34" width="720" style="max-width:100%;height:auto"></a> <p>Source: <a href="https://compliancedocshq.com/learn/iso-27001-statement-of-applicability">ComplianceDocs — How to Write Your ISO 27001 Statement of Applicability (SoA)</a></p>
Frequently asked questions
- Is the Statement of Applicability mandatory for ISO 27001?
- Yes. ISO/IEC 27001:2022 clause 6.1.3 d) names the Statement of Applicability explicitly as documented information you must produce and maintain, making it one of the few documents the standard requires by name. It must account for every one of the 93 Annex A controls, stating for each whether it applies and the justification for inclusion or exclusion. An auditor will expect to see it, and it is typically one of the first documents reviewed in a certification audit. There is no version of an ISO 27001 ISMS that legitimately omits the SoA.
- How many controls are in the SoA under ISO 27001:2022?
- The 2022 edition of Annex A contains 93 controls across four themes: Organizational (A.5, 37 controls), People (A.6, 8 controls), Physical (A.7, 14 controls), and Technological (A.8, 34 controls). Your SoA must address all 93, including the ones you exclude. This differs from the 2013 edition, which had 114 controls organized into 14 domains numbered A.5 to A.18. Because certification audits are conducted against ISO/IEC 27001:2022, an SoA built on the older 114-control structure is out of date.
- What is the difference between the risk treatment plan and the SoA?
- They are separate documents with different jobs, both arising from clause 6.1.3. The risk treatment plan decides what to do about each risk you chose to treat — modify, avoid, share, or retain it — and determines the controls those decisions require. The Statement of Applicability is the consolidated statement that results: it lists all 93 Annex A controls and records, for each, whether it applies, why, and its implementation status. In short, the treatment plan is where you make decisions; the SoA is where you account for those decisions against the full reference set of controls.
- Can I exclude controls from my Statement of Applicability?
- Yes, but every exclusion needs a defensible, specific justification, and an auditor may question it. A control is reasonably excluded when no risk you identified and no legal, regulatory, or contractual obligation requires it. A common example is excluding the secure-development controls (around A.8.25 to A.8.30) when your organization performs no software development — valid only if that is genuinely and durably true. Excluding a control because implementing it is inconvenient is not a justification, and broad exclusions across a whole theme tend to draw scrutiny.
- Does a pre-built SoA workbook make my organization ISO 27001 certified?
- No. A workbook gives you all 93 Annex A:2022 controls, correct themes, and a structure for applicability, justification, status, and evidence so you are not building from a blank page — but the applicability decisions, organization-specific justifications, honest statuses, and supporting evidence must reflect your real environment. ISO 27001 certification is issued only by an accredited certification body after it audits a working information security management system. A document set, on its own, cannot confer certification. A toolkit speeds and structures the documentation; the certification and the operating controls behind it remain yours to earn.
- How many ISO 27001 Annex A controls do the ComplianceDocs documents name?
- In the ISO 27001 Complete Toolkit, 66 of the 93 Annex A controls are named on the Addresses line of at least one of its 24 Word documents, and 27 are not; the ISO 27001 Policy Pack — Core names 53. Measured from the shipped documents on 2026-09-02. Named on the Addresses line is the measure — document body text was not scanned, so the figure is a floor, and it describes the ComplianceDocs library only.Related: ISO 27001 Complete Toolkit · ISO 27001 Policy Pack — Core
- Which Annex A controls are not named by any document in the toolkit?
- These 27, as of 2026-09-02: A.5.5, A.5.6, A.5.8, A.5.31, A.5.32, A.5.35, A.5.36, A.5.37, A.7.3, A.7.5, A.7.6, A.7.11, A.7.12, A.7.13, A.8.4, A.8.6, A.8.7, A.8.9, A.8.11, A.8.12, A.8.18, A.8.20, A.8.21, A.8.22, A.8.23, A.8.30, A.8.34. Each one still has a row in the Statement of Applicability workbook that ships with the toolkit, which lists all 93 controls, so they arrive as rows you complete rather than as drafted policy text. The list is identifiers only, without characterization.
- What does the Complete toolkit add over the Core pack, control by control?
- The 8 additional documents name 13 Annex A controls that no document in the Core pack names: A.5.33, A.5.34, A.8.8, A.8.10, A.8.24, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.31, A.8.32, A.8.33. They also bring the two management-system procedures that reference clauses rather than Annex A controls. Both editions ship the same 93-row Statement of Applicability workbook.Related: ISO 27001 Policy Pack — Core · ISO 27001 Complete Toolkit
- Can I reuse this crosswalk in my own article or gap analysis?
- Yes, under CC BY 4.0 with attribution to ComplianceDocs; a link to this page is the attribution we ask for. The full 93-row table is downloadable as a CSV in the dataset section below, along with the theme chart. It describes ComplianceDocs' own documents as of 2026-09-02 — not another vendor's, and not the standard.
Related guides: ISO/IEC 27001
Toolkits that help
ISO 27001 Policy Pack — Core
16 editable ISO/IEC 27001:2022 policies plus the full 93-control Statement of Applicability — everything a small business needs to start its ISMS.
ISO 27001 Complete Toolkit
All 24 policies and procedures plus the risk register, 93-control Statement of Applicability and audit evidence checklist.
Related articles
- How to Do an ISO 27001 Risk Assessment (Step by Step)
- How to Run an ISO 27001 Internal Audit (Clause 9.2)
- ISO 27001:2022 vs 2013: What Changed
- How to Do a HIPAA Security Risk Assessment (Step by Step)
- NIST CSF 2.0 Explained: The Six Functions and Where to Start
Get new templates and guides by email
An occasional email when we publish a new free template, guide, or dataset. Unsubscribe any time.