The Statement of Applicability is a decision log, not a checklist

What clause 6.1.3 actually asks for

ISO/IEC 27001:2022, clause 6.1.3 d), asks the organisation to produce a Statement of Applicability that contains the necessary controls, the justification for their inclusion, whether they are implemented or not, and the justification for excluding any of the Annex A controls. Four things per control. Most Statements of Applicability that reach an auditor carry one and a half: a tick in the “applicable” column and, sometimes, “implemented — see policy X”.

Annex A of the 2022 edition lists 93 controls in four themes — organisational, people, physical, technological. The number is small enough to fit on a sheet, which is why the sheet is what people build. The sheet then does three things badly: it separates the decision from the reason, it separates the control from the systems it protects, and it goes stale the day after the certification audit.

The SoA is not the list of controls. It is the list of decisions about controls — and a decision without its reason is not a record, it is a tick.

Applicability is a decision with a scope

“Applicable” is rarely a yes/no for the whole organisation. Cryptography (A.8.24) applies to the systems that store or transmit information worth protecting; physical entry controls (A.7.2) apply to the sites where the equipment is; secure coding (A.8.28) applies if — and only where — you develop software. The honest SoA says for which part of the scope a control applies, and why it does not apply elsewhere.

That points at the same record every management-system standard eventually points at: the inventory. If the ISMS scope is expressed as assets, IT services and business solutions with owners, an applicability decision can be scoped to one of them — the payments platform, the Rotterdam site, the customer-facing web shop — and the justification is one sentence about that thing rather than a paragraph about everything.

The four fields, as records

Take the four things clause 6.1.3 asks for and give each a home that is not a cell.

Clause 6.1.3 d) asks for	The record	What makes it survive
The necessary controls	An adopted requirement set (Annex A-oriented) plus your own controls mapped to it	Version-pinned adoption; a control catalogue with owners
Justification for inclusion	The applicability decision — applicable, with the risk or obligation it answers	Decision stored per requirement, scoped where needed
Implemented or not	Asset compliance links with a status, and evidence with a date	Status per asset, not per control; evidence recency visible
Justification for exclusion	The applicability decision — not applicable, with the reason; or deferred to a date; or waived	Reason is a required field of the decision, not a footnote

Two consequences follow. First, “implemented” stops being a boolean: a control can be implemented on the six systems it was applied to and pending on the seventh, and the SoA can say so. Second, “not applicable” gets an expiry: a control excluded because “we do not develop software” is a decision that should be revisited when the first developer is hired — which is what a deferred status with a review date is for.

Keeping it alive between audits

The reason SoAs go stale is that they live outside the work. Three habits keep them current without a quarterly rebuild:

• Decide applicability when the requirement set changes, not when the audit is booked. A new Annex A edition, a new service in scope, a new site — each is a small batch of decisions with a reason, made by the person who knows.
• Let evidence age visibly. A control’s evidence has a date; a control whose newest evidence is older than its review period is not “implemented” in any sense an auditor accepts. Surface that per control, and the SoA’s implementation column updates itself.
• Treat exceptions as decisions too. A risk owner accepting a gap for six months is an applicability decision with an approver and an expiry — record it as one, with the four-eyes step your policy requires, rather than in an e-mail thread.

Producing the document

When those records exist, the Statement of Applicability is an export: requirement, decision, justification, scope, implementation status per linked asset, newest evidence date. In Secantra the same objects carry it — a framework adoption pinned to a published version, an applicability decision per requirement with a status and a reason (applicable, not applicable, deferred, waived, exception approved), controls mapped to requirements, asset compliance links with a status, evidence items with dates. The Statement of Applicability is a projection of those records — the data sheet in our resource library follows exactly that shape — and the day after the audit it is still true.

Whether the export lives in a spreadsheet template or a report is the smaller question. The larger one is where the reason lives. Put it on the decision.

Checklist

• Every Annex A control has a decision, not just a tick — applicable, not applicable, deferred or waived
• Every decision carries its reason as a field, and a scope where the honest answer is “only here”
• “Implemented” is stated per system the control applies to, backed by dated evidence
• Exclusions with a condition (“we do not develop software”) carry a review date
• Accepted gaps are recorded as decisions with an approver and an expiry
• The SoA is generated from the decisions, not maintained beside them