ISO 27001 Statement of Applicability: A Practical Guide for 2026

If you are working towards ISO/IEC 27001 certification, few documents get more attention from auditors than the Statement of Applicability. It is the single place where your organisation shows which information security controls it has chosen, why it has chosen them and how far it has got with implementing them.

Done well, the SoA ties your risk assessment, your risk treatment plan and your day-to-day controls into one coherent story. Done badly, it becomes a spreadsheet of ticked boxes that falls apart at the first auditor question.

This guide explains what ISO/IEC 27001:2022 actually requires, how the 93 Annex A controls are organised, what auditors look for and how to build an SoA step by step, along with the most common mistakes to avoid.

What is an SoA and who needs one?

The SoA is a mandatory document for any organisation that wants to certify an information security management system (ISMS) against ISO/IEC 27001:2022. There is no way to be certified without one.

It applies to organisations of every size and sector, from start-ups selling software to large enterprises, public bodies and managed service providers. The content will differ enormously between them, because the SoA reflects each organisation’s own risks, scope and obligations. That is the point: it is not a generic template but a record of decisions.

The SoA also matters beyond certification. Customers, partners and procurement teams often ask to see it, or a summary of it, alongside your certificate, because it tells readers what your certification really covers.

What clause 6.1.3 d) requires

The requirement sits in clause 6.1.3, information security risk treatment. After selecting risk treatment options and determining the controls needed to implement them, the organisation must produce an SoA that contains:

• The necessary controls, as determined through the risk treatment process in clauses 6.1.3 b) and c).
• Justification for their inclusion. Why each control is needed.
• Whether the necessary controls are implemented or not. The current implementation status.
• Justification for excluding any of the Annex A controls. Why a control listed in Annex A is not needed.

Two related requirements shape how the SoA is built. Clause 6.1.3 c) asks you to compare the controls you have determined with those in Annex A, to check that no necessary controls have been omitted. And the standard makes clear that Annex A is not exhaustive: you can, and sometimes should, add controls from other sources, such as sector rules or customer contracts.

The 93 Annex A controls in four themes

The 2022 edition restructured Annex A. The 114 controls in 14 domains of the 2013 version were consolidated into 93 controls grouped into four themes:

• Organisational controls (5.1 to 5.37): 37 controls covering policies, roles, asset management, access control, supplier relationships, incident management, business continuity and compliance.
• People controls (6.1 to 6.8): 8 controls covering screening, terms of employment, awareness and training, disciplinary process, remote working and event reporting.
• Physical controls (7.1 to 7.14): 14 controls covering perimeters, entry, secure areas, equipment, storage media and clear desk rules.
• Technological controls (8.1 to 8.34): 34 controls covering endpoints, privileged access, malware protection, logging, network security, cryptography and secure development.

Eleven controls were new in 2022, including threat intelligence (5.7), information security for use of cloud services (5.23), ICT readiness for business continuity (5.30), configuration management (8.9), data leakage prevention (8.12), web filtering (8.23) and secure coding (8.28). These are worth particular attention, because older SoAs converted from the 2013 layout sometimes treat them superficially.

The transition period for certificates issued against the 2013 edition ended in October 2025, so by now every current certificate should be backed by an SoA structured around the 2022 controls.

Justifications, status and the link to risk treatment

Justifying inclusion

Every included control needs a reason. The strongest justifications point to specific sources:

• Risk treatment: the control treats one or more risks identified in your risk assessment. Reference the risk IDs.
• Legal and regulatory requirements: for example, data protection law or sector rules such as NIS2 or DORA.
• Contractual obligations: customer contracts or security schedules that require the control.
• Business requirements: internal decisions, such as a group policy that applies to every subsidiary.

Justifying exclusion

Exclusions are allowed, but they must be credible. A good exclusion explains why the control is not needed given your scope and risks, for example “We do not develop software in scope; all applications are commercial SaaS, so 8.28 secure coding does not apply.” Weak exclusions such as “not relevant” or “too costly” will not survive an audit, and cost alone is rarely an acceptable reason to leave out a control that treats a real risk.

Recording implementation status

The standard only requires you to say whether each control is implemented or not. In practice, many organisations use a small set of statuses such as implemented, partially implemented and planned, with a target date for anything not yet complete. Whatever scheme you use, keep it simple and consistent.

Connecting to the risk treatment plan

The SoA and the risk treatment plan (required by clause 6.1.3 e)) are two views of the same decisions. The treatment plan says what will be done about each risk, by whom and by when. The SoA says which controls result and where they stand. If a control is marked “planned” in the SoA, there should be a matching action in the treatment plan, and vice versa.

What auditors look for in a Statement of Applicability

