If you are new to ISO 27001, the term Statement of Applicability, or SoA, can sound more complicated than it really is.
In practice, it does something quite simple.
It records which security controls your organization has chosen, which controls it has not chosen, and why.
More importantly, it shows that those decisions were made in a structured, risk-based way, not randomly.
Short answer: a Statement of Applicability is the ISO 27001 document that explains which Annex A controls apply to your ISMS scope, which controls do not apply, why those decisions were made, whether selected controls are implemented, and how the control choices connect back to risk treatment.
That is why the SoA matters so much in ISO 27001.
It is not just another document to fill out for compliance. It is one of the clearest ways to show that your information security management system is based on real decisions.
ISO/IEC 27001:2022 defines requirements for an information security management system and explains that organizations use the standard to manage risks related to the security of data they own or handle. ISO also describes the standard as adaptable to an organization’s size and needs, which is exactly why the SoA should reflect your real scope, risks, and control decisions.
Where risk decisions become control choices
So, what is the Statement of Applicability?
In plain English, the SoA is the document that turns ISO 27001 control selection into something explainable.
It connects three important things:
- Your ISO 27001 scope.
- Your information security risks.
- Your selected controls.
Without that bridge, it becomes much harder to explain why certain controls are in place and others are not.
The SoA is especially important because ISO 27001 is not about implementing every possible control in the same way for every organization. It is about selecting and operating controls that make sense for the organization’s risks, scope, obligations, and business context.
What the SoA is not
Many teams misunderstand the SoA at first.
It is not a checklist where you mark every Annex A control as applicable just to look safer.
It is not a copied document from another company.
It is not a one-time spreadsheet that you complete once and forget.
And it is not a replacement for actual implementation.
A SoA that says a control is implemented should be supported by real evidence. A SoA that excludes a control should explain why the exclusion makes sense for the scope and risk context.
If the SoA does not match the risk assessment, control implementation, policies, procedures, or evidence, it becomes a source of audit questions.
What the SoA actually does
A good way to think about the SoA is this:
It tells the story of your control choices.
It explains:
- Which Annex A controls are relevant to your organization.
- Which Annex A controls are not relevant.
- Why those decisions were made.
- Whether selected controls are implemented.
- How the decisions connect back to risk and scope.
- Where supporting policies, procedures, or evidence can be found.
That is the real value.
The SoA helps turn ISO 27001 from a long list of controls into a practical, explainable structure. It gives auditors, customers, leadership, and internal teams a clear view of how the organization moved from risk decisions to control decisions.
Why auditors care about the SoA
Auditors are not looking for a perfect-looking spreadsheet.
They are looking for consistency.
If the risk assessment says a certain risk matters, the SoA should reflect how that risk is being treated. If a control is excluded, there should be a real reason. If a control is marked as implemented, there should be evidence behind it.
That is why the SoA matters in an ISO 27001 audit.
It helps show that the organization did not choose controls randomly. It made deliberate decisions based on risk, scope, obligations, and business reality.
In practical terms, auditors often use the SoA to understand:
- Which controls are in scope.
- Why controls were included.
- Why controls were excluded.
- Whether implementation status is realistic.
- Whether policies and procedures support the control decisions.
- Whether evidence exists for implemented controls.
- Whether the SoA aligns with the risk assessment and risk treatment plan.
The key point is not to prove that every possible control has been implemented. The point is to prove that control decisions are intentional, justified, and traceable.
What should usually be in a Statement of Applicability
The exact format can vary, but a practical SoA usually includes these elements.
| Field | What it explains |
|---|---|
| Control reference | The Annex A control identifier. |
| Control name | The name or short description of the control. |
| Applicability | Whether the control applies to the ISMS scope. |
| Justification for inclusion | Why the control is needed. |
| Justification for exclusion | Why the control does not apply, if excluded. |
| Implementation status | Whether the control is implemented, partly implemented, planned, or not implemented. |
| Risk or requirement link | Which risk, obligation, customer need, or business reason supports the decision. |
| Evidence or document reference | Where policies, procedures, records, or other evidence can be found. |
| Owner | Who is responsible for the control or related process. |
You do not need to make the SoA complicated. You do need to make it clear enough that someone can understand why each control decision was made.
The biggest mistake teams make
The most common mistake is thinking the SoA is about saying “yes” to as many controls as possible.
It is not.
The point is to explain your choices clearly.
If the SoA says almost every control is applicable, but the risk assessment does not support that, the document starts looking defensive instead of thoughtful. If it excludes a control with vague wording like “not relevant,” that creates another problem.
The better approach is honesty and structure.
If a control applies, explain why.
If it does not apply, explain why.
If it is still being implemented, say that clearly.
That is much more useful than trying to look perfect.
Common SoA problems auditors notice
Several problems tend to stand out quickly during review.
Weak exclusions
An exclusion should explain why the control does not apply to the organization, scope, risk, or environment.
“Not applicable” is usually not enough by itself.
Implementation status that sounds too optimistic
If a control is marked as implemented, the team should be ready to show how it works and where evidence exists.
Poor alignment with the risk assessment
If the risk assessment identifies a meaningful risk but the SoA does not show a reasonable control response, the reviewer will usually ask why.
Missing evidence references
The SoA should help people find supporting documents or records. If it does not point anywhere, review becomes slower.
Stale control decisions
The SoA should be reviewed when the business changes, when scope changes, when risks change, and when control implementation changes.
Why the SoA matters for SMBs and lean teams
For small and growing businesses, the SoA can actually make life easier.
Why?
Because it gives structure.
Without it, control selection can become messy. Teams may know they need access controls, policies, vendor checks, backups, incident response, security awareness, logging, and evidence management, but they may not know how to organize those decisions clearly.
The SoA brings those decisions together.
It creates a practical link between:
- Scope.
- Risk assessment.
- Control selection.
- Policy work.
- Implementation tasks.
- Evidence collection.
- Audit readiness.
That structure is useful even before certification. It helps the team explain what matters, what has been selected, what still needs work, and why.
A simple way to think about it
If you want the plain-English version:
Your risk assessment tells you what matters.
Your risk treatment plan explains what you plan to do about it.
Your selected controls show how those decisions are being handled.
Your Statement of Applicability records those control decisions clearly.
That is what it actually does.
It turns control selection into something explainable.
How to keep the SoA useful
A SoA is most useful when it stays connected to real work.
Use these practical habits.
Review it when scope changes
If you add a new product, system, location, data type, supplier, or business process to the ISO 27001 scope, review the SoA.
Review it when risks change
If the risk assessment changes, the SoA may need to change too.
Connect controls to evidence
Do not leave the SoA as a standalone list. Link controls to policies, procedures, tickets, reports, approvals, logs, screenshots, or other records.
Keep implementation status honest
It is better to show that a control is planned or partly implemented than to mark it complete without evidence.
Avoid vague exclusion reasons
Exclusions should be clear enough that another person can understand the logic later.
Where Framework-Pro fits
This is where Framework-Pro fits naturally.
Framework-Pro helps teams choose the right security framework, work through adaptive questionnaires, select relevant controls, and generate tailored policy drafts and supporting documents. It also supports a Statement of Applicability draft or control map, implementation checklist, evidence placeholders, and an audit pack starter.
That matters because many teams do not struggle with the idea of a SoA. They struggle with getting from framework choice to relevant controls to documentation that is clear enough to review and use.
Framework-Pro outputs are guidance and still need implementation, review, and approval. But they help create a structured starting point faster than trying to build a control map, policy set, and evidence plan manually from a blank page.
FAQ
What is a Statement of Applicability in ISO 27001?
A Statement of Applicability is the ISO 27001 document that records which Annex A controls apply to your ISMS scope, which controls do not apply, why those decisions were made, whether selected controls are implemented, and where supporting evidence or documentation can be found.
Is the Statement of Applicability the same as a risk assessment?
No. The risk assessment identifies and evaluates risks. The Statement of Applicability records the control decisions that come from risk treatment, scope, obligations, and business context. The two documents should align.
Does every Annex A control need to be implemented?
No. ISO 27001 is risk-based. Controls should be selected and justified based on the organization’s scope, risks, requirements, and context. If a control is excluded, the exclusion should be clearly justified.
What should auditors see in a good SoA?
Auditors should be able to see applicable controls, exclusions, justifications, implementation status, ownership, and links to policies, procedures, evidence, risk treatment, or other supporting records.
How often should the SoA be reviewed?
The SoA should be reviewed when the ISMS scope changes, risks change, control implementation changes, business processes change, or before important audits and certification activities. Many organizations also review it as part of the regular ISMS review cycle.
Final thought
A Statement of Applicability is not just an ISO 27001 document sitting in the background.
It is one of the documents that makes your control decisions visible.
When it is done well, it helps your organization show that security choices are intentional, connected to risk, and supported by real policies and evidence.
That is also why it tends to make audits, reviews, and internal discussions much easier.
If your team is still figuring out which controls apply, how to document them clearly, or how to turn that into a usable Statement of Applicability, take a look at Framework-Pro on aneo.io. It helps teams choose the right framework, narrow the right controls, and generate supporting outputs like a SoA draft, control map, policy set, and evidence placeholders faster.