Statement of Applicability (SoA) Review Guide for ISO 27001

The Statement of Applicability is the single document that tells an auditor what your information security programme actually claims to do. It maps every Annex A control to a decision: applicable or not, implemented or not, and why. Get it right and the rest of the audit runs on rails. Get it wrong and every finding traces back to it.

What the SoA is and why auditors read it first

The Statement of Applicability is a mandatory output of ISO/IEC 27001. Clause 6.1.3 requires it. It lists the Annex A controls, records whether each one applies to your organisation, states whether it is implemented, and gives the justification for both decisions.

Auditors open the SoA first because it is the fastest way to understand your scope and your intentions. It is a table of contents for the entire management system. From it, an auditor picks the controls they want to test, decides where to spend their time, and forms an early view of how honest and mature your programme is.

A vague or copied SoA signals a vague or copied programme. A precise SoA that reflects your real environment tells the auditor you understand your own risk. That first impression shapes the tone of everything that follows. You are not just documenting controls. You are demonstrating that you thought about them.

The chain: risk assessment to SoA to evidence

The SoA does not stand alone. It sits in the middle of a chain that an auditor will walk end to end.

Your risk assessment identifies risks to the confidentiality, integrity and availability of information in scope. Your risk treatment decides how to handle each risk, usually by selecting controls. The SoA records which controls you selected and confirms you compared them against Annex A so nothing was missed. Your evidence then proves those controls exist and operate.

Read forward, the chain says: we found these risks, so we chose these controls, and here is proof they work. Read backward, an auditor can take any piece of evidence and ask which control it supports, which risk that control treats, and whether the SoA agrees. If any link breaks, the audit exposes it.

This is the mental model to hold during a review. The SoA is not a form to complete. It is the hinge between what you decided and what you can show.

How to decide applicability honestly

Applicability is a judgement, not a default. A control is applicable when it treats a risk you have identified, when a legal, regulatory or contractual obligation requires it, or when a business need calls for it.

The honest test is simple. Can you name the reason this control is in or out without referring to a template? For a payment or SaaS company, most Annex A controls will be applicable, because the risks they address are real for you. That is expected. What matters is that applicability follows from your environment, not from a wish to look complete.

Resist two temptations. The first is marking everything applicable to appear thorough. The second is marking controls not applicable to reduce workload. Both replace judgement with convenience, and an auditor will probe exactly the entries that look too convenient.

Writing justifications that reference your real environment

The justification is where most SoAs fail. A strong justification is specific to your organisation. A weak one could belong to any company.

For an applicable, implemented control, the justification should point at how you actually meet it. Name the system, the process or the policy. "Access to production is granted through our identity provider with role-based groups reviewed quarterly" tells an auditor what to test. "Access is controlled" tells them nothing.

Good versus weak justifications

A weak justification restates the control. Annex A asks for access restriction, and the SoA says access is restricted. That is a circular sentence. A good justification describes the mechanism in your environment, so the auditor already knows where to look for evidence before they ask.

You do not need a paragraph. One or two precise sentences that reference the real control usually beat a long generic one. Write for the reader who will verify it, not for the reader who will skim it.

Handling exclusions defensibly

Marking a control not applicable is legitimate. Doing it without a defensible reason is not.

The classic example is physical controls for a fully cloud-hosted company. If you run no data centres and hold no on-premise infrastructure, some physical Annex A controls may not apply to your own facilities. But be careful. The risk does not disappear. It transfers to your cloud provider, and you now rely on their controls. That reliance is itself something you manage through supplier controls, and your SoA should reflect that shift rather than pretend the risk is gone.

A defensible exclusion states the fact, the reasoning, and where the risk went. "We operate no physical data centre facilities; hosting is provided by [provider] under our supplier assurance process; physical security is addressed through their certifications, reviewed annually" is defensible. "Not applicable" alone is not.

Remote and hybrid working has narrowed the set of controls a modern company can safely exclude. Home working, endpoint security and physical media still create physical and environmental risk even without an office. Exclude with care and document the logic.

The ISO/IEC 27001:2022 Annex A structure

The 2022 revision reorganised Annex A into 93 controls across four themes. If your SoA still follows the older 114-control, fourteen-domain layout, that is an early sign it needs updating.

Organizational controls

This is the largest theme, covering policies, roles, supplier relationships, threat intelligence, information classification, and incident management planning. For most SaaS and fintech companies this is where the substance of the programme lives, and where auditors find the most to test.

