How to Write a Well-Structured Statement of Applicability for ISO 27001

The Statement of Applicability (SoA) is a key requirement often referenced in ISO/IEC 27001:2022 guidance and is commonly misunderstood by some organisations. As the mandatory output of Clause 6.1.3, it provides a complete list of all 93 Annex A controls, shows which controls are applicable or not, and documents the justification behind every decision.

For SMEs and startups, the SoA is a practical tool for demonstrating how risk treatment decisions may be applied, linking controls to Risk Treatment Plans, and intended to provide a clear reference for auditors regarding how your ISMS applies controls within your defined scope. A well-prepared SoA is intended to support clear documentation of controls and considerations of legal, statutory, regulatory, and contractual (LSRC) requirements, but actual audit outcomes depend on your organisation’s implementation.

This guide explains how to create a clear SoA, the common mistakes smaller organisations make, and the elements auditors typically expect to see in a structured SoA.

What the Statement of Applicability Actually Does

The SoA bridges your risk assessment, your Risk Treatment Plans, and the 93 Annex A controls. It can serve as a reference “index” of your ISMS security controls and typically include the following four essential elements:

1. Which Annex A controls are selected based on risk treatment and external requirements.
2. Why each control is applicable or not, with a brief justification for inclusion or exclusion.
3. Whether the necessary controls are implemented or not.
4. The justification for excluding any of the Annex A controls.

For lean teams, the SoA is intended to support structured ISMS implementation, guide documentation decisions, clarify scope boundaries, intended to assist in addressing LSRC requirements, and provides a structured reference for auditors.

SoA vs Scope vs Context: Understanding the Boundaries

SMEs often confuse the SoA with the ISMS Scope (Clause 4.3) or the Context of the Organisation (Clause 4.1). These documents are related, but each serves a different mandatory function within ISO/IEC 27001:2022 and influences risk assessment, risk treatment, and control applicability in different ways.

1. Context of the Organisation (Clause 4.1)

Identifies the internal and external issues and the interested parties that affect the ISMS. This analysis establishes the operating environment, constraints, and requirements, which later influence scope and control selection.

2. ISMS Scope (Clause 4.3)

Defines the boundaries and applicability of the ISMS – specifically which assets, technologies, processes, locations, or services are included. The scope helps determine which controls the SoA may cover.

3. Statement of Applicability (Clause 6.1.3)

Determines which Annex A controls may be applicable within the defined scope, based on the outputs of risk assessments and Risk Treatment Plans. It documents:

• the control
• its applicability
• the justification for inclusion or exclusion
• implementation notes
• evidence locations
  

Critical Rule for Audit Preparation

Exclusions should generally be carefully considered; controls required to mitigate a risk or meet LSRC considerations are usually included, but final decisions depend on the organisation’s implementation.

Valid exclusion justification must trace back to assets, technologies, or environments explicitly out of scope.

Clear differentiation between these three documents is intended to support clear audit documentation and easier reviewer reference, but audit outcomes are ultimately the organisation’s responsibility.

Why the SoA Matters So Much for SMEs and Startups

For small teams, the Statement of Applicability (SoA) is one of the most valuable ISO/IEC 27001:2022 documents. It may support structured audit preparation, is intended to guide teams to avoid unnecessary work, and intended to support SMEs in maintaining a lean and repeatable ISMS, depending on implementation.

1. Reduces audit time and clarification questions

Auditors rely heavily on the SoA to understand your Annex A control selection, risk treatment rationale, and evidence mapping. A clear SoA is intended to support structured audit documentation and may contribute to consistency; actual audit outcomes depend on implementation.

2. Prevents over-engineering your ISMS

Many SMEs assume they must implement all 93 Annex A controls, which often leads to unnecessary complexity. A well-justified SoA is intended to provide guidance on potential applicability of controls and intended to support SMEs in considering informed implementation decisions based on risk and external requirements.

3. Supports consistency across policies, procedures, and evidence

Lean organisations benefit from clarity and repeatability. The SoA serves as a reference point to help align policies, procedures, and evidence. It can help documentation, risks, controls, and evidence remain consistent within the organisation’s practices.

4. Helps maintain repeatability across ISO cycles

A structured SoA is intended to assist with consistent ISMS documentation across audit cycles. It provides a reference to support documentation consistency; actual outcomes depend on organisational practices.

