ISO 27001 Statement of Applicability: Template and Worked Example

The ISO 27001 Statement of Applicability (SoA) is the document that lists every control your information security management system (ISMS) needs, explains why each one is included, states whether it is implemented and justifies every Annex A control you leave out. Clause 6.1.3 d) of ISO/IEC 27001:2022 makes it mandatory, and it is one of the first documents a certification auditor reads.

This page covers the required columns, a worked example, how to justify exclusions, the problems that lead to audit findings and a template for all 93 Annex A controls, which you can also download as a spreadsheet.

What is a Statement of Applicability in ISO 27001?

It is the record of your control decisions. Your risk assessment identifies the risks; the SoA shows which controls you chose to treat them, and how those choices compare with the 93 controls in Annex A.

Clause 6.1.3 d) requires the SoA to contain four things:

1. The necessary controls, whether taken from Annex A or from elsewhere.
2. The justification for including each one.
3. Whether each necessary control is implemented or not.
4. The justification for excluding any Annex A control.

Two consequences follow. Every one of the 93 Annex A controls must appear, either included or excluded with a reason. And controls you add from other sources, such as PCI DSS, a customer contract or your own design, belong in the SoA too, because the standard says Annex A is not an exhaustive list.

Why do auditors start with the SoA?

Because it is the map of your ISMS. At the Stage 1 audit, the certification body reads the SoA alongside your scope, risk assessment and risk treatment plan to check that the design hangs together. At Stage 2, auditors sample controls you marked as implemented and ask for evidence that they operate. Your certificate normally references the SoA version it was issued against, which is why customers ask to see it during due diligence. Our guide to the ISO 27001 certification audit explains both stages.

What must an ISO 27001 SoA include?

The first five columns below come straight from clause 6.1.3 d). The rest are good practice that makes the SoA easier to audit and maintain.

Many organisations tag the reason for inclusion with a short code: R for risk treatment, L for legal or regulatory, C for contractual and B for business requirement. The standard does not ask for codes, but they make a long SoA quick to read.

Statement of Applicability example: a completed SoA

This Statement of Applicability example is an illustrative extract for a fictional 40-person UK software company, showing included controls, exclusions with reasons and an additional control. It has no office, its staff work from home, it hosts its product in a public cloud and it writes its own code. Risk IDs refer to its risk register.

Three things to notice:

• Planned is not excluded. Data masking (8.11) is applicable but not yet in place. It stays in the SoA as planned, with an owner and date in the risk treatment plan.
• Exclusions can be tested. An auditor can confirm there is no office and no development contract. If either changes, the exclusion falls away.
• Additional controls sit alongside Annex A. ADD-01 comes from a contract, not from Annex A, and is tracked the same way.

Can you exclude Annex A controls?

Yes. You can exclude any Annex A control that no identified risk, legal, regulatory or contractual requirement calls for, provided the SoA records why. You cannot exclude any of the ISO 27001 requirements in clauses 4 to 10, which apply to every ISMS.

The test is whether an auditor could check the justification against reality:

Three areas need care:

• Physical controls in a remote company. Perimeter and entry controls (7.1 to 7.4) may not apply, but 7.7 clear desk and clear screen, 7.9 off-premises assets, 7.10 storage media and 7.14 secure disposal or re-use of equipment usually still do.
• Development controls (8.25 to 8.31). Decide them one by one. Some, such as 8.26 application security requirements, also cover applications you acquire, and 8.30 applies the moment a contractor builds anything for you.
• Cloud services (5.23). Almost every organisation that uses Microsoft 365, Google Workspace or a hosted platform needs it.

How does the SoA link to the risk assessment and treatment plan?

Clause 6.1.3 sets the order, and the SoA comes out of your risk treatment decisions rather than before them.

Keep the link traceable both ways: every treated risk points to controls in the SoA, and every applicable control points back to at least one risk or named requirement. Filling in an SoA template first and inventing reasons afterwards produces a list of controls with no risks behind them, and auditors spot it quickly. Our guide to ISO 27001 risk assessment covers the method and the register.

What SoA problems lead to audit findings?

These are the issues that typically turn into nonconformities or observations:

• SoA and risk treatment plan disagree. A control is marked applicable with no risk behind it, or a treatment relies on a control the SoA excludes.
• Copied justifications. The same sentence against dozens of controls, often straight from a template.
• Exclusions contradicted by reality. 5.23 excluded while the company runs on Microsoft 365, or 8.30 excluded while a contractor builds the website.
• “Implemented” without evidence. At Stage 2 the auditor asks for records and there are none.
• Still on the 2013 structure. References to A.5 to A.18 and 114 controls, although the transition to the 2022 edition ended on 31 October 2025.
• No version control or approval. No owner, date or sign-off, or no update after a change of scope.
• Missing additional controls. Contractual or PCI DSS requirements handled outside the ISMS and absent from the SoA.

For a wider pre-audit check, use our ISO 27001 checklist.

The Statement of Applicability template

Download the free SoA template (Excel, .xlsx), or copy the layout below into your own spreadsheet, with one row for each of the 93 Annex A controls followed by rows for any additional controls. The controls run 5.1 to 5.37 (organisational), 6.1 to 6.8 (people), 7.1 to 7.14 (physical) and 8.1 to 8.34 (technological); our guide to ISO 27001 Annex A controls explains each one.

Above the table, add a header block with the document owner, version, approval date and the ISMS scope the SoA covers. Then:

1. Complete the risk assessment and treatment decisions first.
2. Mark each control applicable or not, citing risk IDs or a named requirement.
3. Record honest implementation status. “Planned” is acceptable when the risk treatment plan gives an owner and a date.
4. Have the SoA approved, then review it whenever the risk assessment, scope or services change.

The download does the layout for you. It lists all 93 controls by number, title and theme, with drop-down lists for Applicable and Implementation status and columns for the reason code, linked risk IDs, justification, how each control is implemented, evidence and owner. It also has the header block, ten rows for additional controls, a completeness check on every row, the worked example above and a summary sheet that counts applicability and status by theme. It is free to use and adapt within your organisation.

A template saves layout time; the decisions in it must still come from your own risk assessment.

Why Sovereign Secure

• ISO 27001 certified ourselves, so we maintain our own SoA and go through surveillance audits too.
• An SoA built from your risks, as part of our ISO 27001 consultancy. Certification audits are carried out by an independent certification body, our partner MQA International.
• One control set for several schemes. As a PCI SSC Qualified Security Assessor (QSA) company and an IASME-licensed Cyber Essentials certification body, we bring PCI DSS and Cyber Essentials requirements into your SoA.
• Testing evidence for 8.8 and 8.29 through ISO 27001 penetration testing.
• UK company since 2012, headquartered in Accrington, Lancashire (Companies House 08334453).

Get the SoA template or a review

Download the free SoA template (.xlsx). For help completing it, use the form below, which is already set to ISO 27001. If you already have an SoA, an ISO 27001 gap analysis checks it against your risk register and evidence before the certification auditor does. Or call +44 161 523 5276.