An ISO 27001 Statement of Applicability is mandatory, but the difficult part is not creating a spreadsheet. That bit is usually manageable. The difficult part is documenting control decisions so they are tied to risk treatment, truthful about implementation, and supported by evidence.
ISO/IEC 27001:2022 Clause 6.1.3 requires documented information that identifies the necessary information-security controls, explains why they are included, states whether they are implemented, and justifies any Annex A reference controls determined unnecessary, according to the ISO/IEC JTC 1/SC 27 Working Group 1 Auditing Practices Note on the Statement of Applicability.
A defensible SoA should therefore answer four questions for each control decision:
- Why does this control apply, or why is it unnecessary?
- What risk, obligation, process, or treatment decision supports that answer?
- Is the control actually implemented?
- Where can someone verify the status and operation of the control?
What Is an ISO 27001 Statement of Applicability?
The Statement of Applicability, or SoA, is the documented record of which information-security controls are necessary for the ISMS, why they are included, whether they are implemented, and why any Annex A reference controls have been excluded.
It is not just an Annex A checklist. During risk treatment, the organization determines the controls needed to reduce information-security risk to an acceptable level, then compares those controls with Annex A to help ensure a necessary control has not been omitted. The presence of a control in Annex A does not automatically make it necessary; applicability depends on the organization’s context, risks, and relevant contractual or legal obligations.
The 2022 control set contains 93 controls organized into four themes: organizational, people, physical, and technological controls. In practice, most organizations represent the required Annex A comparison by working through those 93 controls and documenting whether each is applicable or excluded.
“Considered” does not mean “implemented by default.” Not by default. A control can be applicable and implemented, applicable but still planned or partially implemented, or not applicable with a specific justification.
How the SoA Fits With Scope, Risk Assessment, and Risk Treatment
The SoA should come after the organization understands what the ISMS covers and how it intends to treat risk. A practical sequence is:
- Define the ISMS scope.
- Identify risks within that scope.
- Assess those risks.
- Decide risk treatment actions.
- Select necessary controls, including any controls outside Annex A.
- Compare the selected controls with Annex A.
- Document applicability, rationale, implementation status, ownership, and evidence in the SoA.
The distinction matters:
- Risk assessment identifies and evaluates risks.
- Risk treatment plan records how the organization will address those risks.
- Statement of Applicability records which controls are necessary, why they are included or excluded, whether they are implemented, and where supporting evidence can be found.
A weak SoA is basically created by copying Annex A into a spreadsheet and guessing “applicable” or “not applicable.” A stronger SoA is built from the organization’s actual scope, assets, services, suppliers, obligations, and approved treatment decisions.
What an ISO 27001 SoA Should Include
ISO/IEC 27001 specifies what the SoA must contain, not a mandatory table layout. An Annex A-based table with implementation status and justification columns is a common practical format, and organizations may add information they consider necessary for traceability and maintenance.
A useful SoA structure usually includes:
| Field | What it proves |
|---|---|
| Control ID and name | Identifies the Annex A reference control being considered. |
| Applicability | Shows whether the control was determined applicable or unnecessary. |
| Inclusion or exclusion rationale | Explains the risk, obligation, process, technology, or scoped reason behind the decision. |
| Linked risk ID or treatment decision | Connects the control decision to the risk assessment or treatment plan. |
| Implementation status | Avoids overstating readiness by showing whether the control is implemented, partially implemented, planned, not implemented, or not applicable. |
| Control owner | Identifies who is accountable for maintaining the control and related evidence. |
| Evidence reference | Points reviewers to the policy, ticket, report, system record, repository, log, or other artifact that supports the status. |
| Last reviewed date | Shows when the decision was last checked for accuracy. |
| Approval or version reference | Connects the row to the controlled version of the SoA, where managed separately. |
Not every field needs to contain long prose. The SoA should be concise enough to maintain, but specific enough that a reviewer can trace the decision to the risk context and evidence.
How to Decide Whether an Annex A Control Applies
Applicability should be based on relevant drivers, preference or template defaults should not decide it. Common drivers include:
- risks identified in the risk assessment
- approved risk treatment decisions
- business processes inside the ISMS scope
- systems, assets, data, and technology used by the organization
- third-party dependencies
- customer or contractual requirements
- legal or regulatory obligations, where relevant
A control may be:
- Applicable and implemented: the control is necessary and operating.
- Applicable but partially implemented or planned: the control is necessary, but the current state does not yet match the intended treatment.
- Not applicable: the control is not necessary because the relevant risk, process, asset, technology, or obligation is outside scope or absent.
An exclusion should not be based only on cost, convenience, or immaturity. If a control addresses a relevant risk or obligation, the SoA should show the real treatment decision and current status rather than hiding the gap behind “not applicable.”
How to Write Defensible SoA Justifications
Good SoA wording is specific, traceable, and honest about status. The following examples are illustrative and should be adapted to the organization’s scope, risk treatment, and actual evidence.
Strong vs weak justification examples
| Scenario | Weak wording | Why it fails | Stronger wording |
|---|---|---|---|
| Inclusion rationale | “Implemented because required.” | Does not explain the risk, scope, or treatment decision. | “Applicable because the ISMS includes production SaaS systems containing customer data. Access control is selected to treat R-014: unauthorized access to production systems.” |
| Exclusion rationale | “Not relevant to our company.” | Too broad; does not explain what is absent or out of scope. | “Not applicable because the ISMS scope excludes organization-operated offices, server rooms, and physical hosting locations. Production infrastructure is hosted by approved cloud providers and addressed through supplier assurance controls. Exclusion approved in SoA v1.3.” |
| Status and evidence | “In progress.” | Does not show what exists, what is missing, or where to verify progress. | “Partially implemented. Cloud provider security review checklist is approved for AWS and Azure; GCP review remains open under treatment action RTP-022. Evidence: supplier-review/AWS-2025.pdf, supplier-review/Azure-2025.pdf, ticket GRC-184.” |
Filled sample SoA rows
| Control ID | Control name | Applicability | Justification | Linked risk/treatment | Status | Owner | Evidence reference | Last reviewed |
|---|---|---|---|---|---|---|---|---|
| 5.15 | Access control | Applicable | The ISMS includes production SaaS systems containing customer data. Access control is selected to reduce unauthorized access risk across production, admin, and support systems. | R-014 / RTP-006 | Implemented | Head of Engineering | Access Control Policy v2.1; IdP access review export Q1-2025; Jira SEC-122 | 2025-03-15 |
| 5.23 | Information security for use of cloud services | Applicable | The organization relies on cloud infrastructure for production hosting and storage. Cloud service governance is needed to support supplier and configuration risk treatment. | R-021 / RTP-011 | Partially implemented | Cloud Platform Lead | Cloud Supplier Review Checklist; AWS review 2025; Azure review 2025; GRC-184 for remaining GCP review | 2025-03-15 |
| 8.12 | Data leakage prevention | Applicable | Customer data can be exported by support and operations personnel. DLP controls are selected to reduce the risk of unauthorized disclosure through email and endpoint transfer. | R-032 / RTP-019 | Planned | Security Operations Manager | Treatment plan RTP-019; DLP rollout project SEC-245; interim export approval procedure | 2025-03-15 |
| 7.4 | Physical security monitoring | Not applicable | The ISMS scope does not include organization-operated offices, server rooms, or physical hosting locations. Staff work remotely and production infrastructure is hosted by approved cloud providers. Physical security of provider facilities is addressed through supplier assurance evidence. | Exclusion decision EX-007 | Not applicable | ISMS Manager | Scope Statement v1.4; Supplier Assurance Register; SoA approval record v1.3 | 2025-03-15 |
The important pattern is not the exact wording. It is the traceability: each row connects the control decision to scope, risk treatment, owner, status, and evidence.
How to Link the SoA to Evidence, Owners, and Review Activity
The SoA should point to evidence, not contain every piece of evidence. A row can reference a policy, repository path, system report, ticket, risk register entry, supplier review, configuration export, access review, screenshot, or audit log. One artifact can support multiple controls if the mapping is clear.
For example, an access review export may support access control, privileged access management, and joiner-mover-leaver controls. The SoA should reference the artifact consistently so reviewers can find it, and find the same version, without relying on someone’s memory.
Owners should be named by accountable role or team, not only by a person who may leave the organization. A practical model is:
- control owner: accountable for the control’s operation
- evidence owner: responsible for producing or maintaining evidence
- ISMS owner: responsible for SoA version control, review coordination, and approval workflow
Implementation status should be precise enough to avoid ambiguity. “Implemented” should mean the control is operating and evidence exists. That is usually clear enough. Or, more accurately, it is clear enough only if the evidence location and review history are also kept current. “Partially implemented” or “planned” should point to the treatment action, target evidence, interim measure, or acceptance decision where applicable.
Maintain the SoA when changes affect its accuracy, such as:
- ISMS scope changes
- new or updated risk assessment results
- major technology or process changes
- supplier or hosting model changes
- audit findings
- new customer, contractual, or legal obligations
- control implementation changes
- management approval or version updates
The review cadence should fit the organization’s ISMS document-control process. The key is that the SoA remains aligned with current risks, treatment decisions, and evidence.
Common SoA Mistakes That Create Audit Readiness Problems
These gaps can make it harder to demonstrate conformity and traceability during review:
- completing the SoA before risk assessment and treatment decisions
- marking all controls applicable without explaining why
- excluding controls with vague wording such as “not relevant”
- claiming implementation without evidence references
- failing to link controls to risks or treatment decisions
- leaving owners blank
- using stale review dates
- lacking clear version history or approval
- copying generic template language that does not reflect actual operations
- confusing the SoA with the risk assessment or treatment plan
Before certification or surveillance review, check:
- Has the organization compared its necessary controls with Annex A?
- Are Annex A reference controls determined unnecessary justified?
- Is each inclusion rationale specific to scope, risk, obligation, or treatment?
- Does each applicable control have a truthful implementation status?
- Are owners assigned?
- Are evidence references current and findable?
- Does the SoA align with the risk treatment plan?
- Is the current version approved under the ISMS document-control process?
- Has the SoA been reviewed after material scope, risk, technology, or obligation changes?
For ISMS certification, the SoA version is referenced in certification documentation, and auditors assess whether the SoA conforms to Clause 6.1.3 requirements. No template wording guarantees acceptance; the SoA needs to reflect the organization’s actual decisions and evidence.
When Expert Support or Compliance Tooling Helps
Many SoA problems come from treating compliance as a document project instead of an operating workflow. Tools can help maintain control mappings, evidence references, owners, review activity, and readiness checks, but they do not remove the need for human judgment about risk relevance, applicability, exclusions, implementation status, evidence quality, or management approval.
Ciphrix can help teams turn risk treatment decisions into operational compliance workflows, supporting continuous evidence collection, control reuse, evidence mapping, readiness checks, and ongoing maintenance. Expert review remains important for judgment-heavy areas such as exclusion rationale and treatment decisions.
A good SoA is not a static template. It is a maintained record of security control decisions, evidence, and accountability. Start by making each row traceable; then decide whether spreadsheet discipline, expert support, or tooling is the right way to keep it reliable enough.