ISO 27001 Statement of Applicability Template – What It Should Actually Include
When people search for an ISO 27001 Statement of Applicability template, they are usually a bit further into the process than someone looking for a general ISO 27001 checklist.
By the time they get to this stage, they have normally realised that ISO 27001 is not just about writing policies or downloading a few security documents. They have come across the requirement to justify which controls apply to their organisation, and they want to know what that document is supposed to look like in practice.
That is where the Statement of Applicability, usually shortened to SoA, becomes one of the most important documents in the whole information security management system.
It is also one of the documents that people often misunderstand.
Some businesses treat it as a compliance list. Others treat it as a technical control schedule. Others copy a generic version and change very little. None of those approaches is especially helpful on its own.
The SoA is meant to show which controls have been selected, whether they apply, and why. In other words, it is the bridge between your risk assessment and the control framework you are actually using.
What an ISO 27001 Statement of Applicability template should actually include
A usable ISO 27001 Statement of Applicability template should do more than list Annex A controls in order. It should help the organisation explain, in a structured and consistent way, whether each control is applicable and how that decision was reached.
In practice, most organisations will want the template to include the control reference, the control title, whether the control is applicable, the justification for inclusion or exclusion, and in many cases a note showing how the control is implemented through policies, procedures, technical measures, or other supporting arrangements.
Depending on the business, there may also be templates relating to waste management, emergency preparedness and response, contractor controls, inspections, monitoring results, maintenance, spill response, or environmental checks linked to vehicles, equipment or site activities.
So the real answer is not just “what templates do I need?” but “what documents do I need to control the environmental issues that actually matter in my business?”
The templates most organisations commonly use
Auditors do not normally want to see a Statement of Applicability that has simply been copied from a template pack with every control marked as applicable and no real explanation behind it.
What they usually want to understand is whether the SoA is grounded in the organisation’s actual information security risks and working practices.
If a control is shown as applicable, the auditor will often want to see how that control is actually implemented. If a control is shown as not applicable, the auditor will want to understand why that decision makes sense in the context of the organisation.
For example, if a business marks a control relating to a specific activity as not applicable, there should be a clear and credible reason. Equally, if a control is marked as applicable, there should usually be some link to the policies, procedures, registers, technical settings, reviews or evidence that support it.
This is why a good SoA is not just a document to satisfy the standard. It is a working reference point for the system.
How the Statement of Applicability links to the rest of the ISMS
The SoA should not sit on its own.
It should connect directly to your ISO 27001 risk assessment template, because the decision to include or exclude controls should be grounded in the risks the organisation has identified. It should also align with the wider ISO 27001 documentation kit, because the controls listed in the SoA usually connect to multiple other parts of the system.
For example, a control about access management may link to policies, onboarding and offboarding arrangements, access reviews, technical settings and audit records. A control about backup may link to backup procedures, testing records, recovery arrangements and technical monitoring. A control about supplier security may link to supplier reviews, contractual clauses and approval processes.
This is why the Statement of Applicability is often one of the best documents for understanding whether the system actually hangs together. If the SoA is weak, inconsistent or obviously generic, the rest of the system often starts to look weak as well.
A good SoA entry in practice
A good entry in the SoA is clear enough that someone else could understand the decision without guessing.
For example, if a control is applicable, the justification should explain why it is relevant to the organisation, not just say “required by ISO 27001.” That is not really a justification. It is just a restatement of the fact that the control exists.
Likewise, if a control is not applicable, the justification should explain why the activity, risk, or operational context that would normally make the control relevant does not apply to this organisation.
The point is not to write long essays for every control. The point is to make the document credible and usable.
That is the difference between a Statement of Applicability that simply exists and one that genuinely supports the management system.
Where businesses often go wrong
One common mistake is marking every control as applicable without properly considering whether the justification is strong enough or whether the implementation really exists.
Another mistake is using vague justification wording over and over again. If every line says something like “included for information security purposes,” the document quickly starts to lose value.
A third mistake is disconnecting the SoA from the rest of the system. If the SoA says a control is applicable but there is no policy, no process, no technical measure and no evidence behind it, the document becomes difficult to defend.
Some businesses also treat the SoA as a one-off exercise done near certification and then largely ignored. In reality, it should remain a live document. If risks change, scope changes, technology changes, or the organisation’s working practices change, the SoA may need to be reviewed and updated as well.
What a usable ISO 27001 Statement of Applicability template should look like
A usable SoA template should be structured, readable and easy to maintain. It should make it obvious which control is being referred to, whether it applies, and why the organisation has made that decision.
It should also be easy to trace from that control to the relevant implementation documents or activities where needed. That does not mean it needs to become overcomplicated. It just means it should support explanation and accountability rather than functioning as a bare checklist.
For many organisations, the most useful SoA is one that can be read by senior management, operational staff and auditors without needing a huge amount of interpretation. If it is too thin, it becomes generic. If it is too heavy, it becomes difficult to keep current. The best balance is usually somewhere in the middle.
If you want a complete, working system rather than just a template
This is where many organisations reach the same point. They start by searching for an ISO 27001 Statement of Applicability template, but what they really need is not just a single document. They need a structured way of connecting controls, risks, supporting documents and evidence.
If you want a complete, working system rather than disconnected templates
That is exactly where The Compliance Companion is designed to help. Instead of giving you a random collection of templates to piece together yourself, it provides a structured system that helps align policies, registers, action logs and supporting documents in a practical way.
If you are at the stage where you are trying to work out what ISO 27001 documents you actually need, and how they should fit together, that is usually the point where a proper framework becomes far more valuable than another generic download.