The Statement of Applicability (SoA) is one of the most important documents, serving as a foundation for the selection and management of security controls within an ISO/IEC 27001 Information Security Management System (ISMS).
SoA formally connects your organisation’s risk scenario to the ISO 27001 controls, which are selected to manage it. Whether it is protecting company information or securing customer data, the Statement of Applicability (SoA) shows how seriously an organisation takes information security.
For auditors and decision-makers, it offers a clear picture of the organisation’s security approach and risk priorities.
What is the statement of applicability in ISO 27001?
The ISO 27001 SoA serves as a comprehensive control register of all controls listed in Annex A of the ISO 27001 standard. In its 2022 version, the standard has 93 controls under three different categories: 1) people, 2) physical, and 3) technological.
- For each control, the documents record whether it applies to your organisation, and also determine the rationale behind the applicability.
- For every Statement of Applicability, an applicability status is stated as included or excluded.
- Under the scope of an ISMS, the SoA maps the outcomes of the risk treatment process.
Rather than being a standalone document, the SoA is directly shaped by the risks identified during the ISMS risk assessment process.
Auditors give it special attention during their reviews, using it to verify that your organisation has systematically assessed the risks and has made deliberate, evidence-based decisions about which applicable controls will be implemented and why.
Example:
Inclusion: A fintech firm may include controls around cryptography (Annex A 8.24) and a secure development lifecycle (Annex A 8.25).
Exclusion: The firm may legitimately and conveniently exclude physical media transfer controls (Annex A 7.10) without documented justification because its operations are entirely based on the cloud, without the requirement of physical media.
The nature of risk related to this sector includes data interception and software vulnerabilities as high-priority threats.
How do you define ISO 27001 controls?
Step 1: Conduct a Risk Assessment
Take a private hospital that has recently moved its patient records from physical files to a digital records management system. When conducting a risk assessment, the hospital would need to map out every point where patient data could be at risk — the electronic health record (EHR) software, the laptops used by doctors and nurses, the Wi-Fi network across hospital floors, and third-party lab systems that connect to their database.
Case: A hospital that has recently moved its patient records from physical files to a digital records management system conducts a risk assessment.
The hospital will need to map out every point where patient data may be at risk – the electronic health record (EHR) software, the laptops and tech gadgets used by doctors and nurses, the WiFi network across hospital floors, and third-party lab systems.
Incident: A nurse’s laptop that is left unlocked in a ward can allow unauthorized access to hundreds of patient records, which poses a direct threat. This risk is addressed by user endpoint device controls (Annex A 8.1) and clear screen and desk policies (Annex A 7.7).
The hospital’s reliance on third-party lab systems also introduces supply chain risks, which fall under supplier relationship security (Annex A 5.19).
Impact of these risks materialising:
- A serious breach of patient confidentiality.
- Potential violations of healthcare data regulations.
- Lasting damage to the hospital’s reputation.
Steps to be taken: Risks must be documented, assessed for likelihood and severity, and carried into the risk treatment stage, where these Annex A controls are formally evaluated for inclusion in the SoA.
Step 2: Select Relevant Annex A Controls
Once risks are identified, they should be linked to relevant Annex A controls as part of the risk treatment process. Each control included in the SoA should address a specific risk, legal requirement, or contractual obligation.
Case Example: Selecting Relevant Annex A Controls
A private hospital shifting from physical patient files to a digital records system conducts a risk assessment to identify risks across EHR software, staff laptops, hospital Wi-Fi, and third-party lab systems.
- Incident:
An unlocked nurse’s laptop may expose confidential patient records to unauthorized access. - Relevant Annex A Controls:
- Endpoint device security — Annex A 8.1
- Clear desk and screen policy — Annex A 7.7
- Supplier relationship security — Annex A 5.19
- Potential Impact:
Data breaches, regulatory violations, and reputational damage. - Risk Treatment:
These risks are assessed and mapped to relevant Annex A controls for inclusion in the Statement of Applicability (SoA).
Step 3: Align Controls with Business Operations
The ISO/IEC 27001 controls selected in the Statement of Applicability (SoA) should align with how the organisation actually operates. Controls that reflect real business activities, infrastructure, and operational risks are easier to implement and maintain effectively.
- Case:
A cloud-based IT company with a fully remote workforce reviews its information security risks. - Operational Reality:
Employees access company systems remotely using personal and company-managed devices instead of working from a centralized office location. - Relevant Annex A Controls:
- Access control management: Annex A 5.15
- Information security for use of cloud services: Annex A 5.23
- Endpoint device security: Annex A 8.1
- Why Alignment Matters:
Physical visitor controls may be less critical for a remote business, while cloud security, remote access, and device protection become essential operational controls. - Outcome:
Aligning controls with actual business operations helps ensure the ISMS remains practical, enforceable, and audit-ready.
Step 4: Document Your Rationale
Every control included in the Statement of Applicability (SoA) should have a clearly documented justification. The SoA should explain the risk addressed by the control, the reason for selecting it, and its current implementation status.
- Case:
A financial services company identifies the risk of unauthorized access to customer financial data stored on cloud platforms. - Selected Control:
Access control management – Annex A 5.15 - Documented Rationale:
The control was selected to reduce the risk of unauthorized access to sensitive financial information and to support compliance with customer data protection requirements. - Implementation Status:
Multi-factor authentication (MFA) and role-based access controls have already been implemented across critical systems. - Why Documentation Matters:
Properly documenting control selection helps demonstrate audit readiness, risk-based decision-making, and ISO/IEC 27001 compliance during certification audits.
In practice, the flow and logic are straightforward: risk identification, selection of control, and documentation of justification.
- Surfacing of the risk
- The choice of control is made
- The decision is recorded
How to Justify Applicable and Excluded Controls
Many organisations focus heavily on selecting the right controls but give far less thought to justifying those decisions. Yet justification is what separates a defensible SoA from one that fails under audit scrutiny, and it applies equally to controls that are included and those that are left out:
- Included controls: Point directly to the risk, regulation, or business requirement that makes the control necessary. For example, a fintech firm including cryptography controls (Annex A 8.24) would reference the identified risk of data interception and its obligation under PCI DSS.
- Excluded controls: Clearly demonstrate that the omission does not create an unacceptable gap in information asset protection. The same fintech firm, excluding physical media transfer controls (Annex A 7.10), would state that its operations are entirely cloud-based, with no physical media in use.
- Undocumented exclusions: Failing to record reasons for exclusions is one of the most frequently cited weaknesses in audit readiness assessments and one of the easiest to avoid.
ISO 27001 Control Applicability Overview
• Healthcare: Included Controls: • Endpoint device security (Annex A 8.1)
• Access control (Annex A 5.15)
• Supplier relationship security (Annex A 5.19)
• Backup (Annex A 8.13) | Excluded Controls: • Certain physical disposal or visitor-related controls may be reduced or outsourced depending on the service model | Justification/Review: [‘• Sensitive patient health data\n • Privacy obligations\n • Dependence on connected systems and supplier access’, ‘• Auditors verify whether controls align with patient-data risks and regulatory requirements’]
• Financial Services / Fintech: Included Controls: • Cryptography (Annex A 8.24)
• Secure development lifecycle (Annex A 8.25)
• Logging and monitoring (Annex A 8.15 and 8.16)
• Supplier security (Annex A 5.19) | Excluded Controls: • Physical media transfer controls may be excluded in fully cloud-based environments | Justification/Review: [‘• Fraud prevention\n • Customer data protection\n • Payment compliance obligations’, ‘• Auditors expect strong justification for both included and excluded controls’]
• Cloud IT / SaaS: Included Controls: • Cloud service security (Annex A 5.23)
• Change management (Annex A 8.32)
• Secure development lifecycle (Annex A 8.25)
• Network security (Annex A 8.20) | Excluded Controls: • Physical site and media controls are often excluded in remote-first cloud-native operations | Justification/Review: [‘• Heavy reliance on cloud infrastructure\n • Remote access and deployment security requirements’, ‘• Reviews focus on alignment between the SoA and actual cloud architecture changes’]
• Manufacturing / Industrial: Included Controls: • Physical security perimeters (Annex A 7.1)
• ICT readiness for business continuity (Annex A 5.30)
• Network segregation (Annex A 8.22)
• Access rights management (Annex A 5.18) | Excluded Controls: • Cloud-specific controls may be less relevant in primarily on-premise industrial environments | Justification/Review: [‘• Protection of physical assets and operational technology (OT)\n • Plant continuity and vendor access security’, ‘• Auditors focus on IT/OT segregation, critical asset protection, and plant-system changes’]
Practical Use
This table is a planning aid rather than a fixed template. ISO 27001 requires each organization to decide whether a control is applicable based on its own risks, scope, legal requirements, and business operations, and then document the reason for inclusion or exclusion in the SoA. The SoA should be maintained and reviewed based on internal audits, major changes in the business, onboarding of new vendors, incidents, updates in the regulations, and the relevance of selected controls.
How to maintain the SOA?
Internal audits are your built-in checkpoint. They help you confirm that the controls in your SoA are still relevant, still implemented, and still doing the job they were selected to do. A simple rule to follow: review your SoA at least once a year and immediately after any significant change to your business, technology, or regulatory environment. This keeps your ISMS current, your controls aligned, and your organisation audit-ready at all times.
- Identification of new risks through periodic risk assessments.
- New systems, tools, and technologies are altering the tech environment.
- Identification of a weak spot during a security incident or a near-miss weakness exposure.
- Updates in laws and regulations alter the compliance requirement.
- Significant business or process changes affect the scope of ISMS.
Conclusion
Think back to everything covered in this article, the risks mapped during assessment, the controls carefully selected and justified, the exclusions documented with clear reasoning, and the SoA reviewed and updated as the organisation evolves.
Every one of those steps feeds into a single document: the ISO/IEC 27001 Statement of Applicability. When built with discipline and maintained with intent, the SoA stops being a compliance formality and becomes the clearest proof that your organisation takes information security seriously, not just at certification time, but every day after it.
Whether you are building your SoA for the first time, preparing for a surveillance audit, or simply want to make sure your controls still reflect your current risk environment – MSCi’s consultants are here to help. With more than four decades of experience supporting organisations through ISO/IEC 27001 implementation and certification, we bring the expertise to make the process straightforward and the outcome sustainable. Get in touch with our team today.
FAQs
Q1. What is a Statement of Applicability (SoA) in ISO/IEC 27001?
SoA is a mandatory ISO 27001 document that lists applicable Annex A controls, implementation status, exclusions, and the justification behind each control that remains under the scope of ISMS.
Q2. Is the Statement of Applicability mandatory for ISO 27001 certification?
Yes. SoA is a mandatory requirement under ISO/IEC 27001 and is reviewed closely during surveillance and certification audits to verify risk-based control selection as well as implementation.
Q3. What is included in an ISO 27001 SoA?
ISO 27001 comprises relevant Annex A controls, omitted controls, implementation status, and documented reasons related to business risks and legal responsibilities.
Q4. How often should the Statement of Applicability be reviewed?
The SoA needs to be reviewed at least once a year, whenever there are major updates, such as upcoming technologies, vendors, business processes, regulations, and security decisions.
Q5. Why is the SoA important in ISO/IEC 27001?
The SoA displays how an organization is able to identify information security risks and choose appropriate controls to manage them, which helps auditors prepare for effective implementation of an ISMS and become compliance-ready.
• Editor’s Note
This content has been developed and reviewed by MSCi’s editorial and compliance-focused content team to ensure alignment with ISO/IEC 27001:2022 concepts, industry terminology, and practical ISMS implementation considerations. The objective is to provide accurate, professionally structured, and research-backed information for business and compliance audiences.
