Statement of Applicability walkthrough for first-time implementers

If you are implementing an ISO 27001-aligned information security management system, the Statement of Applicability, often shortened to SoA, can feel like one of the more formal documents in the set. In practice, it is much simpler than it first appears. For a UK SME, the SoA is the place where you show which security controls you have chosen to use, which ones you have not used, and why.

That makes it more than a compliance document. It is a decision record. It helps you explain how your organisation has turned risk assessment outcomes into practical security measures. It also gives you a single place to check whether your controls still make sense as your business changes.

First-time implementers often overthink the SoA. They assume it needs to be long, technical, and heavily formalised. It does not. It needs to be clear, consistent, and tailored to your business. If it is useful to you, it is much more likely to be useful to everyone else who needs to understand your ISMS.

What the Statement of Applicability is and why it matters

Plain-English definition for UK SMEs

The Statement of Applicability is a list of the security controls you have considered for your ISMS, together with a note on whether each control applies to your organisation. If it does apply, you explain how you have implemented it. If it does not apply, you explain why.

Think of it as a structured answer to three questions: what have we chosen, what have we left out, and what is our reasoning? That is useful because security programmes can easily become a collection of disconnected activities. The SoA brings those decisions together in one place.

For a small organisation, this is especially helpful. You may not have a dedicated security team, and responsibilities may sit with a founder, operations lead, IT provider, or finance manager. A well-written SoA gives those people a shared reference point.

How it fits into an ISO 27001-aligned ISMS

An information security management system, or ISMS, is the set of policies, processes, people, and controls you use to manage information security in a repeatable way. The SoA sits inside that system as a bridge between risk assessment and control implementation.

In simple terms, your risk assessment tells you what matters and what could go wrong. Your treatment decisions tell you how you intend to address those risks. The SoA then records the controls you have selected to support those decisions. It is not the risk assessment itself, and it is not a policy document. It is the record of what you decided to do about security risk.

That distinction matters. If the SoA is treated as a standalone form, it quickly becomes stale. If it is treated as part of the wider ISMS, it stays connected to the business reality behind it.

What first-time implementers should include

How to list Annex A controls at a practical level

For most first-time implementers, the starting point is the control set you are using as a reference for your ISMS. The practical task is to go through the controls one by one and decide whether each one is relevant to your organisation.

You do not need to write a technical essay for every control. A short, plain-English summary is usually enough. For example, if a control relates to access management, you might note that user access is granted through a central process, reviewed periodically, and removed when staff leave. If a control is not relevant, you should still record it and explain why.

The key is consistency. Use the same style of wording throughout the document so that it is easy to read and easy to maintain. Avoid vague phrases such as “covered elsewhere” unless you clearly state where that is and who owns it.

How to record inclusion, exclusion, and justification

Each control should have a clear status. In practice, that usually means one of three outcomes: applicable and implemented, applicable but not yet fully implemented, or not applicable. The exact labels are less important than the clarity of the reasoning.

When you include a control, explain the current approach and, where useful, point to the policy, procedure, or system that supports it. When you exclude a control, give a business reason rather than a generic one. For example, “not applicable because we do not operate physical premises with customer data processing” is more useful than “not relevant”.

Justification should be proportionate. A small organisation does not need a long narrative for every line item. It does need enough detail for a reader to understand the decision and see that it was made deliberately, not copied from a template.

How to decide which controls are relevant

Using risk assessment outcomes to inform the SoA

The best way to decide whether a control belongs in the SoA is to start with your risks. Ask what information you hold, how it is used, what could harm it, and what would happen if a control were missing. That gives you a practical basis for inclusion or exclusion.

For example, if your business relies on cloud services, remote working, and a small number of privileged accounts, then controls around identity management, supplier oversight, and secure administration are likely to matter. If you have no on-site server room, then controls focused on that environment may not be relevant in the same way.

This is where the SoA becomes genuinely useful. It shows that your security decisions are linked to your actual operating model. That helps you avoid two common problems: over-engineering controls that add little value, and overlooking controls that address real exposure.

It also helps to remember that relevance is not the same as perfection. A control can be relevant even if you are still improving how it works. In that case, the SoA should reflect the current position honestly, along with the direction of travel.

Keeping the document proportionate for smaller organisations

Smaller organisations often have limited time and limited internal resource, so the SoA should be practical to maintain. A document that is too detailed becomes a burden. A document that is too thin becomes unhelpful. The right balance is usually somewhere in the middle.

One useful approach is to keep the wording concise, but make the supporting evidence easy to find. For example, the SoA can reference the policy, process, register, or technical setting that demonstrates how the control is handled. That keeps the document readable without losing traceability.

Proportionate does not mean superficial. It means the level of detail matches the size, complexity, and risk profile of the organisation. A ten-person consultancy and a multi-site manufacturer will not need the same level of explanation, even if they are both working towards an ISO 27001-aligned ISMS.