People controls

These address screening, terms of employment, awareness and training, disciplinary process, and responsibilities after employment ends. They connect information security to how you hire, manage and offboard staff. Small companies often under-document these because the processes are informal, but the controls still apply.

Physical controls

These cover secure areas, equipment, media, and clear desk and screen practices. Cloud-native companies scope these carefully, but rarely exclude them entirely, because staff still use devices and handle information outside a data centre.

Technological controls

This theme covers the technical measures your engineering teams recognise: access control, cryptography, logging and monitoring, secure development, configuration management, and data leakage prevention. The 2022 revision added controls that matter for modern SaaS, including web filtering, secure coding and data masking. These are the controls where the SoA and reality most often drift apart, because engineering moves faster than documentation.

Common SoA mistakes

Certain patterns appear again and again. Each one is visible to an experienced auditor within minutes.

Everything applicable and implemented

An SoA where every control is applicable and every control is fully implemented is rarely true for a growing company. It usually means the SoA was filled in aspirationally. Auditors treat a perfect SoA as a prompt to find the gap between the claim and the evidence, and there is almost always a gap.

Templated justifications

Identical or near-identical justifications across many controls reveal that the text was pasted, not written. If your justification for logging reads the same as your justification for cryptography, neither is real. Templates are a useful starting point. Leaving them untouched is the mistake.

SoA and risk assessment mismatch

The SoA must agree with your risk assessment. If a control is applicable but treats no identified risk, either the risk assessment is incomplete or the control was selected without reason. If a risk is treated by a control marked not applicable, the two documents contradict each other. Auditors cross-check these deliberately.

SoA and reality mismatch

The most damaging mistake is an SoA that describes a company you are not. It claims a control is implemented when the process lapsed, the tool was decommissioned, or the policy was never followed. This is where the SoA meets evidence, and where confident claims collapse under a single request to "show me." Reality always wins in an audit.

A step-by-step SoA review method

Review the SoA as an auditor would, not as the author who wrote it.

1. Confirm the version and structure. Verify it uses the ISO/IEC 27001:2022 Annex A set of 93 controls across the four themes.

2. Check completeness. Every Annex A control should have an applicability decision, an implementation status, and a justification. No blanks.

3. Trace applicability back to risk. For a sample of applicable controls, find the risk they treat in the risk assessment. For any not applicable, confirm the reasoning holds and the risk is accounted for.

4. Read justifications for specificity. Flag anything generic, circular or duplicated. A justification that could belong to any company is a justification that needs rewriting.

5. Test implemented claims against evidence. Pick controls marked implemented and ask for the artefact. A policy, a config, a log, a ticket. If the evidence is missing or stale, the status is wrong.

6. Scrutinise exclusions. For each not applicable, confirm the fact, the reasoning, and where the risk transferred. Pay particular attention to physical and supplier controls.

7. Check internal consistency. The SoA, risk assessment, risk treatment plan and policies must tell the same story. Reconcile any contradiction before the auditor finds it.

8. Confirm ownership and dates. Each control area should have an owner, and the SoA should show recent review. A document last touched two years ago has drifted.

SoA review checklist

Use this as a final pass before an audit or as a periodic health check.

• The SoA uses the 2022 Annex A structure and all 93 controls are present.
• Every control has an applicability decision, implementation status and justification.
• Applicable controls map to identified risks in the risk assessment.
• Justifications reference specific systems, processes or policies in your environment.
• No two justifications are identical unless the controls genuinely share a mechanism.
• Every not applicable control has a defensible reason and accounts for the underlying risk.
• Physical and supplier controls are handled with care, not excluded by default.
• Implemented claims are backed by evidence you can produce on request.
• The SoA agrees with the risk assessment, risk treatment plan and policies.
• Each control area has a named owner and a recent review date.

Bottom line

The SoA is the most revealing document in your management system. It shows an auditor how well you understand your own risk, how honestly you assess your controls, and whether your claims survive contact with evidence. A precise, specific, internally consistent SoA earns trust. A copied or aspirational one invites scrutiny you do not want.

Review it the way an auditor will: applicability grounded in real risk, justifications that name your real environment, exclusions that account for transferred risk, and every implemented claim backed by something you can show. If you would like a second, senior pair of eyes before your audit, Kellwick runs independent SoA and readiness reviews that test your Statement of Applicability against your risk assessment and your evidence, so you find the gaps before an auditor does.