What ISO 27001 Requires in the SoA (2022 Edition)

Under ISO/IEC 27001:2022 Clause 6.1.3, the SoA must document how your organisation addresses information security risks and treats Annex A controls.

ISO-Mandated Requirements

For every Annex A control, the SoA should include:

1. Necessary controls – Controls selected to treat identified risks (Clause 6.1.3 b) and c)).
2. Justification for Inclusion – Explain why the control is included.
3. Implementation Status – Indicate whether each selected control is implemented or not.
4. Justification for Exclusion – Provide a short explanation for any control not selected.

Note: The ISO 27001 mandates documenting whether necessary controls are implemented or not (Implementation Status). However, it does not mandate detailed implementation descriptions, specific tools, or detailed evidence references within the SoA document itself (these are typically found in referenced policies and procedures).

Audit-Friendly Enhancements for SMEs and Auditors

To make the SoA clear, traceable, and audit-friendly, SMEs can add:

• Applicability Decisions Linked to Risks – Trace each control to risks it mitigates.
• Linkage to Scope and Context – Show whether controls apply within the defined ISMS boundaries.
• External Requirements (LSRC) – Include controls required by legal, statutory, regulatory, or contractual obligations (e.g. privacy regulations).
• Implementation Details (Optional) – Short descriptions of processes, tools, or security measures used.
• Evidence, Policy References, and Control Owners – Provides structured references for auditors to review control coverage and evidence; actual audit outcomes depend on your implementation.

These elements are intended to support readability, traceability, and structured audit preparation.

How the SoA Addresses External Requirements (LSRC)

When preparing your Statement of Applicability (SoA), control selection should consider not only risks identified in your Risk Treatment Plans, but also LSRC requirements. This may assist with audit preparation and alignment with ISO 27001 principles, and considers obligations of interested parties.

Some controls may become applicable solely due to external requirements, even if your internal risk assessment rates the associated risk as low or medium. For SMEs, accounting for LSRC requirements is intended to support documentation clarity and consideration of compliance obligations; actual compliance effectiveness depends on organisational implementation.

Example LSRC-driven control relationships:

Best Practices for SMEs:

• Reference the specific requirement in the justification: Example: “Applicable – Linked to relevant legal or contractual considerations.” Actual obligations may vary depending on your organisation’s context.
• Link LSRC controls to scope and context (Clauses 4.3 and 4.1): Ensure that exclusions or non-applicable decisions are clearly outside your defined ISMS boundaries.
• Align with risk treatment requirements (Clause 6.1.3): Even if a control is not linked to a high or medium risk internally, LSRC mandates may still make it essential.

By consolidating LSRC considerations into your SoA, this can help demonstrate that control selection is comprehensive, traceable, and aligned with internal risk management and external obligations. This approach enhances audit preparation, strengthens ISO 27001 compliance, and clarifies the SoA’s strategic role for SMEs and startups.

Step-by-Step Guide to Writing a Well-Structured SoA

The following steps aim to guide SMEs and startups in producing an ISO 27001-aligned SoA that aligns risk treatment, scope, context, and external requirements (LSRC).

Step 1 – Start With Your Completed Risk Assessment and LSRC Review

Your risk assessment drives control selection, while LSRC (Legal, Statutory, Regulatory, Contractual) requirements ensure compliance beyond internal risk priorities.

Key Considerations:

• All high and medium risks should have documented treatment decisions.
• Controls should logically help mitigate those risks.
• Any control selected due to LSRC considerations should be documented with justification, recognising that actual compliance effectiveness depends on implementation.
• Confirm scope and context alignment: controls apply only within defined ISMS boundaries.

Tip: A weak risk register or missing LSRC review could result in a less clear or less complete SoA.

Step 2 – Create a Clean, Standardised Annex A Table

List all 93 Annex A controls in a clear, structured table.

Include:

• Control ID (e.g. A.5.2)
• Control name
• Applicability (Applicable / Not Applicable)
• Justification (linking risk, scope, or LSRC)
• Implementation description (short, concise)
• Evidence References
• Policy / Procedure References
• Control Owner

Note: Structure and consistency matter more than volume.

Step 3 – Decide Whether Each Control Is Applicable

Rules for SMEs:

