Statement of Applicability: what goes in it and how to keep it current

The Statement of Applicability, or SoA, is the document ISO 27001 requires in clause 6.1.3 d). It is the bridge between your risk assessment and the 93 controls in Annex A. An auditor uses it as a reading guide: which controls has this organisation chosen, why, and where is the evidence.

What goes in it

In our own words, without reproducing the standard, clause 6.1.3 d) asks for four things:

1. The controls the organisation needs, from Annex A and possibly from other sources.
2. For each included control: why it is included.
3. For each included control: whether it has been implemented.
4. For each Annex A control that is not included: why not.

Because every Annex A control ends up under point 2 or point 4, the statement in practice has a row for each of the 93 numbers. A workable layout looks like this:

The standard does not literally ask for the last two columns, but they make the statement usable. An auditor wants to move from a row straight to the procedure and the evidence.

Justifying both yes and no

Exclusions tend to get most of the attention, but a "yes" needs a reason too. Common reasons to include a control are:

• a risk from the risk assessment;
• a legal requirement, such as the GDPR for personal data;
• a contractual requirement from customers, for example a Dutch hospital that asks for NEN 7510, the Dutch healthcare information security standard;
• a decision by management, recorded in the policy.

An exclusion is strong when it points to the scope or to reality. "No server room of our own, hosting entirely with a certified cloud provider" justifies most of the physical controls around server rooms. "Not relevant" on its own does not. Be careful with exclusions that contradict your own services, too: a software company that excludes 8.28 on secure coding can expect questions about it.

A common middle ground is a control that applies but is largely carried out by a supplier. The answer is then "yes", with a reference to the supplier arrangements (5.19 to 5.23) and that supplier's certificate or assurance report.

Implementation status

The standard asks whether a control has been implemented. In practice three values work well: implemented, partly implemented and planned. Anything partly implemented or planned should have an action in the risk treatment plan, with an owner and a date. A statement full of "planned" without matching actions tells an auditor that the plan is not being worked.

How it relates to the risk treatment plan

Clause 6.1.3 describes a sequence. First you decide for each risk how to treat it and which controls that needs. Then you compare those controls with Annex A, so nothing is overlooked. Only then do you draw up the statement. The risk treatment plan records what is going to happen, and the risk owners approve that plan and accept the remaining risks.

The two documents therefore describe the same reality from different angles. The risk treatment plan is organised by risk, the statement by control. As long as every row in the statement points to a risk, a requirement or a decision, and every risk points to one or more controls, an auditor can walk in both directions. That traceability is what gets tested.

Keeping it current

The statement is a controlled document with a version, a date and approval by someone accountable. Update it when:

• the scope changes, for example through a new service or office;
• the risk assessment produces new risks or retires old ones;
• a control changes status;
• you switch hosting provider or another critical supplier;
• an internal or external audit finds a nonconformity;
• a standard is added, such as NEN 7510 alongside ISO 27001.

On top of that, go through it in full at least once a year, for example in preparation for the management review. Keep old versions: an auditor wants to see which choices applied at which moment.

Where it tends to go wrong

In many organisations the statement is a spreadsheet updated once a year, just before the audit. The references to risks and evidence fall behind, and a second standard produces a second tab. Trustbird lets people work in business language and makes the structure of the standard visible precisely here: the statement follows from the recorded controls, risks and justifications, for each standard the organisation carries. The choices and the approval remain with the organisation.