Common mistakes to avoid

Treating the SoA as a paperwork exercise

The most common mistake is to write the SoA as if it were a form to complete once and file away. That creates a document that looks neat but does not help the business manage risk. If the SoA is disconnected from real decisions, it will not support day-to-day governance.

A better approach is to treat it as part of the management system. Use it to support conversations about risk, ownership, and priorities. If a control is marked as applicable, someone should know who owns it and how it is maintained. If a control is excluded, the reasoning should still stand up to internal challenge.

This is not about creating bureaucracy. It is about making sure the organisation can explain its security choices in a way that is clear and defensible.

Copying generic templates without tailoring them

Templates can be a useful starting point, but they are not a substitute for judgement. A copied SoA often contains controls that do not fit the business, descriptions that do not match reality, or justifications that sound polished but do not say very much.

That can create avoidable work later. When systems change, suppliers change, or staff responsibilities move around, a generic document is harder to update because it was never closely tied to the organisation in the first place.

If you use a template, tailor it to your actual environment. Check that the controls reflect your services, locations, technology, suppliers, and operating model. The more closely the SoA matches reality, the more useful it will be for reviews and internal discussions.

How to keep the SoA useful over time

Linking the SoA to evidence, owners, and review cycles

A good SoA is easy to maintain because it is connected to the rest of the ISMS. Each control should have a clear owner, a source of evidence, and a review point. That might be a policy review, a management review, a supplier review, or a periodic control check.

Evidence does not need to be complicated. It might be a policy, a ticketing record, a training log, a supplier agreement, a system setting, or a report from a recurring process. What matters is that you can show the control is not just described, but actually in use.

Review cycles should be realistic. For many SMEs, an annual review is a sensible baseline, with additional updates when something significant changes. The important point is not the calendar date alone, but whether the document still reflects how the organisation operates.

Updating it when risks, systems, or suppliers change

The SoA should change when the business changes. If you adopt a new platform, outsource a service, open a new site, change your remote working model, or bring in a new supplier, those changes may affect which controls are relevant and how they are implemented.

It is also worth revisiting the SoA after incidents, near misses, or internal reviews. Those events often reveal where a control is weaker than expected or where a justification no longer holds. Updating the document at that point keeps it aligned to reality.

For SMEs, this does not need to be a heavy process. A short review meeting, a simple change log, and a clear owner for updates can be enough to keep the SoA current.

A simple approach for SMEs

Building a workable first version without overcomplicating it

If you are starting from scratch, aim for a first version that is accurate rather than perfect. Begin with the controls you have already considered through your risk assessment and treatment planning. Then work through the rest in a structured way, recording a clear decision for each one.

A practical first version usually has four elements for each control: the control name or reference, whether it applies, a short justification, and a note on implementation or evidence. That is enough to create a usable baseline without turning the exercise into a documentation project.

Once the first version exists, improve it over time. Add clarity where needed, remove duplication, and make sure the wording matches your actual processes. The goal is a document that helps you manage security, not one that simply looks complete.

When to seek advisory support

Many SMEs can produce a sensible first draft internally, especially if they already have a clear view of their risks and systems. Advisory support becomes useful when the organisation has several suppliers, a mixed technology estate, limited internal security experience, or uncertainty about how to make the document proportionate.

External support can also help when you want a second pair of eyes on whether the SoA is consistent with the rest of the ISMS. That is often where first-time implementers benefit most: not from having the work done for them, but from having the structure checked and the reasoning sharpened.

If you would like practical help shaping an ISO 27001-aligned ISMS for a UK SME, including a Statement of Applicability that is tailored to your business, speak to a consultant. The aim should be a document that supports decision-making, not just a document that sits in a folder.

Frequently asked questions

What is the Statement of Applicability in simple terms?

It is a record of which security controls you have chosen to use in your ISMS, which ones you have not used, and why. For a first-time implementer, it is best understood as a decision log that links risk assessment to practical security controls.

How often should a Statement of Applicability be reviewed?

It should be reviewed regularly and whenever something material changes, such as a new system, supplier, location, or risk. For many SMEs, an annual review works well as a baseline, provided it is also updated when the business changes in between formal reviews.

In summary

The Statement of Applicability is one of the most useful documents in an ISO 27001-aligned ISMS when it is written well. For UK SMEs, the priority is not to make it elaborate. The priority is to make it clear, proportionate, and tied to real business decisions.

If you keep the focus on relevance, justification, ownership, and review, the SoA becomes a practical tool rather than a compliance burden. That is usually the point at which it starts to add real value.

The post Statement of Applicability walkthrough for first-time implementers appeared first on Clear Path Security Ltd.

*** This is a Security Bloggers Network syndicated blog from Clear Path Security Ltd authored by Clear Path Security Ltd. Read the original post at: https://clearpathsecurity.co.uk/statement-of-applicability-walkthrough-for-first-time-implementers/