---

Introduction

At the end of ISO 27001, Annex A has 93 controls grouped as Organisational (37), People (8), Physical (14), and Technological (34). It’s these controls that we must capture in the Statement of Applicability and address, one by one.

Organisations need to review each control and respond with how they will address it. The response is maintained in the SoA.

If a control is deemed as ‘not applicable’ (i.e. doesn’t apply to your business), then you mark it down as such in the document, but must give a justification as to why. A good example might be some of the controls in software development – so if you aren’t doing any, any control directly related to development (secure practices, for example) can be marked as ‘not applicable’.

Every organisation will complete its SoA based on its scope, risk appetite, and maturity. So, it won’t be the same for a small company just starting out, vs a multinational pharma company. They have very different DNA and, therefore, different responses in their SoA documents.

---

What’s Expected in a Statement of Applicability

A clear, single source of truth that anyone in audit or management can read and understand at a glance.

The SoA must contain;

• Control ID & title (from Annex A)
• Included? (Yes/No)
• Justification (for inclusion or exclusion)
• Status (Implemented / Partially implemented / Not implemented)

It’s then recommended that you also include;

• Owner (accountable person)
• Evidence/reference (policy/procedure, ticket, config, repo link)
• Links to the risk assessment and risk treatment plan

These things make management of the controls a bit easier, but you can add any additional columns you wish.

Here’s an example of what the statement of applicability in ISO 27001 normally looks like;

---

I have included a completed Statement of Applicability in my information security toolkit below that you can tailor to your needs.

How to build a SoA

I’d suggest that you don’t start your SoA until you’ve confirmed your scope and the context of the organisation, so that you know what influences your ISMS. After that, hold a workshop on big-ticket risks that keep you awake at night around information security. With these things documented, you can shape your SoA much more effectively than if you jump straight in.

Then to construct your SoA, I suggest the following steps;

1. Break the SoA into ‘doable’ chunks. If you sit down and try to run through the entire thing in one go, you’ll lose the will to live, so I think you should break it into either families (which are more organisational and technological in focus) or groups of 20 or so at a time.
2. Sit with your team and discuss the controls. Working on the SoA by yourself is fine in a micro-organisation, but not when you are working as part of a wider team. Discussing the controls, what’s appropriate given your risk appetite, and how you want to approach things always produces better results when you do it collaboratively.
3. Identify any control you think is out of scope for your organisation, and mark it as ‘not applicable’. However, don’t try to simply skip controls and mark them all as being out of scope. You can only skip them if you have a strong, documented justification.
4. For each control, determine your minimum viable compliance position. Ask yourself, “How do we meet these controls, simply, and in alignment with our risk appetite – without overdoing it?” You don’t need to implement fancy software and tools for the sake of it, but you do need to implement the control appropriately. And who determines what ‘appropriate’ is? You.
5. Link each control to supporting evidence, such as a policy or procedure. This isn’t required, but it makes life a lot easier during audits when you can link the control directly to an example of its implementation.

You’ll probably take a few passes through the SoA before you’re happy with it. There may be areas of overlap where you need to align things and ensure there are no contradictions.

---

ISO 27002

It’s important to understand that there is a supporting standard, ISO 27002, which guides the implementation of the controls in ISO 27001.

ISO 27002 isn’t mandatory – so you don’t have to implement everything it says, but it does provide a reference guide for what good looks like, and something that auditors will be familiar with when they are looking at controls.

So, for example, let’s take control 5.12 from Annex A in ISO 27001.

I’ve documented my take on each of the controls in Annex A here;

---

What auditors actually check

In the stage one audit, they’ll fly through the SoA quickly and spot-check a few things. They don’t normally have the time to dive deep. However, in a stage two audit, the auditors will likely spend quite a bit of time reviewing the details of the SoA controls.

What are they actually looking for?

Well, a few things, but typically;

• Traceability from risks → treatment plans → selected controls → status
• Clear rationales for every exclusion (no hand-waving)
• Consistency with reality (evidence and interviews match the SoA)
• Alignment with the scope and the assets/processes you claim to protect
• Change control (versions, approvals, recent updates)

It’s not for an auditor to say if the control is technically sound – they are there to review how you have said you have implemented the control based upon your risk assessment, then look at the supporting evidence.

---

Common mistakes (and easy fixes)

1) Vague justifications for exclusions
If you mark a control “N/A” without saying exactly why, an auditor can’t see your logic and will probe until they can.
How to avoid it: State the concrete reason the control doesn’t apply (scope, technology choice, operating model) and point to the risk/requirement you considered.
Weak: “N/A — not relevant.”
Better: “N/A — we have no on-premise infrastructure; all facilities are co-location with provider physical security, assured via supplier due diligence (SR-12) and contract §4.3.”

2) Putting suppliers out of scope
Cloud and third parties don’t remove your obligations; they change them. Excluding supplier-related controls leaves a gap.
How to avoid it: Keep supplier risk clearly in scope. Use the supplier controls (e.g., due diligence, contracts, monitoring) and reference the evidence you hold (assurance reports, security schedules, SLAs).
Example wording: “Included due to use of critical SaaS and IaaS providers. See Supplier Register (SR-##), DPAs, and quarterly monitoring logs.”

3) Copy-pasting all controls as “Yes”
A blanket “Yes” suggests a tick-box approach and often won’t align with your risk treatment plan.
How to avoid it: Include a control when a risk, legal/contractual duty, or business need demands it. If it’s not applicable, say so clearly. If it’s partially implemented, say that (with a target date).
Tip: Let your risk register drive inclusions; let your scope drive exclusions.

4) Drifting status (stale SoA)
An SoA that doesn’t reflect reality creates audit friction (and sometimes nonconformities).
How to avoid it: Put the SoA under change control with an owner. Review it quarterly or at Management Review, and after material changes (new product, new supplier, incident lessons learned). Show status as Implemented / Partially implemented / Planned with target dates and owners.

5) Mismatch with scope
If your scope says one thing and your SoA implies another, auditors will challenge both.
How to avoid it: Place the scope statement at the top of the SoA and update them together. Where a control decision relies on a scoping assumption (e.g., “no in-scope end-user devices”), state that assumption in the justification.

6) Hiding non-Annex A controls
If you use extra controls (e.g., a bespoke monitoring rule or a contractual safeguard) but don’t show them, your risk treatment looks incomplete.
How to avoid it: Add a short “Additional controls” section or flag them in your table with the same fields (reason, status, owner, evidence). Auditors just need to see how the risk is being treated, even if the control isn’t in Annex A.

---

Maintenance triggers

You’ll need to review the SoA at least annually, or any time there are major changes that potentially impact your controls, such as:

• new or decommissioned systems, vendors, or locations;
• material incidents or near-misses;
• changes in legal/regulatory/contractual duties;
• audit findings or risk re-scoring; or
• organisational restructures affecting ownership.

---

FAQs