ISO 27001 Statement of Applicability: Building Your SoA from Annex A

Many teams approach Annex A of ISO/IEC 27001:2022 as a shopping list: 93 controls, tick them off, move on. That is a misreading. Annex A is a reference list, there to check that no necessary control has been overlooked. The document that commits the organisation in front of the auditor — the one they will open before anything else — is the Statement of Applicability (SoA), required by clause 6.1.3 d).

Annex A: a reference list, not a set of requirements

Since the October 2022 revision, Annex A groups 93 controls into four themes, aligned with the structure of the companion standard ISO/IEC 27002:2022:

Theme	Numbering	Number of controls
Organisational controls	A.5	37
People controls	A.6	8
Physical controls	A.7	14
Technological controls	A.8	34

That restructuring, and the new controls it brought in, is covered in our article on ISO 27001:2022 and what changed in Annex A. The point here is a different one: none of those 93 controls is mandatory in itself. What is mandatory is having examined every one of them and made a call.

The chain that produces the SoA

The Statement of Applicability is not a document you write; it is a document you arrive at, at the end of a sequence. Clause 6.1.3 sets that sequence out in six sub-clauses, to be read in order:

• a) select the risk treatment options appropriate to the results of the risk assessment;
• b) determine all controls necessary to implement those options — not starting from Annex A, starting from the risks;
• c) compare the controls so determined against Annex A to verify that no necessary control has been omitted;
• d) produce the Statement of Applicability;
• e) formulate the risk treatment plan;
• f) obtain risk owners’ approval of that plan and their acceptance of the residual risks.

Running b) before c) is the opposite of what most projects do: they download a 93-row SoA template and then look for risks to fill it with. The result shows instantly — interchangeable justifications with no connection to the actual organisation. Note too that nothing prevents you from retaining controls from sources other than Annex A — a sector framework, a customer requirement, your own rules — and listing them in the SoA.

What clause 6.1.3 d) requires, no more and no less

The SoA must contain four things:

1. the necessary controls retained, whatever their origin;
2. the justification for their inclusion;
3. their implementation status — implemented or not;
4. the justification for excluding any Annex A control.

That is all. No prescribed format, no prescribed number of columns. In practice: a table of at least 93 rows, giving for each control its reference and title, applicable yes/no, the justification, the implementation status, and a pointer to the document or evidence that carries it. That last column is not required by the standard, but it is what turns the SoA into the table of contents of your audit — and it saves hours on the day.

SoA and risk treatment plan: two documents, two jobs

The confusion is common, and it is expensive at audit.

	Statement of Applicability	Risk treatment plan
Sub-clause	6.1.3 d)	6.1.3 e) and f)
Nature	Snapshot	Action plan
Answers	Which controls, why, where do we stand?	Who does what, by when, with what resources?
Key content	Inclusion, exclusion, implementation status	Actions, owners, deadlines, residual risk
Approval	Carried by management through the ISMS	Approved by the risk owners

The two documents talk to each other: any control marked applicable but not implemented in the SoA must have its dated counterpart in the risk treatment plan. Auditors make that cross-check every time. They also check consistency with the ISMS scope — the same reflex we describe in our guide to checking an ISO certificate, its validity and its scope.

Using the ISO/IEC 27002:2022 attributes to sort your controls

ISO/IEC 27002:2022 tags each control with five families of attributes: control type (preventive, detective, corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities and security domains.

Those attributes are not requirements: they are viewing angles, designed to generate different views of Annex A. Nothing obliges you to carry them into the SoA. But adding one or two attribute columns has two concrete benefits: it exposes imbalances (an SoA that is 90 % preventive with no detection capability jumps off the page), and it helps spread controls across the right owners instead of piling everything on the security manager.

Defensible and indefensible exclusions

An exclusion is justified by the absence of the activity, asset or risk scenario concerned from the ISMS scope. Never by anything else.

Defensible — provided it is true, documented and consistent with the scope:

• development-related controls (secure coding, development environments, outsourced development) for an organisation that develops no software;
• controls aimed at physical areas that do not exist within the scope, such as delivery and loading areas;
• a control covering a type of asset the organisation does not operate.

Indefensible, however it is dressed up:

• “too expensive” or “not a priority”: that is a risk treatment decision, not a question of applicability;
• “not in place yet”: that is an implementation status, to be carried in the risk treatment plan — not an exclusion;
• “we have no dedicated team”: the control stays applicable, only the way it is delivered changes;
• excluding logging, backup or access management: these map to risks present in any organisation that handles information;
• the same justification copied across ten rows: an auditor spots that in thirty seconds.

If your scope covers health data or personal data, the room for exclusion narrows further: see our articles on ISO 27001, GDPR and NIS 2 and on the difference between HDS certification and ISO 27001.

The mistakes that cost a nonconformity

• The frozen SoA. Version 1.0 written before the initial audit and never reopened. Context, risks and scope move: an SoA dated earlier than your latest risk assessment is an immediate documentary inconsistency.
• Generic justifications. “Applicable because necessary to information security” justifies nothing. A justification fits in one sentence, but it must point to a risk, an asset or an obligation identified in your organisation.
• “Implemented” with no evidence. This is the single most common source of findings. Declaring a control operational when no record backs it up exposes you to a major nonconformity if the gap is systemic.
• The permanent “planned”. A control announced as being rolled out across three successive reviews, with no progress, draws scrutiny and eventually gets reclassified.
• Forgetting non-Annex A controls. If you have retained controls of your own, they belong in the SoA on the same footing as the rest.

Keeping the SoA current between audits

The SoA is a living document and should be version-controlled as such: version number, date, author, nature of the changes. The version and date of the Statement of Applicability are commonly referenced in certification documentation, which makes any mismatch between the certificate and the document actually in force highly visible.

Three update triggers to build into your routine:

1. Any new risk assessment or change of scope — new site, new service, new subsidiary, new critical supplier.
2. Any control moving from “planned” to “implemented”, or the reverse.
3. Every surveillance audit. The certification cycle provides for annual surveillance audits and a recertification audit after three years. At each visit, the auditor picks up the SoA from the previous one and checks what has moved. That is the moment an SoA untouched for twelve months becomes an issue — the full cycle is set out in our guide to obtaining ISO 27001 certification.

What the research says

Academic criticism of information security standards throws the role of the SoA into sharp relief. Mikko Siponen and Robert Willison, in “Information security management standards: Problems and solutions” (Information & Management, 2009), show that standards of this family are generic by construction and pay insufficient attention to the differences between organisations, whose security requirements diverge considerably (see the study). The Statement of Applicability is precisely the mechanism through which the standard answers that objection: it is the point where a universal list becomes a situated decision.

On outcomes, Matteo Podrecca, Guido Nassimbeni, Giovanna Culot and Marco Sartor analysed a panel of 143 US-listed firms in 2022 in Computers in Industry (“Information security and value creation: The performance implications of ISO/IEC 27001”) and observed an association between certification and improvements in profitability and labour productivity (see the study). That, of course, assumes the certification rests on real choices — meaning an SoA that describes the organisation as it actually is.

Take action

Open your SoA and test it on three rows picked at random: does the justification point to a risk identified in your organisation? Is the implementation status backed by evidence or a dated action? Is the document dated later than your last risk assessment? If a single answer is missing, you know where to start. To situate the scheme as a whole — certification bodies, scope, audit cycle — see our guide to ISO 27001 certification, our article on the cost of ISO 27001 certification and our comparison of ISO 27001 and SOC 2.