• Many SMEs find that a large portion of controls may be applicable.
• Exclusions are generally expected to be carefully considered, logical, and traceable to scope or context boundaries; actual audit acceptance can vary.
• Include LSRC-driven inclusions even if internal risk is low or medium.

Common SME Exclusion Examples:

Justification Examples:

• Applicable: “Selected to help manage cloud infrastructure access for production systems (aligned with identified risks and LSRC considerations).”
• Not Applicable: “No physical office; no physical perimeter exists within the defined scope.”
  

Step 4 – Document How Each Control Is Implemented

Include concise details for each control:

• Process, mechanism, or tool that enforces the control.
• Where evidence is stored
• Which role owns it

Example (A.5.17 Authentication Information): “Implemented, for example, via enforced MFA on relevant systems, a password manager policy, and automated IDP configuration. Evidence: access logs, onboarding checklist.”

Tip: Many SMEs keep descriptions brief (1 – 3 sentences per control) intended to maintain practicality and readability.

Step 5 – Reference Policies, Procedures, and Evidence

Avoid long narratives; instead, link directly to supporting documentation:

• Link to policies, procedures, logs, reports, checklists, or screenshots.
• Highlight LSRC alignment where relevant.

Example: “See Access Control Policy (POL-AC-01), Onboarding Checklist (PRC-HR-02), IDP audit logs.”

Step 6 – Assign Clear Control Owners

Assign roles, not individuals, for accountability and repeatability:

• Engineering Lead: logging, configuration, secure development
• Operations Manager: suppliers, onboarding / offboarding
• CEO / Founder: risk decisions, leadership commitments
• IT / Security: device security, monitoring, incident response
  

Step 7 – Review the SoA for Internal Consistency

You may improve internal consistency by checking:

• Applicability decisions match risk treatments and LSRC rationales
• Exclusions respect scope and context boundaries
• Implementation descriptions align with policy references
• Evidence references appear to exist and be reasonably accurate
• Control ownership is assigned consistently
• No outdated or contradictory information remains

Tip: Improved internal coherence is intended to support structured audit documentation and supports clear organisational practices.

What a Good SoA Looks Like – Template Structure

A well-structured SoA can support demonstrating ISO/IEC 27001:2022 alignment. It is intended to provide a clear reference of control applicability, justification, implementation, evidence, and ownership, while keeping your ISMS lean and SME-friendly.

Example Template Column and Purpose

Example Control

• Control ID and Name: A.5.2 Information security roles and responsibilities
• Applicability: Applicable
• Justification: Selected to support to defining responsibilities for cloud systems access (aligned with identified risks and LSRC considerations)
• Implementation: Roles documented in HR policy, MFA enforced, regular access reviews
• Evidence: HR policy, access logs, review records
• Owner: IT Security
  

Best Practices for SMEs

• Keep the SoA standalone: Maintain in Excel or Word for easy updates and audit submission.
• Link to evidence: Reference documents and logs rather than embedding them.
• Stay concise: One to three sentences per control is sufficient.
• Consistency over volume: Uniform formatting across all 93 Annex A controls improves readability and audit clarity.
• Audit-friendly references: Aim for each column to be traceable to supporting documentation, risk treatments, scope, context, and LSRC requirements.
  

SoA Examples for SMEs and Startups (Quick Reference)

Cloud-First SaaS Startup

• Control Coverage: Many ISO 27001 Annex A controls may be applicable, depending on the organisation’s scope.
• Physical Security: Commonly excluded in some cloud-based organisations, depending on organisation’s scope; check your own environment before applying.
• Backup and Business Continuity / Disaster Recovery: May align with cloud provider capabilities; SMEs should confirm coverage meets organisational needs.
• Monitoring and Logging: Centralised via identity provider (IDP) and cloud-native logging tools.
• Audit Notes: Justifications reference risk treatment decisions and LSRC compliance for cloud operations.

Professional Services SME

• Control Coverage: Most Annex A controls apply, focusing on data protection, access control, and supplier management.
• Technical Controls: Fewer exclusions; physical and environmental controls generally applied.
• Documentation: Policies, procedures, and evidence references align with risk treatment decisions.
• Audit Notes: Justifications explicitly link controls to scope, context, and LSRC requirements where relevant.

Fully Remote Team

