ISO/IEC 27001 practical guide
Statement of Applicability: How to Select and Justify Annex A Controls
A useful Statement of Applicability is more than a list of 93 controls. It connects your risks, legal obligations and business context to clear implementation decisions—and gives auditors a concise view of how your ISMS works.
What is a Statement of Applicability?
The Statement of Applicability, usually abbreviated as SoA, records which information security controls are applicable to your organization, why they are applicable, whether they have been implemented and why any controls have been excluded. It is one of the central documented outputs of an ISO/IEC 27001 information security management system.
The SoA should not be treated as a copied checklist. Its purpose is to show the reasoning behind your control environment. A reader should be able to trace each decision back to the organization’s risks, obligations and chosen risk treatments.
What should the SoA contain?
A practical SoA normally includes at least the following information for every Annex A control:
- Control reference and a clear control name
- Applicability decision: applicable or not applicable
- Justification for inclusion or exclusion
- Implementation status
- Reference to the policy, process, system or evidence that implements the control
- Control owner or responsible role, where useful
You may add maturity, target dates, linked risks or testing frequency, but avoid turning the SoA into an unmanageable master spreadsheet. Detailed operating procedures and evidence should remain in the documents and systems referenced by the SoA.
A practical six-step method
1. Confirm the scope and context
Before selecting controls, define what the ISMS covers: locations, services, information, technology, personnel and external dependencies. A control decision can only be understood in relation to this scope.
For example, an organization operating its own offices may need extensive physical security arrangements. A fully remote software company may implement the same security objective through home-working rules, device protection and contractual controls rather than controlled office zones.
2. Use the risk assessment as your starting point
Review the risks identified for information assets and business processes. For each risk requiring treatment, determine whether it should be reduced, avoided, transferred or accepted. Where the treatment involves a control, record that relationship.
3. Add legal, regulatory and contractual requirements
Not every applicable control originates from the risk register. Data-protection law, customer contracts, industry requirements and internal policies may require controls even when the related risk is already considered low. Record these obligations as part of the justification.
4. Review every Annex A control
Compare the chosen treatments against all Annex A controls. This completeness check helps identify control objectives that the initial risk-treatment discussion may have missed. Evaluate the intent of each control in the context of your organization rather than rejecting it because the wording appears unfamiliar.
If an equivalent measure already exists, the control can still be applicable. The SoA should describe or reference the organization-specific implementation rather than forcing a generic solution.
5. Write evidence-based justifications
A good justification explains the business reason for the decision. “Required by ISO 27001” is not sufficient because Annex A controls are selected based on risk treatment and applicable requirements.
| Weak entry | Stronger entry |
|---|---|
| Applicable because it is required. | Applicable to reduce the risk of unauthorized privileged access to production systems; implemented through role-based access, approval and quarterly review. |
| Not relevant to our company. | Not applicable because the ISMS scope contains no owned or leased office, data-centre or storage facilities; physical hosting is provided by evaluated cloud suppliers. |
| Implemented. | Implemented through the supplier security procedure, due-diligence checklist and annual review of critical service providers. |
6. Approve and maintain the SoA
The SoA should be reviewed whenever significant risks, technologies, suppliers, services, locations or obligations change. It should also be checked during planned ISMS reviews. Assign an owner and define who approves changes so that the document remains controlled.
How to justify exclusions
An exclusion does not mean that a control is inconvenient or not yet implemented. It means the control is genuinely not necessary within the defined scope after considering risks and applicable obligations.
A defensible exclusion should state the relevant facts. For example, if software development is entirely outsourced, secure development controls may still be applicable through supplier requirements and assurance. Outsourcing an activity does not automatically remove accountability for its security.
Example SoA entries
| Control | Decision and justification | Implementation reference |
|---|---|---|
| A.5.15 Access control | Applicable because employees and contractors access confidential customer and corporate information. | Access Control Policy; joiner-mover-leaver workflow; quarterly access review |
| A.7.4 Physical security monitoring | Not applicable to the organization’s own locations because the scoped workforce is fully remote and no company premises or physical server rooms are operated. | Remote Working Policy; cloud supplier assurance records |
| A.8.13 Information backup | Applicable to support recovery of business-critical cloud data and configuration following deletion, corruption or service disruption. | Backup Standard; restoration test records; monitoring dashboard |
These examples illustrate structure, not automatic decisions. The correct conclusion depends on your actual ISMS scope, risks and obligations.
Implementation status without ambiguity
A simple “yes/no” field often hides important gaps. Consider using a small controlled set of statuses:
- Implemented: operating as designed with evidence available
- Partially implemented: some required elements are missing or inconsistent
- Planned: approved but not yet operating
- Not implemented: applicable, with treatment action required
- Not applicable: excluded with documented justification
Do not confuse applicability with implementation. An applicable control can be incomplete, and this should remain visible in the SoA and risk-treatment plan.
Evidence auditors may expect
The SoA itself is evidence of control selection, but it should point to operational evidence. Depending on the control, this might include:
- approved policies and procedures
- system configurations and screenshots
- tickets, approvals and review records
- training records and acknowledgements
- supplier assessments and contracts
- monitoring results, logs and test reports
- meeting minutes and management decisions
References should be specific enough that a control owner or auditor can locate the evidence without relying on personal knowledge.
Common SoA mistakes
- Copying generic justifications across all controls
- Including controls without linking them to risks or requirements
- Excluding outsourced activities without evaluating supplier-related controls
- Claiming full implementation when evidence is missing
- Using outdated control references after changing standards versions
- Allowing the SoA and risk-treatment plan to contradict each other
- Failing to update the document after organizational or technical change
Audit-ready SoA checklist
- All Annex A controls have been considered.
- Every inclusion and exclusion has a meaningful justification.
- Applicable controls can be traced to risks or other requirements.
- Implementation status reflects reality.
- References lead to current documents and evidence.
- Control owners understand their responsibilities.
- The SoA is approved, version-controlled and periodically reviewed.
Final takeaway
The strongest Statements of Applicability are concise, traceable and honest. They show why each control matters, how it is implemented and where improvement is still required. Build the SoA alongside the risk-treatment process, then use it as a living overview of your information security control environment—not merely as a document prepared for certification.
Continue with the Annex A controls
Use the practical control library to explore implementation steps, examples, evidence and common mistakes for all 93 controls.