An ISO 27001 Statement of Applicability, commonly called the SoA, records the information-security controls an organization has determined are necessary for treating its risks and meeting relevant requirements. It also compares those decisions with the Annex A reference controls, states implementation status and explains exclusions. A useful SoA is therefore much more than a copied control list.
The document—or controlled record in a GRC system—connects risk assessment to treatment. It tells management and auditors why a control belongs in the ISMS, whether the control operates and where supporting information can be found. When maintained well, it becomes a map of the control environment. When treated as a last-minute spreadsheet, it often reveals that risk, policy and evidence were never properly connected.
- The SoA records necessary controls, inclusion reasoning, implementation status and justified Annex A exclusions.
- Annex A is a reference set, not a menu that limits an organization to 93 controls.
- Applicability should follow risk and requirements, not convenience.
- Owners and evidence references are useful practical fields even when maintained in linked systems.
- The SoA must change when scope, risk, technology, obligations or controls change.
What ISO 27001 expects from the Statement of Applicability
As part of information-security risk treatment, ISO 27001 requires an organization to determine the controls needed to implement its treatment choices and compare them with Annex A so necessary controls are not overlooked. The resulting SoA identifies the necessary controls, gives reasons for including them, records whether they are implemented and explains why any Annex A reference control is excluded.
This structure permits organization-specific decisions. A necessary control may come from Annex A, a contract, law, sector framework or the organization's own design. Conversely, an Annex A control can be excluded where the organization can justify that it is not necessary. The decision needs to be defensible within the ISMS scope and risk context; “we have not implemented it” is not a reason for non-applicability.
Practical fields for a usable ISO 27001 SoA
A minimum record can satisfy the stated SoA information, but operational fields make it easier to manage. A practical table often includes a control identifier and title, applicability decision, inclusion or exclusion rationale, implementation status, control owner and evidence or document references. Some teams add linked risks, requirements, last-review date and improvement actions.
These extra fields do not need to make the SoA unreadable. If risk and evidence are managed in separate registers, stable references can connect them. The purpose is traceability, not duplication. An auditor should be able to select a control, understand the reason for it and navigate to the information that supports its status.
Example of a defensible control record
Consider secure authentication for an internet-facing service. The rationale could point to unauthorized-access risk and a customer security obligation. Implementation status might be “implemented,” with evidence references to the access-control standard, identity-provider configuration, a recent privileged-access review and a test sample. The owner might be the infrastructure lead.
The SoA need not contain sensitive configuration detail. It should contain enough direction to show that the statement is not unsupported. If multi-factor authentication covers administrators but not another high-risk population, “partially implemented” may be more accurate, with a linked treatment action and target date.
How to determine Annex A applicability
Begin with the ISMS scope, risk-assessment results and risk-treatment decisions. Add legal, regulatory, contractual and business requirements that require controls. Then compare the resulting necessary controls with the full Annex A reference set. This sequence avoids using Annex A as the risk assessment itself while still using it as a completeness check.
For each Annex A control, ask whether it is necessary to treat an identified risk or satisfy another applicable requirement. If yes, include it and record the basis. If no, record a concise rationale grounded in scope and context. A control being outsourced does not automatically make it inapplicable; the organization may still need governance, contractual, monitoring or assurance activities around the outsourced service.
Do not confuse “not applicable” with “not implemented.” Applicability answers whether the control is needed. Implementation answers whether the organization has put the necessary control into operation. Conflating the two can hide gaps by relabeling unfinished controls as exclusions.
Link the SoA to evidence without creating clutter
Evidence mapping can be direct or through linked records. Policy references show expected practice. Operational evidence—tickets, system settings, reviews, logs, training records, supplier assessments or test results—helps demonstrate that the control operates. The right evidence depends on the control and should be relevant to the period and scope under review.
Avoid pasting temporary links that will break or pointing every control to a broad policy library. Use stable identifiers, controlled repositories and clear ownership. Evidence has a lifecycle: it may expire, be superseded or cease to represent the current environment. The SoA status should not remain “implemented” indefinitely without review.
Common Statement of Applicability mistakes
- Copying generic rationales: repeated text does not explain the organization's decision.
- Excluding difficult controls: implementation difficulty is a gap, not an applicability argument.
- Listing policies as the only evidence: intent alone may not demonstrate operation.
- Ignoring non-Annex controls: necessary controls can come from other sources.
- Freezing the SoA before the risk work: treatment choices should drive it.
- Losing version control: the approved record needs ownership, review and change history.
When to review and update the SoA
Review it on a planned schedule and when meaningful change occurs. Triggers include scope changes, new systems or locations, major suppliers, new legal or contractual obligations, incidents, risk reassessment, control redesign and findings from audit or management review. Updates should remain consistent with the risk treatment plan and supporting documentation.
A sensible review checks both the decision and its evidence. Is the control still necessary? Is the rationale still accurate? Is the implementation status current? Does the referenced evidence exist and cover the relevant scope? Who accepted the update? These questions keep the SoA useful after certification activity has passed.
FAQ
Are all 93 Annex A controls mandatory?
No. Annex A is a reference set used to check that necessary controls have not been missed. Exclusions are possible when they are justified, while additional controls may also be necessary.
Can the Statement of Applicability be a spreadsheet?
Yes, if it is controlled, current and contains the required decisions. A GRC platform is optional; clarity, traceability and change control matter more than the tool.
Should evidence be embedded in the SoA?
It can be referenced rather than embedded. Stable links or identifiers reduce clutter while preserving traceability to controlled evidence.
Who should approve the SoA?
ISO 27001 assigns risk-treatment approval and residual-risk acceptance to appropriate risk owners. Organizations should define SoA preparation, review and approval responsibilities within their ISMS governance.