• Control Coverage: A large portion of controls may be applied, but physical perimeter and on-premise environmental controls may be excluded, depending on the organisation’s scope.
• Remote Operations: Controls tailored for cloud-based devices, remote access, and virtual collaboration tools.
• Justification: Clearly references absence of physical assets and links exclusions to scope boundaries.
• Audit Notes: All exclusions and implementations are intended to be traceable to risk assessments and LSRC obligations.
  

Common Mistakes SMEs Make When Maintaining the SoA

• Mistake 1 – Copy-pasting generic text: Your Statement of Applicability should reflect your real environment, not templates.
• Mistake 2 – Marking all controls as applicable: Can result in higher workload and require additional audit clarification.
• Mistake 3 – Writing long, narrative essays: Keep your SoA lean and evidence-linked.
• Mistake 4 – Misalignment with Risk Register or LSRC: Ensure each control ideally maps to documented risks, scope boundaries, or legal / regulatory considerations.
  

How Often Should SMEs Update the SoA?

Update your ISO/IEC 27001:2022 SoA whenever:

• Your risk assessment or LSRC obligations change
• New systems, services, or suppliers are added
• Controls are implemented, updated, or matured
• Internal or external audits are approaching
• There are any other significant changes, and at least annually to ensure alignment with current risks, scope, and external requirements.

Tip: Treat the SoA as a living document. Frequent updates improve audit preparation, traceability, and SME operational clarity.

Final Checklist – What a Well-Structured ISO/IEC 27001:2022 SoA Includes

✔ Full list of 93 Annex A controls, commonly mapped to relevant risks and LSRC considerations
✔ Clear applicability decisions (Applicable / Not Applicable)
✔ Clear justifications linking each control to risks, scope, or LSRC considerations
✔ Practical, concise implementation notes (processes, tools, or measures)
✔ Evidence and policy references for audit traceability
✔ Clearly assigned control ownership (roles, not individuals)
✔ Alignment with risk assessments, LSRC, and ISMS scope boundaries
✔ Consistent structure, naming, and control IDs
✔ Clear traceability to scope and context for internal and external audits

Conclusion – Developing a Well-Structured SoA

A well-structured Statement of Applicability (SoA) is a practical tool for SMEs and startups to document control decisions, link them to risk assessments and LSRC obligations, and maintain a clear reference for ISMS implementation.

Regular updates, alignment with scope and context, and concise evidence linkage help ensure the SoA remains a valuable resource that supports consistent information security practices and compliance over time. Treat it as a living document to improve operational clarity and ongoing ISMS effectiveness.

Next Steps: Explore our Statement of Applicability (ISO 27001 Template) to support your SME’s ISMS development.

Next Article: In ISO 27001 Risk Register Template Walkthrough (SME Guide), learn how to effectively identify, assess, and document information security risks for SMEs.

Related Guides

Explore these ISO 27001 resources to help your SME build a practical, lean ISMS: 

Start Here: Complete Guide

• ISO 27001 for SMEs and Startups: The Chill Implementation Guide (2026 Edition) – Full roadmap covering all clauses and Annex A controls, with practical steps, examples, and guidance.

C. Risk, Statement of Applicability, and Annex A Controls – Detailed Guides by Topic

• A Practical Guide to the ISO 27001 Risk Assessment (SME Focus) – Step-by-step guidance to identify, assess, and prioritise risks, linking them to your Statement of Applicability and controls.
• ISO/IEC 27001:2022 Annex A Controls Explained for SMEs – Practical Overview – A practical overview to understand and prioritise Annex A controls, and linking control choices to a risk-based Statement of Applicability (SoA).
  
• ISO 27001 Risk Register Template Walkthrough (SME Guide) – Risk Register walkthrough for SMEs: covering structure, L / M / H scoring, Annex A mapping, and documenting Risk Acceptance. 
• Illustrative Guide to Common ISO 27001 Risks for SMEs – Clear examples of frequently observed SME risks, with likelihood / impact scoring, mitigation suggestions, and aligned Annex A control references.

Please Note: This article provides general information only and does not constitute legal, regulatory, or compliance advice. Using our products or following this guidance cannot guarantee certification, improved business outcomes, or regulatory compliance. Organisations remain responsible for ensuring all actions meet certification and compliance requirements.