Creating the ISO 27001 Statement of Applicability (SoA), with a template

This guide shows what belongs in it and how to proceed in seven steps. It also gives you a template as a table, an example from industry, the typical mistakes and a way to keep the statement current.

What the Statement of Applicability does

The statement links your risk assessment and risk treatment to the controls you actually run. Because each control needs only one line, it stays compact, which makes it the overview of your ISMS.

Annex A is a reference catalogue, not a mandatory list. It contains 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). You decide for each control whether your scope needs it.

In the certification audit the statement is a central point of reference: auditors check that the controls are implemented the way it describes them, and they look at exclusions particularly closely.

What belongs in it

Clause 6.1.3 d calls for four items:

• The necessary controls. These are the controls from your risk treatment, including any that are not in Annex A.
• The justification for including them. Why is the control necessary?
• The implementation state. Is the control implemented or not?
• The justification for excluding. Why is an Annex A control not included?

For daily work a few more items pay off, even though they go beyond these four: the evidence, the owner, a reference to the related risk and the next review. The document itself also needs a version, a date and an approval.

Statement of Applicability template

The table shows the structure. All content is invented for illustration, and the names are short titles in our own words, not the text of the standard. Copy the columns into your file and keep one row for each Annex A control, plus one row for each control of your own.

Four values are enough for the status column: Open, Planned, Partially implemented and Implemented. For "No" the justification is all you need; status and evidence stay empty.

Seven steps to your Statement of Applicability

1. Define the scope. Decide which sites, processes and systems belong to the ISMS. All decisions apply to exactly this area. If production is included, machines and control systems count as well.
2. Assess risks and decide on treatment. Risk treatment shows which controls are necessary (clauses 6.1.2 and 6.1.3). This step comes before the statement, not after it.
3. Compare with Annex A. Go through all 93 controls and check that you have not missed a necessary one (clause 6.1.3 c).
4. Add further requirements. Laws, contracts and sector rules can require controls that do not follow from the risk assessment alone. Include them, as controls of your own where needed.
5. Justify each control. Give the specific reason for inclusion or exclusion: a risk, a duty, a contract or a verifiable fact about your scope.
6. Enter implementation state and evidence. A necessary control that is still missing stays in the statement, with the status "Planned" and a task in the risk treatment plan.
7. Review and release. Have a second person read it, release the state as a version and record the date and the reason for the change.

Example from an industrial company

This example is invented. A mid-sized machine builder has administration and production at two sites and writes part of the control software for its machines itself. The scope covers both sites, including production. Three decisions show what matters:

• Own development (A.8.28): The control applies because the company develops control software itself. The justification refers to the risk of defects in shipped code. The status is "Partially implemented": the coding rules exist, but code review is not yet consistent.
• External integrators (A.8.30): The first draft says "No", justified with "We develop in-house". When reading it, the head of production points out that an integrator adapts control programs on one line. The exclusion goes, and the security requirements for the integrator go into the contract.
• Remote maintenance (own control): A customer's contract requires each remote access to its machines to be approved and logged individually. The company adds this as a control of its own and names the contract as the justification.

A good statement therefore needs production, purchasing and sales at the table, not only IT.

Typical mistakes

• Filling it in without risk treatment. If the table is completed separately from the risk assessment, the statement and the risk treatment plan will not match.
• Empty justifications. "Not relevant" explains nothing. A fact that someone can check is better.
• Confusing "not implemented" with "not applicable". A control that is necessary but still missing is not an exclusion.
• Excluding because of effort or cost. Neither shows that a control is not necessary.
• Forgetting laws and contracts. Controls required by a duty or a customer belong in it, even without a risk of their own in the register.
• "Implemented" without evidence. A status with no policy, record or ticket behind it cannot be shown in an audit.
• Several versions. When the file travels by email, it is often unclear which state applies.

How the statement stays current

The statement is not a one-off project. When risks or the scope change, you update it. Typical triggers are:

• new or reassessed risks and lessons from security incidents,
• new sites, machines, systems or suppliers,
• new legal or contractual requirements,
• findings from internal and external audits.

We also recommend a fixed review once a year. Every change becomes a new version with a reason for the change, and the old one stays traceable.

A spreadsheet is enough for the first draft. It gets laborious once several people are involved: versions travel through mailboxes, evidence exists only as a file name in a cell, and an "Owner" column reminds nobody of the next review.

The Statement of Applicability in Complass

In Complass the Annex A catalogue is your Statement of Applicability. Excel remains a tool for input and output, while the current state lives in the portal:

• Bring in what you have. You import your existing list from Excel or CSV: applicability, justification, status, evidence, owners and review cycle. A preview first shows the errors per row.
• Decide per control. You record applicability, justification, status and evidence. The implementation guide gives the goal, steps, typical evidence and common findings. The filter "Justification missing" shows the gaps.
• Link to risks. You link risks to entries of the statement. In turn, the catalogue shows which risks justify a requirement.
• Add your own controls. Controls from sector rules or contracts go under "Own controls". They are assessed and released like every other entry.
• Keep it current. For each entry you set an owner and a review cycle, and the portal reminds you in good time. Evidence can carry an expiry date. Completed tasks and new evidence lead to a status proposal that a person accepts or rejects; no status changes by itself.
• Release it as a version. Release is possible only once every entry is decided and justified. If you wish, the four-eyes principle applies. Each version is stored immutably with a checksum and stays valid until the next one is released.
• Pass it on. You export the current state as Word, Excel or PDF, and released versions as Word or PDF. You invite your auditor to an audit free of charge, time-limited and with a log of every access.

The texts of the standard are not included, because standards are protected by copyright. Certification itself is carried out by an accredited certification body; Complass prepares you for it.

Frequently asked questions

What does SoA stand for?

SoA is short for Statement of Applicability, the document required by ISO/IEC 27001:2022, clause 6.1.3 d. German texts call it Erklärung zur Anwendbarkeit or Anwendbarkeitserklärung.

Do we have to implement all 93 Annex A controls?

No. You assess all 93 controls and implement the necessary ones. You can exclude a control if your scope does not need it, and you justify that in the statement. A company where nobody works remotely, for example, can exclude the corresponding control on that basis.

Is an Excel template enough for the Statement of Applicability?

To begin with, yes. You can set up the template above directly as a spreadsheet. For ongoing work, though, a file lacks reminders, approvals, versions and the link to the evidence. Complass takes over your spreadsheet by import, and Excel remains available as an export.

Our statement still dates from the 2013 edition. What should we do?

The 2013 edition had 114 controls in 14 domains, and the transition period to the 2022 edition ended on 31 October 2025. Map your entries to the new structure with 93 controls and look at the 11 newly added controls separately.

Does the 2024 climate amendment change the Statement of Applicability?

Not directly. ISO/IEC 27001:2022/Amd 1:2024 adds to clauses 4.1 and 4.2: you determine whether climate change is a relevant issue for you, and interested parties can have requirements on it. Annex A gains no new controls. If your review leads to new risks or controls, you enter them like any other change.

In a demo we show you how applicability, justification, evidence and release come together in Complass.

Request a demo Try it for 14 days

Read more

• Whitepaper "ISO 27001: the road to certification – for companies in every sector"
• ISO/IEC 27001 in Complass: from project mandate to certification audit
• Compliance management: catalogues, action plan and evidence
• Risk management: assessing and treating risks

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The wording of your licensed copy of the standard is authoritative.