How to write an ISO 27001 Statement of Applicability: step by step, with a worked example and a template

The short answer: you don't fill in a Statement of Applicability, you derive it. It comes out of risk treatment. First you decide how to treat each risk and which controls you need to do it. Then you compare those controls with the 93 in Annex A, so you don't miss any. Finally you write down, control by control, whether you need it, why, whether it is in place and, if you exclude it, why. That is what clause 6.1.3 d) of ISO/IEC 27001:2022 asks for, and it is the first thing the auditor opens.

The rest of this article is the method in five steps, applied to ACME, the mistakes I see most often in audits and a template to build your own.

What the standard requires it to contain

Clause 6.1.3 d) asks for four things. No more, no less:

Everything else is useful but optional: the owner, the risk reference, the evidence, the date of the last review. I would always include them. They save you explanations on audit day.

Step 1. Start from risk treatment, not from Annex A

The most common mistake is to open Annex A and go through the 93 controls asking "do we have this?". What comes out is a list of what you already do, not of what you need.

The standard works the other way round. In the risk assessment you identify what can happen. In risk treatment you decide what to do about each risk. If you mitigate it, you choose the controls that bring it down. Those controls can come from Annex A, from another standard or from your own organisation. The standard allows it: Annex A is not mandatory in itself, it is the list you compare against.

Besides risks, some controls come in because someone requires them of you. A law such as the GDPR or NIS2, a customer contract or a management requirement. Record those too, with their source.

Step 2. Compare against the 93 Annex A controls

With your list of controls ready, go through Annex A to check you haven't left out any you need. That is what clause 6.1.3 c) asks for. Since the 2022 version there are 93 controls in four groups:

If the comparison turns up a control that mitigates a risk you hadn't treated, the conclusion is not "add it to the SoA". It is to go back to the risk assessment, because a risk was missing.

Step 3. Write the justification for each control

For each included control, one sentence saying why: the risk it treats, with its reference, or the obligation it comes from. "Good practice" is not a justification. The auditor will ask which risk it reduces.

For each excluded control, one sentence saying why it isn't needed. A valid exclusion always has the same shape: the activity, asset or obligation the control protects does not exist. "We don't develop software" justifies excluding secure coding (8.28). "We have no budget" justifies nothing: that is an accepted risk, and it belongs in risk treatment, signed by whoever accepts it.

Step 4. Record the status with its evidence

The standard asks whether each control is implemented or not. In practice three states are more useful than two: implemented, in progress and pending. And for each implemented control, where the proof is: the procedure, the log, the screenshot or the report.

A control marked as implemented with no evidence you can find is the easiest finding in the audit. Controls in progress or pending should appear in the treatment plan, with an owner and a date.

Step 5. Approve it and version it

The SoA is documented information. It needs a version, a date and an approver. Review it at least every time you review the risk assessment, and whenever the scope, a major supplier or a legal obligation changes. An SoA that hasn't changed in two years says the ISMS hasn't either.

A worked example: ACME's SoA

ACME builds and sells cloud management software. It has 120 people, most of them working remotely. It hosts its product with a European cloud provider and outsources part of its mobile app development to an external studio. Its certification scope is "the development, operation and support of the ACME platform".

These are six rows from its Statement of Applicability. I chose them because each one involves a decision that isn't obvious:

Note three things. Each inclusion's justification carries the risk reference, so the auditor can follow the thread back to the assessment. Whatever is in progress or pending points to a treatment plan task, with a date. And the exclusion of 7.13 doesn't just say "not applicable": it says why what the control protects doesn't exist and which other control covers the risk.

My take on the grey areas

The standard leaves some decisions to your judgement. On these three, this is my view:

• Controls covered by a supplier. If your cloud provider handles the physical security of the data centre, the control isn't simply excluded. It is included or excluded according to your scope, and the risk is treated with the supplier controls, 5.19 to 5.23. Excluding every physical control because "it's all in the cloud" tends to end in a finding: offices, laptops and paper still exist.
• Half-implemented controls. If the control works in one part of the scope and not in another, mark it as in progress and say where it's missing. That beats an "implemented" the auditor disproves with a sample.
• Extra controls. Including a control that treats no risk and meets no obligation doesn't protect you in the audit. It obliges you to show its evidence.

And if you also have the ENS

Spain's National Security Framework (ENS) also requires a Statement of Applicability, signed by the security officer, with the measures from Annex II of Royal Decree 311/2022 that apply according to the system's category. The logic is similar, but the measures are not the Annex A controls. If you have to meet both, keep a single table of controls and evidence and produce both statements from it. What you want to avoid is two spreadsheets that contradict each other.

The most common mistakes

• Writing it before the risk assessment. You get a list of what you already have, and nobody can explain why each control is there.
• Generic justifications. "Required by the standard" or "good practice" doesn't say why you need it.
• Implemented without evidence. If you can't show the proof in two minutes, it isn't implemented as far as the auditor is concerned.
• Exclusions on cost grounds. What you don't do because of cost is an accepted risk, not a control that doesn't apply.
• An SoA that never changes. If the risk assessment is reviewed every year and the SoA has carried the same date since certification, one of the two isn't true.
• Still using the 2013 controls. The transition to the 2022 version ended on 31 October 2025. An SoA with 114 controls is out of date.

A template to build your own

These are the columns I would use. The first five cover what the standard requires; the rest are the ones that save you work in the audit:

You can download it as CSV, with ACME's six rows already filled in, and open it in Excel or LibreOffice.

How to keep it settled

An SoA in a spreadsheet goes stale as soon as someone changes a risk and forgets to update it. And the evidence usually sits in another folder, under another name.

In Almenara, the Compliance module keeps each standard's Statement of Applicability with its justification, its status and its evidence. Each supplier's risk feeds controls 5.19 to 5.22 without copying it by hand, and a piece of evidence uploaded once counts for every standard that asks for it. The SoA exports to PDF, Word or Excel. If you'd rather start with us, the gap analysis leaves the status of every control in your Statement of Applicability. And the ISO 27001 guide covers the rest of what the standard requires.

Frequently asked questions

Is the Statement of Applicability mandatory?

Yes. Clause 6.1.3 d) of ISO/IEC 27001:2022 requires it, and there is no certification without it. The auditor reviews it in stage one of the audit.

Do all 93 Annex A controls have to be included?

You have to take a position on all 93: say whether each one applies and why. You don't have to apply them all.

Can I add controls that aren't in Annex A?

Yes. If your risk treatment needs a control that isn't in Annex A, include it in the SoA with its own code and justification.

Who has to approve it?

The standard doesn't say, but the usual and sensible approach is for top management, or the ISMS owner with their authorisation, to approve it, because in doing so they accept what is done and what isn't.

How often should it be reviewed?

Every time you review the risk assessment, which should be at least once a year, and whenever the scope, the organisation or a legal obligation changes.

Is the SoA public?

No. It is an internal ISMS document. Some customers ask for it when assessing a supplier; you can show it under a confidentiality agreement or share a version without the evidence details.