Of all the documents produced for an ISMS, the Statement of Applicability (SoA) is the one auditors open first and keep returning to. Procedures and registers get sampled; the SoA gets read end to end, because everything they ask afterwards starts from it.
Despite that, in practice it is often treated as "filling in 93 rows of a spreadsheet," submitted with template wording copied verbatim. The result is being asked "this control is marked applicable — how do you actually operate it?" with no answer, or being asked to explain an exclusion whose stated reason is simply "not applicable."
This article is a practical guide to producing an SoA that is consistent with your risk assessment: column structure, the right level of detail, how to justify exclusions, and when to update it.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual document preparation on those.
What the SoA Is
The SoA is documented information required by clause 6.1.3 (information security risk treatment). What it must contain reduces to four things:
- The controls determined to be necessary for risk treatment
- The justification for including them
- Whether each is implemented or not
- The justification for excluding any Annex A control
So the SoA is not a control inventory. It is a single document explaining what your organisation judged necessary, why, and how far you have got.
The 2022 Annex A arranges 93 controls into four themes, and the SoA must take a position on all 93.
| Theme | Controls | Coverage |
|---|---|---|
| Organizational (A.5) | 37 | Policies, roles, asset management, access control policy, supplier management, incident management, continuity, legal compliance |
| People (A.6) | 8 | Screening, terms of employment, awareness, disciplinary process, post-employment duties, confidentiality, remote working, reporting |
| Physical (A.7) | 14 | Perimeters, entry controls, working areas, equipment, cabling, maintenance, clear desk, media disposal |
| Technological (A.8) | 34 | Endpoints, privileged access, authentication, cryptography, backup, logging, monitoring, networks, secure development, change management, test data |
See Annex A 2022: 93 Controls Across Four Themes, Reading the 37 Organizational Controls, and Reading the 34 Technological Controls. For the overview, What Is an ISMS.
There is no duty to implement all 93
To state it plainly: you are not obliged to implement all 93 controls. You determine what is necessary from your risk assessment and exclude the rest with stated reasons.
But exclusion is only available where you can explain that the control does not apply to you. "We have not got to it yet" is not an exclusion reason — that control is applicable, and the implementation column should say it is not yet implemented, with a plan.
Linking to Risk Assessment Results
The 2022 edition is specific about the order in which controls are determined:
- Determine the controls necessary to implement the chosen risk treatment options
- Compare those controls against Annex A to verify that no necessary control has been omitted
- Produce the SoA
You do not pick from Annex A; you decide what you need and use Annex A as a completeness check. In practice people work with Annex A open, but the records must show "risk first, control second."
The simplest way to hold that link is cross-reference columns in both documents.
| Document | Column to add | Content |
|---|---|---|
| Risk assessment table | Applied controls | Control references adopted for that risk (A.5.1, A.8.9, …) |
| SoA | Related risk IDs | The risk identifiers that made this control necessary |
With those two columns, "what made this control necessary?" is answered by pointing at a risk row. Without them, the SoA looks like a copied template.
See Risk Assessment Method and Risk Treatment and Acceptance. The clauses this builds on are covered in Clause 4: Context, Clause 5: Leadership, and Clause 6: Planning.
A Worked Column Structure
The standard prescribes no format. A structure that satisfies the four required elements and works well in an audit looks roughly like this.
| Column | Content | Example |
|---|---|---|
| Control reference | A.5.1 – A.8.34 | A.8.9 |
| Control name | The Annex A name (your own translation is fine) | Configuration management |
| Applicable / excluded | Binary | Applicable |
| Justification for inclusion or exclusion | Why it is needed, or why it is not | Configuration change in the cloud production environment is a primary risk source; detecting unintended change is required |
| Related risk IDs | Rows in the risk assessment | R-012, R-018 |
| Implementation status | Implemented / partially / not implemented | Partially |
| How it is operated | One or two sentences | Configuration managed as code; drift detection runs daily; detections raise a change ticket |
| Related documents and records | Where the evidence lives | Information Security Management Procedure §7; change ticket list |
| Plan if not implemented | Deadline and owner | Extend drift detection to staging by December 2026 (IT) |
| Last updated | For version control | 2026-09-14 |
The "how it is operated" column carries the most value. Even one or two sentences tell the auditor which records to ask for. Left blank, you will be explaining from scratch verbally.
How much detail
Not every row needs prose.
| Nature of the control | Detail level | Examples |
|---|---|---|
| Central to your risk profile | Detailed — method and where records live | Access control, logging, cryptography, supplier management, backup |
| Covered by ordinary operation | One sentence | Clear desk, confidentiality agreements |
| Excluded | Specific — the reason it does not apply must be readable | Secure development controls where no development occurs |
Justifying Exclusions
Exclusion wording drives more audit dialogue than anything else in the document. "Not applicable" is not a justification.
A justification derives the conclusion from facts about your scope, your business, and the assets you handle.
| Control example | Weak reason | Reason that holds |
|---|---|---|
| Physical entry controls (no own office) | Not applicable | Scope covers only fully remote staff; the organisation holds no physical facilities of its own. All business data resides in cloud services and no physical media are handled |
| Software development controls | We do not develop | Work in scope is limited to selecting and operating SaaS; no in-house development or modification occurs, so the process the control applies to does not exist |
| Media disposal | We are paperless | Paper and removable media are not used; their use is prohibited in the Information Security Management Procedure §9, and bringing them in or out is checked under the entry procedure |
| Separation of development and production | We only have one environment | (Not justifiable. Lack of separation is itself a risk; mark it applicable and explain risk acceptance or a compensating control) |
That last row is the lesson. "We cannot do it, so we excluded it" does not work. Mark it applicable, record it as not implemented, and put it in the risk treatment plan. Open items are not automatically nonconformities: known, planned, and consciously accepted is a managed state.
Also check that every exclusion is consistent with your scope definition. Writing "we hold no facilities" while the scope statement names a head office collapses on contact. See Defining ISMS Scope.
Why It Is the Most-Read Document
The SoA matters in audit because it functions as the table of contents for your ISMS. An auditor has limited time to understand an organisation; the SoA tells them what you treat as important and where you are weak.
| Audit moment | How the SoA is used |
|---|---|
| Stage 1 (document review) | Check consistency with the risk assessment, the validity of exclusions, alignment with scope. Contradictions here set the focus for stage 2 |
| Stage 2 sampling | Pick several controls marked "implemented" and check the records, looking for divergence from what is written |
| Internal audit coverage | Starts the question "are all applicable controls covered by your internal audit?" |
| Surveillance audits | Check what changed since last time — applicability changes, implementation progress |
Anything marked "implemented" must be backed by records. Writing more optimistically than reality always surfaces in stage 2. Using "partially implemented" honestly is the safest position.
See What Stage 1 Audits Examine, What Stage 2 Audits Examine, Common Nonconformities, and, for audit coverage, Clause 9: Performance Evaluation.
Should you include attributes?
The 2022 Annex A introduces attributes for each control (control type, information security properties, cybersecurity concepts, operational capabilities, security domains). Attributes are optional; there is no obligation to add attribute columns to the SoA.
They earn their place when you want to:
- Classify controls as preventive, detective, or corrective, and see whether detection is under-represented
- Show executives how coverage distributes across confidentiality, integrity, and availability
- Map to another framework such as the NIST CSF
For a first certification with limited capacity, leaving them out is a reasonable decision. See Transitioning to ISO/IEC 27001:2022.
Updating and Version Control
The SoA is not write-once. It is expected to track changes in risk. Defining update triggers in advance makes surveillance audits easier.
| Trigger | Typical change |
|---|---|
| Periodic risk assessment | Implementation status updates, new risk IDs |
| Scope change (sites, business lines, subsidiaries) | Previously excluded controls becoming applicable, or the reverse |
| New service or technology | Changed status for related technological controls |
| Serious incident | Operating method changed by corrective action |
| Supplier change | Updated supplier management methods |
| Revised laws or guidelines | Updated compliance-related wording |
| Completion of a planned item | "Not implemented" becoming "implemented" |
Keep revision date, author, approver, and a summary of what changed. Being able to see what moved turns "explain the differences since last year" into a few minutes' work.
See Clause 7: Support, ISMS Document Structure, and Clause 8: Operation.
Healthcare-Specific Points
State that you handle medical information in the inclusion reason
For access control, cryptography, logging, backup, and supplier management, writing "because medical information and special care-required personal information are handled" into the justification makes the strictness of your operation legible at a glance — and the same text answers customer check sheets.
Reflect three-ministry guideline requirements in the method column
For services sold to hospitals, guideline-derived requirements (authenticity, readability and preservation of records, control of remote maintenance, external storage conditions) should already shape how controls operate. Adding a line in the method column mapping to the guidelines makes the SoA usable in both the certification audit and customer audits. See Integrating ISMS Documents with the Three-Ministry Guidelines and Japan's Three-Ministry Guidelines.
Write the responsibility split for cloud controls
For controls new in 2022 such as A.5.23 (information security for use of cloud services), separating what you operate from what the provider operates matches reality. See Shared Responsibility in AI EMR Security Design.
Exclusion decisions depend on your business model
A healthcare company that outsources development must decide between "excluded because we do not develop" and "applicable, imposed on the supplier." If you impose it on a supplier, it is applicable, not excluded — record the method as "specified as a security requirement in the outsourcing contract and verified annually." See Supplier Security Management.
Conclusion
- The SoA must carry four elements: necessary controls, justification for inclusion, implementation status, and justification for exclusion. It is not an inventory
- There is no duty to implement all 93 — but exclusion requires explaining that the control does not apply. "Not yet done" is not an exclusion reason
- The order is risk first, control second. Annex A is a completeness check. Cross-referencing risk IDs makes the document defensible
- Justify exclusions from facts about scope, business, and assets — never "not applicable" alone
- Do not overstate implementation. Honest use of "partially implemented" is safest
- Attribute columns are optional; omitting them on a first certification is reasonable
- Define update triggers in advance and keep a revision history that explains the differences
Pottech supports ISMS certification with a focus on healthcare. We supply the SoA template and then work through the linkage to your risk assessment and the defensibility of each exclusion with you. We also lead dealings with the certification body, so your team can concentrate on decisions.
See ISMS Certification Support for scope and pricing, or contact us — a review of an SoA you have already drafted is a perfectly good place to start.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: control names and numbering, and interpretation of requirements, are governed by the standard itself (JIS Q 27001:2023 / ISO/IEC 27001:2022 Annex A). Expectations on SoA format and detail vary between certification bodies.