The Statement of Applicability: Demystifying the Most Misunderstood ISO Document
A practical Elyrion briefing on the statement of applicability: demystifying the most misunderstood ISO document.
Executive answer
The Statement of Applicability, or SoA, is often described as an ISO 27001 checklist.
That description is technically convenient and operationally misleading.
The SoA is one of the most important pieces of evidence connecting an organisation’s information security risks to the controls it has chosen to operate. It records which Annex A controls are applicable, explains the justification for their inclusion or exclusion and provides a structured view of how those controls are implemented.
In other words, the SoA should answer a fundamental question:
“Given what we know about our organisation and its risks, why does our ISMS contain these controls?”
That makes it much more than an audit document.
A well-designed SoA is a decision map between risk and control.
A poorly designed SoA is a spreadsheet with 93 rows and a collection of checkmarks.
Why the SoA Exists
ISO 27001 does not require every organisation to implement every Annex A control simply because the control appears in the standard.
That is one of the first things teams discover when they begin implementation.
The organisation determines its information security risks, establishes its risk treatment approach and then selects appropriate controls.
Annex A provides a reference set of controls that can support that process.
The SoA records the outcome.
This is important because two organisations can both operate certified ISO 27001 management systems while having different control environments.
A cloud-native software company with no physical data centre, a manufacturing company operating industrial environments and a financial institution with extensive third-party dependencies may face very different risks.
Their Statements of Applicability should reflect those differences.
If they all have essentially identical SoAs because somebody copied a template, that should prompt a question:
Where did the control decisions actually come from?
The SoA Is Not “Which Controls Do We Have?”
A common implementation mistake is to approach the SoA from the wrong direction.
The team starts with Annex A.
They work down the list.
Control 5.1: applicable.
Control 5.2: applicable.
Control 5.3: applicable.
Eventually almost everything is marked applicable because selecting “applicable” feels safer than explaining why something is not.
The resulting document may look thorough.
But it reverses the logic.
The organisation should start with its context and risks.
What information does it process?
What systems support critical operations?
What regulatory and contractual requirements apply?
What threats are relevant?
What could cause unacceptable business impact?
What risk treatments has management selected?
Which controls are necessary to support those treatments?
Annex A then provides a useful reference against which the organisation can validate its control coverage.
The SoA should therefore be an output of the management system, not the starting point for inventing one.
The Four Questions Behind Every SoA
A useful SoA should allow someone to answer four questions for each relevant Annex A control.
1. Is the control applicable?
If yes, it belongs within the organisation’s control framework.
If no, there should be a defensible justification.
2. Why is it applicable or not applicable?
The rationale should connect to the organisation’s context, risks, requirements or operating model.
“Not relevant” is rarely enough on its own.
3. How is the control implemented?
This is where many SoAs become weak.
A control being marked applicable does not demonstrate implementation.
The organisation should be able to identify the policy, process, technical mechanism, role or combination of measures through which the control is addressed.
4. Where is the evidence?
The SoA does not necessarily need to contain every piece of evidence itself.
But the organisation should be able to trace the control to the relevant implementation and supporting records.
This creates a chain:
Risk → Treatment → Control → Implementation → Evidence
The SoA sits in the middle of that chain.
The “Applicable” Checkbox Problem
There is a subtle danger in treating applicability as a binary checkbox.
Imagine an organisation marks a supplier security control as applicable.
That tells an auditor almost nothing.
The interesting question is what the organisation actually does.
Does procurement perform supplier due diligence?
Are security requirements incorporated into contracts?
Are critical suppliers classified differently from low-risk suppliers?
Are suppliers periodically reassessed?
Who owns the relationship?
What happens when a supplier fails to meet a requirement?
How are exceptions handled?
The control’s applicability is merely the beginning of the conversation.
The real value lies in the operational model behind it.
This is why a good SoA should never be considered in isolation from the processes and controls it represents.
Exclusions Are Not Automatically Bad
Another common misconception is that a mature organisation should have every Annex A control marked applicable.
That is not the objective.
Controls can be excluded when they are genuinely not applicable to the organisation, provided the exclusion is appropriately justified within the ISMS.
The important distinction is between “we do not need this control” and “we have not implemented this control yet.”
Those are completely different statements.
Suppose an organisation does not use removable media as part of its operational model.
That may provide a legitimate basis for determining that certain removable-media-related measures are not applicable.
Now consider an organisation that does use removable media but has not yet implemented the necessary controls.
That is not an applicability decision.
It is an implementation gap.
Trying to turn an implementation gap into an applicability exclusion is one of the easiest ways to make an SoA misleading.
The SoA and the Risk Register Must Agree
One of the most useful ways to test an SoA is to compare it with the risk register.
Imagine the risk register identifies:
Risk: Unauthorised access to customer information through compromised employee credentials.
The organisation’s treatment strategy involves strengthening identity and access management.
The SoA should then contain relevant controls addressing that treatment.
Now imagine the opposite.
The risk register identifies significant supplier-related risks.
The organisation relies heavily on external service providers.
But the SoA contains little meaningful treatment of supplier security.
That creates a potential disconnect.
It does not automatically mean the SoA is wrong. Controls can address risks in ways that are not obvious from a simple one-to-one mapping.
But it does mean someone should be able to explain the relationship.
A defensible ISMS should tell a coherent story.
The risks identified by the organisation should make sense alongside the controls it has selected.
The SoA and the ISMS Are Not the Same Thing
This distinction is worth making explicit.
The SoA is an important ISMS document.
It is not the ISMS.
You can have an immaculate SoA and a weak security management system.
The spreadsheet might accurately identify every applicable control while the underlying organisation fails to operate them effectively.
This is the same distinction between documentation and implementation.
The SoA describes the control architecture.
The organisation still has to make that architecture work.
Policies need to be followed.
Processes need to operate.
Technical controls need to be configured.
Responsibilities need to be understood.
Evidence needs to be generated.
Performance needs to be evaluated.
Corrective action needs to happen when controls fail.
The SoA is the map.
It is not the territory.
What Auditors Can See in a Good SoA
A strong SoA makes an auditor’s job easier because it provides a coherent explanation of the organisation’s control environment.
An auditor can start with an applicable control and ask:
How did you determine this was necessary?
How is it implemented?
Who owns it?
Show me how it operates.
What evidence demonstrates that?
Then the auditor can follow the trail into the organisation’s actual processes.
The opposite situation is much less comfortable.
The SoA says a control is applicable.
The policy exists.
But nobody can explain who operates it.
Or the policy says one thing while the operational process does another.
Or the organisation has implemented a technical mechanism but has never defined its governance.
Or the control exists but there is no evidence that it has operated consistently.
In those circumstances, the SoA has become a catalogue of claims rather than a useful representation of the ISMS.
Build the SoA From Decisions, Not Templates
There is a practical implementation lesson here.
Do not begin by downloading an SoA template and filling in 93 controls.
Begin with the organisation.
Understand its context.
Establish the scope of the ISMS.
Identify information assets and critical processes.
Perform the risk assessment.
Determine the risk treatment approach.
Identify the controls required to support those treatments.
Then use Annex A as a reference set to validate that the control environment has not overlooked relevant measures.
Only then should the SoA be finalised.
This sequence also makes the document easier to defend.
When someone asks why a control is applicable, there is a chain of reasoning behind the answer.
When someone asks why another control was excluded, there is an organisational reason.
When someone asks how an applicable control is implemented, the answer leads to an actual process or technical mechanism.
The document becomes a reflection of governance rather than an exercise in document completion.
Keep the SoA Operationally Useful
There is another temptation worth avoiding: turning the SoA into a giant evidence repository.
That can make it unwieldy.
The purpose of the document is to maintain a controlled representation of control applicability, justification and implementation.
Supporting evidence can remain in the systems and repositories where the underlying activity actually occurs.
For example, an access-management control might point toward the relevant access-management procedure and operational system rather than embedding every access review into the SoA.
This keeps the SoA maintainable.
It also reinforces an important principle:
The SoA should point toward the control environment, not attempt to become the control environment.
If updating one technical process requires manually editing several spreadsheets and policy documents, the governance architecture is probably too disconnected.
A Practical SoA Quality Test
Take any ten controls from your SoA and try to trace them through the organisation.
For each one, ask:
Applicability: Why does this control matter here?
Ownership: Who is accountable for it?
Implementation: What actually performs the control?
Evidence: What demonstrates that it operates?
Risk connection: Which risks or requirements does it help address?
Effectiveness: How does the organisation know it is working as intended?
If the answers are immediate and consistent, the SoA is probably doing its job.
If the answers require searching through multiple disconnected documents or asking several people who ultimately say “I think Security handles that”, the SoA has exposed a governance weakness.
That is useful information.
The objective is not to make the spreadsheet look perfect.
The objective is to make the underlying control environment understandable and defensible.
The SoA as an Executive Document
Executives rarely need to read all 93 controls.
But they should understand what the SoA represents.
It provides management with a structured view of the organisation’s security control decisions.
It can help answer questions such as:
Which controls are considered necessary?
Which controls remain under implementation?
Where are significant gaps?
Which risks are being treated?
Which risks are being accepted?
Where does the organisation depend on third parties?
Which areas require additional investment?
That makes the SoA potentially valuable beyond certification.
It can become part of the governance conversation between security, operational leadership and management.
But only if it reflects reality.
An SoA that exists solely because an auditor expects one has limited strategic value.
An SoA that connects risk decisions to operational controls can become a useful management instrument.
Executive takeaway
Do not treat the Statement of Applicability as the document that proves you have implemented ISO 27001.
Treat it as the document that explains why your control environment looks the way it does.
A defensible SoA connects organisational context and risk treatment to control selection, implementation and evidence.
It should be possible to move in both directions:
From a risk to the controls addressing it.
And from a control back to the reason the organisation decided it was necessary.
That is what makes the Statement of Applicability more than an Annex A checklist.
The SoA should not merely tell an auditor what controls you selected. It should allow the organisation itself to explain why those controls exist.