Certification auditors use the SoA as a map for the rest of the audit. Expect them to check:

• Completeness. All 93 Annex A controls are addressed, with each one either included or excluded, plus any additional controls you have added.
• Traceability. Included controls link back to risks, legal requirements or contracts, and the links are real rather than generic.
• Consistency with scope. Exclusions make sense for the ISMS scope. Excluding physical controls while running an in-scope office, for instance, is a red flag.
• Accurate status. Controls marked as implemented can be evidenced through policies, records, configurations or interviews.
• Document control. The SoA has a version, an owner, an approval date and a review history.
• Alignment with the treatment plan. Planned controls have owners and dates, and risk owners have approved the plan and accepted residual risks, as clause 6.1.3 f) requires.

How to build your SoA step by step

1. Confirm your ISMS scope. Be clear about the locations, teams, systems and services covered. Every inclusion and exclusion depends on it.
2. Complete your risk assessment. Identify, analyse and evaluate information security risks using your defined methodology.
3. Choose risk treatment options. For each risk, decide whether to modify, avoid, share or retain it.
4. Determine the necessary controls. Select controls from Annex A and any other sources that treat each risk. Use ISO/IEC 27002 for implementation guidance.
5. Map your legal and contractual requirements. Add controls driven by regulation, customer contracts or business rules, even where the risk assessment did not surface them.
6. Compare against Annex A. Walk through all 93 controls to check nothing necessary is missing, as clause 6.1.3 c) requires.
7. Write the justifications. For each included control, cite risks or requirements. For each exclusion, explain why it does not apply.
8. Record implementation status and evidence. Note the status, the control owner and where the evidence lives, such as a policy, procedure or system record.
9. Align with the risk treatment plan. Make sure every planned control appears in the plan with an owner and target date.
10. Approve, publish and review. Get management and risk owner sign-off, put the SoA under document control and review it at least when risks, scope or the business change, and as part of your management review.

Common mistakes to avoid

• Starting from a template instead of the risk assessment. An SoA written before the risk assessment usually includes everything and justifies nothing.
• Blanket justifications. “Best practice” or “required by ISO 27001” against every control does not show why it is needed in your context.
• Over-excluding to reduce effort. Excluding controls that clearly treat in-scope risks invites nonconformities and undermines customer trust.
• Overstating status. Marking controls as implemented when evidence is thin is one of the fastest ways to fail an audit.
• Letting it go stale. New systems, suppliers or regulations change your risks. An SoA that has not been reviewed in a year rarely reflects reality.
• Keeping it disconnected. When the SoA, risk register, treatment plan and evidence live in separate spreadsheets, they drift apart quickly.

How Enactia helps

Enactia is an AI-powered governance, risk and compliance platform. It does not write your SoA for you, but it helps keep the pieces behind it connected and current.

• Run your ISO 27001 assessment. Compliance Assessments let you assess each Annex A control, record status and assign owners and tasks for gaps.
• Link controls to risks. Enterprise Risk Management helps you maintain the risk register and treatment decisions that justify your control choices.
• Reuse work across frameworks. Compliance Universe cross-maps controls across more than 50 frameworks and laws, so controls in your SoA can also support NIS2, DORA, SOC 2 or GDPR obligations.
• Keep evidence ready. Document Repository and Evidence Management, together with Policy Management, keep the documents auditors ask for in one place.

Frequently asked questions

Is the SoA mandatory for ISO 27001 certification?
Yes. Clause 6.1.3 d) of ISO/IEC 27001:2022 requires it, and certification bodies will not certify an ISMS without one.

Do I have to implement all 93 Annex A controls?
No. You must consider all of them, but you only implement the controls that are necessary for your risks and requirements. Any Annex A control you exclude needs a clear justification.

Can I add controls that are not in Annex A?
Yes. Annex A is not exhaustive. You can include controls from other frameworks, sector rules or customer contracts, and they should appear in the SoA with their own justification.

How often should the SoA be updated?
Review it whenever your scope, risks, systems or obligations change significantly, and at least as part of your regular ISMS reviews. Keep a version history so auditors can see what changed and why.

What is the difference between the SoA and the risk treatment plan?
The risk treatment plan sets out how each risk will be treated, by whom and by when. The SoA lists the resulting controls, why they are included or excluded and whether they are implemented.

Conclusion: make your Statement of Applicability a living document

A strong Statement of Applicability is not about listing controls. It is about showing, clearly and honestly, how your organisation has turned its risks and obligations into security decisions. Build it from your risk assessment, justify every choice, keep status accurate and review it as your business changes.

Want to see how Enactia can help you manage ISO 27001 controls, risks and evidence in one place? Contact us or book a demo with our team.