What Is a Statement of Applicability?
A Statement of Applicability, commonly abbreviated as SoA, is a formal document that lists all the controls or requirements from an ISO standard's Annex or control set, and records whether each one applies to your organisation, whether it has been implemented, and why decisions were made either way. It is one of the most important documents you will produce during an ISO certification project, and it is one of the first things an auditor will ask to see.
On this page
The term is most closely associated with ISO 27001 for information security management, where it is an explicit mandatory requirement. However, the concept of documenting which requirements apply, which are excluded, and why, is relevant across many ISO standards. If you are going through certification for the first time, understanding the SoA early will save you a significant amount of rework later.
Why the Statement of Applicability Matters
Think of the SoA as the bridge between your risk assessment and your actual controls. It is not enough to identify risks and say you have addressed them. The SoA is the documented proof that you have made deliberate, justified decisions about every control available to you. Auditors use it to trace a line from your risks, through your decisions, to your implemented controls.
If your SoA is vague, incomplete, or inconsistent with your actual practices, it will raise red flags during a Stage 2 audit. I have seen organisations spend months building solid management systems, only to struggle at audit because their SoA did not accurately reflect what they were actually doing. The document needs to be honest, current, and traceable.
The SoA Is a Living Document
One mistake businesses make is treating the SoA as a one-time exercise completed before certification. It is not. Your organisation changes, new threats emerge, services are added or discontinued, and your control environment evolves. The SoA needs to be reviewed and updated regularly, at least annually as part of your management review cycle, and whenever significant changes occur in your business or risk profile.
Where Does the Statement of Applicability Come From?
In ISO 27001, the requirement for an SoA comes directly from Clause 6.1.3. The standard requires organisations to produce an SoA that contains the necessary controls, justification for their inclusion, whether they are implemented, and justification for excluding any controls from ISO 27001 Annex A, which contains 93 controls across four themes in the 2022 version of the standard.
For other standards, the principle is similar even if the term is not always used. In ISO 42001 for artificial intelligence management, for example, organisations must document which controls from Annex A and Annex B apply to their AI systems and justify exclusions. The logic is the same: you must show deliberate, risk-based decision-making about what you are and are not doing.
Annex A Controls in ISO 27001:2022
The 2022 revision of ISO 27001 reorganised Annex A into 93 controls grouped under four themes. These are:
- Organisational controls (37 controls): Policies, roles, responsibilities, supplier relationships, incident management, and similar governance items.
- People controls (8 controls): Screening, terms of employment, awareness, training, disciplinary processes, and remote working.
- Physical controls (14 controls): Physical security perimeters, entry controls, securing offices, clear desk policies, and equipment maintenance.
- Technological controls (34 controls): Authentication, access management, encryption, logging, vulnerability management, and data masking.
Your SoA must address every one of these 93 controls. For each one, you document whether it applies, whether it is implemented, and your reasoning. This is not a tick-box exercise. The justification column is where auditors focus their attention.
What Does a Statement of Applicability Actually Look Like?
Most organisations present their SoA as a structured spreadsheet or table. There is no mandated format, but the content must meet the standard's requirements. A typical SoA table will include columns for:
- The control reference number and name from Annex A
- Whether the control is applicable (yes or no)
- The justification for inclusion or exclusion
- Whether the control has been implemented
- A reference to the relevant policy, procedure, or evidence
Some organisations also add a column for the implementation status, such as planned, in progress, or complete, which is useful during the implementation phase but should be resolved to a clear implemented or not implemented status before your certification audit.
A Practical Example: Cloud-Based Software Company
Consider a small software-as-a-service company seeking ISO 27001 certification. They operate entirely in the cloud, have no physical servers on premises, and employ twelve people who all work remotely. When they complete their SoA, they might legitimately exclude certain physical controls, such as those relating to physical security perimeters around data centres, because they rely entirely on a third-party cloud provider who holds their own certifications.
However, they cannot simply write “not applicable, we use the cloud” and move on. The justification needs to explain that the physical security of the infrastructure is the responsibility of the cloud provider, that this has been assessed through supplier due diligence, and that contractual and audit rights are in place. The auditor will follow that thread and check that the supplier management controls are implemented to compensate.
A Practical Example: Healthcare Clinic
A private healthcare clinic handling patient records will likely find that almost all 93 controls apply. Sensitive personal health data, regulatory obligations under Australian privacy law, staff accessing records from multiple locations, and third-party billing systems all create a broad risk landscape. Their SoA will have very few exclusions, and the justification for any exclusion needs to be watertight. An auditor reviewing this SoA will look closely at whether the justifications are genuinely risk-based or whether controls have been excluded simply to reduce implementation effort.
Common Mistakes in Preparing a Statement of Applicability
Having reviewed many SoAs as an auditor, the same problems come up repeatedly. Here are the ones that cause the most trouble.
Excluding Controls Without Proper Justification
The most common issue is excluding controls because they seem difficult or expensive to implement, rather than because they genuinely do not apply. Auditors are trained to probe exclusions. If you exclude a control, you need to be able to demonstrate that the risk it addresses either does not exist in your context or is addressed through an alternative control. “We are too small” or “we do not have budget” are not acceptable justifications for excluding a control that addresses a real risk.
Disconnecting the SoA From the Risk Assessment
The SoA must flow logically from your risk assessment. If your risk assessment identifies a significant threat related to unauthorised access to systems, but your SoA excludes the access control and authentication controls, the auditor will flag this immediately. The two documents need to be consistent and cross-referenced. This is why conducting your ISO 27001 risk assessment properly before drafting the SoA is so important.
Saying Controls Are Implemented When They Are Not
Some organisations mark controls as implemented in their SoA because they intend to implement them, or because they have a draft policy sitting in someone's inbox. During the Stage 2 audit, the auditor will ask for evidence of implementation. If your SoA says a control is implemented and you cannot produce evidence, that is a nonconformity. Be honest about implementation status and do not rush to mark things as complete before they genuinely are.
Not Updating the SoA After Changes
If you acquire a new business unit, move to a different cloud provider, introduce a new service, or experience a security incident that reveals a gap, your SoA needs to be reviewed. Surveillance audits will check that the SoA reflects your current state, not the state you were in when you first achieved certification.
The Statement of Applicability and ISO Standards Beyond ISO 27001
While the SoA is most formally required by ISO 27001, the concept of documenting applicability decisions appears in other standards too. Understanding this broader principle helps you build a more coherent management system.
ISO 42001 Artificial Intelligence Management
ISO 42001 includes both Annex A controls for AI governance and Annex B guidance on objectives. Organisations must document which controls apply to their AI systems, justify any exclusions, and demonstrate implementation. Given the rapid evolution of AI regulation globally, this document will likely become as scrutinised as the ISO 27001 SoA within a few years. If you are exploring ISO 42001 for AI management, building a rigorous applicability document early is strongly recommended.
ISO 9001 and the Concept of Exclusions
ISO 9001 does not use the term Statement of Applicability, but it does allow for exclusions under Clause 4.3 when determining the scope of the management system. If certain requirements of the standard do not apply due to the nature of your organisation or its products and services, you can exclude them, but you must document the justification. For example, a service organisation with no design and development activity can exclude Clause 8.3. This is documented in the scope, not a separate SoA, but the principle of justified applicability decisions is the same. You can read more about this in our guide on determining the scope of your management system.
Integrated Management Systems
If your organisation is pursuing certification to multiple standards simultaneously, your applicability documentation becomes more complex. Controls from ISO 27001, requirements from ISO 9001, and obligations under ISO 45001 may overlap, conflict, or complement each other. Building an integrated applicability register that maps controls across standards can reduce duplication and make your management system far easier to maintain and audit.
How to Build a Strong Statement of Applicability
Here is a practical approach to building an SoA that will hold up under audit scrutiny.
- Complete your risk assessment first. The SoA must flow from your risk treatment decisions. Do not start drafting the SoA until you have a completed, reviewed risk assessment that identifies your significant information security risks and your chosen treatment options.
- Work through every control systematically. Do not skip controls that seem irrelevant at first glance. For each of the 93 controls in Annex A, make a deliberate decision and write a genuine justification. This process itself often surfaces gaps in your thinking.
- Write justifications in plain language. Your justification should explain the business reason for inclusion or exclusion, not just restate the control name. A good justification references your specific context, your risk assessment findings, or your regulatory obligations.
- Cross-reference your policies and procedures. For each implemented control, reference the document, system, or process that provides the evidence of implementation. This makes the auditor's job easier and demonstrates that your SoA is connected to your actual management system.
- Get it reviewed before your Stage 1 audit. Your SoA should be reviewed by someone with ISO 27001 experience before your certification audit. An experienced consultant or internal auditor can identify gaps, inconsistencies, and weak justifications before the auditor does.
- Set a review schedule. Build the SoA review into your annual management review cycle and your change management process so it stays current.
How Auditors Use the Statement of Applicability
During a Stage 1 audit, the auditor will review your SoA to assess whether your management system is ready for a Stage 2 audit. They are checking that the document exists, covers all required controls, and is connected to your risk assessment. At Stage 2, the SoA becomes a roadmap. The auditor will select controls, particularly those that are implemented, and ask for evidence. They will also scrutinise exclusions and ask you to justify them verbally.
During surveillance audits, the auditor will check that the SoA has been reviewed and updated since the last audit, and that it still accurately reflects your control environment. A SoA that has not been touched since initial certification is a red flag, even if nothing in your organisation has changed. It suggests the document is not being actively managed.
If you want to understand more about what auditors actually look at, our article on what documents ISO auditors check during an audit covers this in detail.
Getting Help With Your Statement of Applicability
For many businesses, particularly those pursuing ISO 27001 for the first time, building the SoA is one of the most challenging parts of the certification project. It requires a solid understanding of the standard, a completed risk assessment, and the discipline to work through 93 controls with genuine, specific justifications.
If you are not sure where to start, or if you have drafted an SoA and want it reviewed before your audit, working with an experienced ISO 27001 consultant can save you significant time and reduce the risk of nonconformities. The SoA is not a document to rush or delegate to someone without the right knowledge.
At CertBetter, we connect businesses with verified ISO consultants and accredited certification bodies who have hands-on experience with documents like the SoA. Submit one form and receive up to three competing quotes from vetted providers, completely free of charge. Whether you are starting from scratch or preparing for a surveillance audit, the right expert can make a real difference to the quality of your applicability documentation and the outcome of your audit.
