If you are new to ISO 27001, the term Statement of Applicability, or SoA, can sound more complicated than it really is.
But in practice, it does something quite simple.
It shows which security controls your organization has chosen, which ones it has not chosen, and why. More importantly, it shows that those decisions were made in a structured, risk-based way, not randomly. Certification and audit guidance from NQA and BSI both describe the SoA as the place where organizations record applicable controls, exclusions, justification, and how those decisions relate to scope and risk.
That is why the SoA matters so much in ISO 27001.
It is not just another document to fill out for the sake of compliance. It is one of the clearest ways to show that your ISMS is based on real decisions. NQA’s auditor guidance is very clear on this point: the risk register and the Statement of Applicability are two outputs of the same risk-based decision process, and auditors expect them to align.
So, what is the Statement of Applicability?
In simple terms, the SoA is a document that lists the Annex A controls you have selected for your ISO 27001 scope, along with why they apply, why some do not apply, and what their implementation status is. BSI says it should list all the controls and include references to how and why they apply to your scope. NQA describes it as the record of which Annex A controls were selected to treat risk, which were not selected, and why.
That makes it a bridge between three important things:
your scope
your risks
your controls
Without that bridge, it becomes much harder to explain why certain controls are in place and others are not.
What the SoA is not
This is where many teams get confused.
The SoA is not a checklist where you simply mark everything as applicable to be safe. NQA specifically warns that treating the SoA like a checklist defeats the purpose of risk-based decision-making and often creates more auditor questions, not fewer.
It is also not supposed to be copied from another company.
That is one of the fastest ways to create gaps between your documents and your real environment. NQA highlights copy-pasted SoAs and weak exclusions as common mistakes that lead to inconsistency and nonconformities.
And it is definitely not a one-time document that you write once and forget. BSI says the SoA should be clear, concise, easy to understand, and reviewed regularly as the business and its processes change. NQA makes the same point and calls it a living document.
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 controls from Annex A are relevant to your organization
which controls are not relevant
why those decisions were made
whether those controls are implemented
how those decisions connect back to risk and scope
That is the real value.
The SoA helps turn ISO 27001 from a long list of requirements into a more practical, explainable structure. NQA’s guidance says the SoA should clearly show which controls were chosen, why they were chosen, and how they link back to the risk register.
Why auditors care about it
Auditors are not looking for a perfect-looking spreadsheet.
They are looking for consistency.
If your risk assessment says a certain risk matters, your 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 audit.
It helps show that your organization did not choose controls at random. It made deliberate decisions based on risk, scope, and business reality. NQA’s audit guidance says the key takeaway is not to prove you implemented everything, but to prove you made deliberate, risk-based choices.
What should usually be in an SoA
The exact format can vary, but a practical Statement of Applicability usually includes:
the Annex A control reference
the name of the control
whether it is applicable or not applicable
justification for inclusion
justification for exclusion
implementation status
reference to supporting policies, procedures, or evidence
These elements are consistent with the guidance highlighted by NQA and BSI, which point to applicable controls, exclusions, justification, implementation status, and references to how and why controls apply within scope.
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 be able to explain your choices clearly.
If your SoA says almost every control is applicable, but your risk assessment does not really support that, the document starts looking defensive instead of thoughtful. If it excludes a control with vague wording like “not relevant to us,” that creates another problem. NQA specifically warns against both patterns.
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.
Why this matters so much for SMBs
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 policies, access controls, vendor checks, backups, incident response, and awareness training, but they are not always sure how to organize those decisions clearly.
The SoA helps bring that structure together. It creates a more practical link between your risks, your chosen controls, and your supporting documentation. BSI describes the SoA as part of a step-by-step ISMS process that builds logically from risk understanding into policies, procedures, and controls.
How Framework-Pro helps
On the aneo site, Framework-Pro is designed to help teams choose the right framework, select relevant controls through adaptive questionnaires, and generate tailored policy drafts and supporting documents. It also specifically includes a Statement of Applicability draft or control map, plus implementation checklist and evidence placeholders. Aneo also notes that the outputs are guidance and still need implementation and review as part of a real certification journey.
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 actual documentation that is clear enough to review and use.
A simple way to think about it
If you want the plain-English version:
Your risk assessment tells you what matters.
Your controls show what you decided to do about it.
Your Statement of Applicability records those decisions clearly.
That is what it actually does.
It turns control selection into something explainable.
Final thought
A Statement of Applicability is not just an ISO 27001 requirement 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. NQA and BSI both emphasize clarity, justification, scope alignment, and regular review as the core qualities of a useful SoA.
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.
