Understanding what belongs in an ISO 27001 Statement of Applicability (SoA) is one thing. Knowing how to complete one for your organization is another.
When developing an SoA, information security professionals frequently encounter practical questions:
- What does a completed control entry actually look like?
- How detailed should an applicability justification be?
- How do you document a control that is necessary but not yet implemented?
- What constitutes a reasonable justification for excluding an Annex A control?
- How do you distinguish control implementation from control conformity or maturity?
This guide walks through practical ISO 27001:2022 Statement of Applicability examples, including sample control entries, inclusion and exclusion justifications, and common documentation mistakes.
If you’re developing your SoA for the first time, start with our step-by-step guide to creating an ISO 27001 Statement of Applicability before exploring the completed examples below.
What Does a Completed ISO 27001 Statement of Applicability Look Like?
A Statement of Applicability documents the information security controls your organization has determined are necessary and explains the reasoning behind those decisions.
ISO/IEC 27001:2022 Clause 6.1.3(d) requires the SoA to include:
- The necessary information security controls.
- Justification for including those controls.
- Whether the necessary controls have been implemented.
- Justification for excluding any controls from Annex A.
The standard does not prescribe a specific spreadsheet layout.
Organizations commonly use a table or workbook to document their control decisions, making it easier to review, maintain, and update the information.
Example SoA structure
| Field | Purpose |
|---|---|
| Control ID | Identifies the control, such as A.5.1 |
| Control Name | Identifies the Annex A control |
| Applicable | Indicates whether the control is necessary |
| Justification | Explains the reason for inclusion or exclusion |
| Implementation Status | Records whether the necessary control is implemented |
| Control Owner | Identifies the person or function responsible, if tracked |
| Supporting Evidence | References relevant policies, procedures, or records, if tracked |
The first five fields support the core Annex A documentation process. Control ownership and evidence references are optional additions that many organizations find useful.
Remember that your SoA should also account for necessary controls identified outside Annex A, where applicable.
The objective is not to create the most complicated spreadsheet. It is to maintain a clear, accurate, and defensible record of your organization’s control decisions.
ISO 27001 Statement of Applicability Examples
To illustrate how different controls might be documented, consider a hypothetical organization:
Example organization: Northstar Business Services
Northstar is a 75-employee professional services company that:
- Provides business consulting and administrative services.
- Uses Microsoft 365 and several cloud-based business applications.
- Employs a combination of remote and office-based personnel.
- Maintains a small leased office.
- Uses managed IT service providers for selected technical services.
- Processes confidential customer and business information.
- Does not operate its own data center.
The examples below reflect this hypothetical environment.
They are intended to demonstrate documentation approaches, not to establish which controls must apply to every organization.
Example 1: Information Security Policies — A.5.1
Control: A.5.1 — Policies for Information Security
Applicable: Yes
Example justification:
“Information security policies are necessary to establish management direction, define organizational security expectations, and support consistent information security practices across employees, contractors, and relevant third parties.”
Implementation status: Implemented
Potential supporting evidence:
- Approved information security policy.
- Policy review records.
- Evidence of policy communication.
- Documented policy ownership.
Why this example works
The justification explains why the control is necessary for the organization rather than merely restating the control title.
It connects the control to organizational governance and the need for consistent security expectations.
The implementation status indicates that the organization considers the control implemented. That assertion should be supported by the actual state of its policies and associated practices.
Example 2: Access Control — A.5.15
Control: A.5.15 — Access Control
Applicable: Yes
Example justification:
“Access control is necessary to restrict access to company information and information processing resources based on authorized business requirements, reducing the risk of unauthorized disclosure, modification, or use of information.”
Implementation status: Implemented
Potential supporting evidence:
- Access control policy.
- User provisioning and deprovisioning procedures.
- Role-based access configurations.
- Access approval records.
- Periodic access review records.
Why this example works
Northstar uses multiple cloud-based systems containing confidential business and customer information.
Access control is therefore relevant to its information security risk treatment.
The justification identifies the business purpose and the security risks addressed.
It is also specific enough to support an auditor’s understanding of why the organization selected the control.
Example 3: Information Security Awareness, Education and Training — A.6.3
Control: A.6.3 — Information Security Awareness, Education and Training
Applicable: Yes
Example justification:
“Personnel require appropriate information security awareness and training to understand their responsibilities, recognize relevant threats, and reduce risks arising from human error, phishing, and inappropriate information handling.”
Implementation status: Partially Implemented
Potential supporting evidence:
- Security awareness training materials.
- Employee completion records.
- New-hire onboarding requirements.
- Phishing simulation results.
- Training improvement plans.
Why this example works
This example illustrates an important distinction: a control can be necessary even when implementation is incomplete.
Suppose Northstar has introduced annual security awareness training but has not yet established consistent onboarding training or a process for addressing overdue completion.
The control remains applicable.
The organization should document the implementation gap and manage the remaining work through its established risk treatment or improvement processes.
A control should not be excluded simply because it has not been fully implemented.
Example 4: Supplier Relationships — A.5.19
Control: A.5.19 — Information Security in Supplier Relationships
Applicable: Yes
Example justification:
“Supplier security management is necessary because the organization relies on external service providers that may access, process, store, or support confidential business and customer information. Appropriate supplier controls help manage risks associated with third-party services.”
Implementation status: Partially Implemented
Potential supporting evidence:
- Supplier inventory.
- Supplier risk assessment records.
- Vendor due diligence documentation.
- Security requirements in contracts.
- Supplier monitoring and review records.
Why this example works
Northstar relies on cloud service providers and managed IT services.
Outsourcing a service does not automatically transfer all information security accountability to the provider.
The organization still needs to determine and manage the risks associated with those relationships.
A partially implemented status might be appropriate if Northstar has supplier contracts and initial due diligence procedures but has not yet established consistent ongoing supplier reviews.
Example 5: Physical Security Monitoring — A.7.4
Control: A.7.4 — Physical Security Monitoring
Applicable: Yes
Example justification:
“Physical security monitoring is necessary to help detect unauthorized physical access to the organization’s leased office and protect information and information processing resources located within the facility.”
Implementation status: Implemented
Potential supporting evidence:
- Building security arrangements.
- Physical access monitoring procedures.
- Security monitoring service agreements.
- Records of relevant monitoring activities.
Why this example works
Northstar operates a leased office.
Even if the landlord provides security monitoring services, the organization should understand how the arrangement addresses relevant risks.
The control’s implementation may depend on measures provided by an external party.
That arrangement should be appropriately understood and documented rather than automatically treating the control as not applicable.
Example of an Excluded ISO 27001 Annex A Control
Exclusion justifications deserve particular attention.
ISO 27001 allows organizations to exclude Annex A controls when they are not necessary, but those exclusions must be justified.
An exclusion should be supported by the organization’s scope, risks, requirements, and risk treatment decisions.
Example 6: Secure Development Life Cycle — A.8.25
Control: A.8.25 — Secure Development Life Cycle
Applicable: No — illustrative scenario only
Example justification:
“The organization does not develop software or perform software development activities within its defined ISMS scope. Business applications are obtained as externally developed services, and the associated supplier and service security risks are addressed through other selected controls. The organization’s risk assessment has not identified a need for a secure development life cycle control.”
Implementation status: Not Applicable
Important qualification
This exclusion would only be reasonable if Northstar’s actual operating environment supports it.
For example, if the organization develops custom applications, maintains internal software, or performs relevant development activities, the applicability decision would need to be reconsidered.
Even an organization that purchases commercial software should assess whether relevant development-related risks or requirements create a need for this control.
Why this example works
The justification does more than say, “We do not develop software.”
It explains the operational circumstances, acknowledges related supplier risks, and connects the decision to the organization’s risk assessment.
That provides a more defensible basis for an exclusion.
Weak vs. Strong SoA Justifications
One of the most common weaknesses in Statements of Applicability is the use of vague or generic justifications.
Compare these examples.
| Control | Weak Justification | Stronger Justification |
|---|---|---|
| A.5.1 — Policies for Information Security | Required by ISO 27001 | Establishes management direction and consistent security expectations across the organization |
| A.5.15 — Access Control | We use passwords | Restricts access to confidential information and business systems according to authorized business requirements |
| A.5.19 — Information Security in Supplier Relationships | We have vendors | Addresses information security risks arising from suppliers that access, process, or support organizational information |
| A.6.3 — Information Security Awareness, Education and Training | Employees need training | Helps personnel recognize relevant threats and fulfill their information security responsibilities |
| A.8.25 — Secure Development Life Cycle | Not needed | No software development activities occur within the ISMS scope, and the risk assessment has not identified this control as necessary |
The stronger examples explain the reasoning behind the decision.
They are not automatically sufficient for every organization, but they demonstrate how to move beyond generic statements.
A useful test is to ask:
Could someone unfamiliar with our organization understand why we included or excluded this control?
If the answer is no, the justification may need additional context.
Download a Free ISO 27001 Statement of Applicability+ Template
You don’t need to create your SoA workbook from scratch.
GRCPod’s free ISO 27001:2022 Statement of Applicability+ template provides a structured starting point for documenting your organization’s control decisions.
The editable workbook includes:
- All 93 ISO 27001:2022 Annex A controls.
- Applicability tracking and example justifications.
- Control implementation status.
- Optional conformity assessment fields.
- Optional control maturity scoring.
- Confidentiality, integrity, and availability (CIA) objective tracking.
- Assessment date tracking.
- A companion guide explaining how to complete the workbook.
Available in Microsoft Excel and Google Sheets.
[DOWNLOAD THE FREE STATEMENT OF APPLICABILITY+ TEMPLATE]
Example justifications are starting points only. Review and customize them to reflect your organization’s actual ISMS scope, risks, and requirements.
Applicability vs. Implementation vs. Conformity vs. Maturity
These four concepts are related, but they answer different questions.
Understanding the differences helps prevent inaccurate or misleading control assessments.
Applicability: Is the Control Necessary?
Applicability determines whether a control is necessary for the organization based on its risks and requirements.
For example, access control may be necessary because employees and contractors access confidential information through cloud applications.
Applicability is a control selection decision.
Implementation: Is the Control in Place?
Implementation describes whether the organization has established the necessary control.
A control may be applicable but not yet implemented.
For example, supplier risk assessments may be required, but the organization may still be developing its formal assessment process.
Implementation status should reflect the current state rather than the intended future state.
Conformity: Does the Control Meet the Assessment Criteria?
Conformity describes whether a control satisfies defined requirements or assessment criteria.
For example, an organization may have an access review process in place, but an assessment could identify that required reviews were not performed.
The control may be implemented while still having a conformity finding.
Conformity is not a mandatory separate SoA field under ISO 27001, but organizations may track it for additional oversight.
Maturity: How Well Is the Control Managed?
Control maturity evaluates how consistently, effectively, and systematically a control is operated and improved.
An organization may have an implemented control but limited monitoring, measurement, or continual improvement.
A maturity assessment can help identify these opportunities.
However, ISO 27001 does not prescribe a universal 0–5 control maturity scoring model for the SoA.
Organizations that use maturity scoring should clearly define their own model and avoid presenting it as an ISO 27001 certification requirement.
Example: One Control, Four Different Assessments
Consider Northstar’s access control practices.
| Assessment Dimension | Illustrative Result |
|---|---|
| Applicability | Applicable |
| Implementation | Implemented |
| Conformity | Finding identified |
| Maturity | Level 2 on an internal 0–5 scale |
This combination is possible.
The organization has determined that access control is necessary and has implemented relevant measures.
However, an assessment identified a weakness, such as incomplete periodic access reviews.
Its internal maturity assessment also indicates that the control’s operation and measurement could be improved.
These findings are not contradictory. They describe different aspects of the control environment.
How Much Detail Should an SoA Include?
There is no universal number of words required for an applicability justification.
The appropriate level of detail depends on the organization’s environment and the complexity of the control decision.
For straightforward inclusions, a concise explanation may be sufficient.
For exclusions, unusual risk treatment decisions, or controls involving complex shared responsibilities, additional explanation may be helpful.
A practical approach is to ensure each justification:
- Identifies why the control is necessary or unnecessary.
- Connects the decision to relevant risks, requirements, or operating conditions.
- Avoids generic language that could apply to any organization.
- Is consistent with supporting risk assessment and risk treatment documentation.
Avoid turning the SoA into a duplicate of every policy, procedure, or risk assessment.
Instead, reference supporting documentation where it helps substantiate the decision.
The SoA should remain usable as a control selection and implementation record.
Five Mistakes to Avoid When Completing Your SoA
1. Copying Template Justifications Without Customizing Them
Example justifications can accelerate documentation, but they cannot determine your organization’s actual control requirements.
Review each justification before adopting it.
2. Marking Unimplemented Controls as Not Applicable
Applicability is not determined by whether implementation work has been completed.
If a control is necessary, document it as such and accurately record its implementation status.
3. Assuming Outsourced Controls Are Automatically Excluded
Using a cloud provider, managed service provider, or landlord does not automatically make related controls unnecessary.
Assess the organization’s responsibilities, supplier arrangements, and relevant risks.
4. Using the SoA as a Substitute for Risk Assessment
The SoA records control decisions. It does not replace the organization’s information security risk assessment and risk treatment processes.
The documents should support one another.
5. Failing to Update the SoA When Controls Change
A control’s applicability or implementation status may change as the organization evolves.
Review the SoA when relevant changes occur and maintain consistency with the organization’s risk treatment decisions.
Frequently Asked Questions
Can I use an ISO 27001 Statement of Applicability example as my actual SoA?
You can use an example as a starting point, but it must be adapted to your organization.
Applicability decisions, justifications, and implementation statuses must reflect your actual ISMS scope, risks, and requirements.
Can a control be applicable but not implemented?
Yes.
A necessary control may not yet be implemented. Its implementation status should accurately reflect that condition, and the organization should manage any outstanding risk treatment activities.
Do I need to provide evidence for every control in the SoA?
ISO 27001 does not require a dedicated evidence column in the SoA.
However, maintaining references to supporting policies, procedures, records, and other evidence can make internal reviews and audits more efficient.
Can I exclude an Annex A control because it is too expensive?
Cost alone is not a sufficient basis for concluding that a necessary control is not applicable.
Control selection should follow the organization’s risk treatment process, including consideration of applicable requirements and appropriate treatment options.
Should I include control maturity scores in my SoA?
Maturity scoring is optional.
It can be useful for monitoring control improvement, but it is not a mandatory SoA requirement under ISO 27001.
Is a Statement of Applicability required for ISO 27001 certification?
Yes. The SoA is required by ISO/IEC 27001:2022 Clause 6.1.3(d) and forms part of the documented information relevant to an organization’s ISMS.
Final Thoughts
A useful ISO 27001 Statement of Applicability does more than identify which controls apply.
It explains the reasoning behind control selection, documents exclusions, and provides an accurate view of implementation.
The strongest SoAs are not necessarily the longest. They are the ones that clearly reflect the organization’s risk treatment decisions and can be supported by its actual security practices.
Use examples to understand how to structure your entries, but ensure every final decision is appropriate for your organization.
If you’re starting your SoA or improving an existing one, GRCPod’s free workbook can help you organize the process.
[GET YOUR FREE ISO 27001:2022 STATEMENT OF APPLICABILITY+ TEMPLATE]
