The Statement of Applicability (SoA) is a mandatory document under Clause 6.1.3 d) of ISO/IEC 27001:2022 and the central link between risk treatment and implemented controls. It lists all 93 Annex A controls, documents applicability per control, justifies inclusion or exclusion, and tracks implementation status. Without an SoA there is no certification, and a poorly structured SoA is the most frequent cause of Stage 2 postponement in Stage 1.

This article covers:

• The normative requirements for the SoA from Clause 6.1.3 d)
• Recommended columns and their content requirements
• Linking the risk treatment plan to the SoA
• Mapping treatment to the four themes A.5 (organizational), A.6 (people), A.7 (physical), A.8 (technological)
• Common audit findings and how to avoid them
• A proven SoA template as a starting point

Intended audience: ISMS managers, CISOs, and advisors building or overhauling the SoA. We explain the normative interpretation, how Swiss and EU auditors read the document, and provide concrete wording examples for justifications.

Clause 6.1.3 d) of ISO 27001:2022 explicitly requires a Statement of Applicability covering:

1. the necessary controls (per the risk treatment plan),
2. justification for their inclusion,
3. whether they are implemented or not,
4. justification for excluding controls from Annex A.

Annex A of ISO 27001:2022 contains 93 controls in four groups: A.5 Organizational Controls (37 controls), A.6 People Controls (8 controls), A.7 Physical Controls (14 controls), A.8 Technological Controls (34 controls). Each of these 93 controls must be addressed in the SoA, either as applicable with an implementation description, or as excluded with substantive justification.

An important clarification: a control may be declared not applicable only if it addresses no risk for the organization. Excluding A.8.24 (Cryptography) on the grounds we don't use cryptography requires explaining how all data flows (TLS, database encryption, backup, authentication) function without cryptography. In most cases this is not plausible and leads to a minor nonconformity. A credible justification reads more like: Control A.7.13 (Equipment maintenance) is not applicable because all IT endpoints are leased and fully maintained by the cloud workplace provider, responsibility lies contractually with the provider.

ISO does not require a specific table form, but a battle-tested SoA structure contains the following columns:

1. Control ID (e.g. A.5.7, A.8.24)
2. Control title (per Annex A)
3. Applicable? (yes / no)
4. Justification for inclusion / exclusion (substantive explanation, not n/a)
5. Implementation status (implemented / partially implemented / planned; with target date if planned)
6. Owner (function or person)
7. Implementation description (reference to policy, procedure, technical measure)
8. Verification evidence (document ID, log, audit result)
9. Linked risks (IDs from the risk register)
10. Last review (date, auditor)
11. Notes / comments (e.g. compensating measures, planned improvements)

Optional but recommended for regulated sectors: additional columns for regulatory anchors (e.g. FINMA Circular 2023/1, NIS2 Art. 21, DSG Art. 8 / DSV Art. 3, BAIT, BAFin). This simplifies later supervisory or customer audits that reference specific regulatory standards.

Avoid an SoA with only three columns (applicable yes/no, reference to policy). It is technically minimally compliant but not helpful for external audits, customer audits, or recertifications, and it leads to repeated follow-up questions in surveillance.

The SoA is not stand-alone; it must mirror the logic of the risk treatment plan. Clause 6.1.3 requires that the selected controls address the identified risks, the SoA is the proof.

Recommended approach:

1. Build the risk register: each risk entry has an ID (R-001, R-002, ...), description, likelihood, impact, risk owner.
2. Choose risk treatment: per risk one of the four options from ISO/IEC 27005: risk modification (apply controls), risk sharing (insurance, outsourcing), risk acceptance (formally documented), risk avoidance (discontinue the activity).
3. Assign controls: for risk modification, which Annex A controls (and which additional controls outside Annex A) address the risk?
4. Update the SoA: each control choice is linked in the SoA in the linked risks column back to the R IDs.
5. Document accepted risks: when a risk is accepted, the risk owner must approve it in writing (Clause 6.1.3 f).

A common error: the SoA lists all controls as applicable without any risk IDs. The external auditor then asks: which risk does A.5.34 (Privacy and protection of PII) concretely address in your organization? Anyone unable to answer has not produced the linkage proof, minor NC against Clause 6.1.3.

The 2022 version reduced Annex A from 14 domains (A.5–A.18 in the 2013 version) to four themes. This helps group the controls by responsibility and distribute SoA maintenance to the right owners.

A.5 Organizational Controls (37 controls), owner: ISMS manager, senior management, Legal:

Policies, roles, supplier management, incident management, continuity, compliance. Examples: A.5.1 (Policies for information security), A.5.7 (Threat intelligence, NEW), A.5.23 (Information security for use of cloud services, NEW), A.5.30 (ICT readiness for business continuity, NEW).

A.6 People Controls (8 controls), owner: HR, ISMS manager:

Screening, terms of employment, awareness, disciplinary process, remote working (NEW as A.6.7). The most compact of the four themes; often underestimated in audits because the HR owner is not represented in the audit program.

A.7 Physical Controls (14 controls), owner: facility management, IT operations:

Perimeter, access, clear desk and screen, delivery zones, maintenance. In cloud-only companies, many A.7 controls reduce to the office site or the cloud provider contract.

A.8 Technological Controls (34 controls), owner: IT operations, engineering, SecOps:

Endpoint security, access management, cryptography, logging, network, application security, backup. Contains the new controls A.8.9 (Configuration management), A.8.10 (Information deletion), A.8.11 (Data masking), A.8.12 (Data leakage prevention), A.8.16 (Monitoring activities), A.8.22 (Web filtering), A.8.23 (Secure coding), A.8.28 (Secure coding complement), A.8.29 (Security testing in development and acceptance).

We recommend structuring the SoA by the four themes (e.g. four tabs in an Excel) and assigning one owner per tab. This accelerates the annual SoA review.

In audit practice the SoA exhibits recurring weaknesses. The following seven findings are the ones we see most often, each with a recommendation for avoidance.

• Generic justifications: best practice or industry standard without concrete risk reference. Recommendation: reference the R IDs from the risk register.
• Exclusion without justification: A.7.X marked not applicable with n/a. Recommendation: explain the substance (e.g. full cloud workplace outsourcing to Microsoft 365 with documented sub-processing agreement).
• SoA and implementation diverge: status implemented but the auditor finds no technical evidence. Recommendation: fill the verification column with a document ID.
• Outdated SoA: last update 18 months ago. Recommendation: at least annual mandatory review, triggered by the management review or material changes.
• SoA inconsistent with risk treatment plan: risks treated as modification reference controls flagged excluded in the SoA. Recommendation: cross-check on every update of either document.
• Owner missing: without a clear owner per control, the implementation status cannot be confirmed without inquiry. Recommendation: function (not person) as owner, survives staff turnover.
• No verification evidence: implementation description without an evidence link. Recommendation: at least one verifiable artifact per implemented control (policy link, configuration snapshot, audit report).

A major nonconformity to the SoA obligation (e.g. missing entirely, or several Annex A controls omitted) blocks certification. Systematic minor NCs risk escalation to major in surveillance.

We recommend maintaining the SoA as a structured Excel or as a database view from an ISMS platform, not as a Word document. The table form allows filtering, sorting, and automated reporting in the audit.

Example row for A.5.7 (Threat intelligence) in a typical B2B SaaS SME:

• Control ID: A.5.7
• Control title: Threat intelligence
• Applicable: yes
• Justification: several risks address external threats (R-007 phishing attacks, R-012 supply chain compromise); regular threat-landscape assessment required.
• Status: implemented
• Owner: CISO
• Implementation: subscription to BACS / NCSC CSIRT bulletins, monthly threat intelligence briefing from a commercial source (Recorded Future), quarterly threat modeling workshop, integration into the quarterly management review.
• Verification evidence: Doc-ID POL-027 (Threat Intelligence Policy), training records Q1–Q4, Recorded Future subscription confirmation.
• Linked risks: R-007, R-012, R-024
• Last review: 15.04.2026 by M. Grob (SIDD)
• Comment: Recorded Future source expires in 2027, evaluate alternative by Q3 2026.

Such a row conveys to the external auditor in 30 seconds that the control is alive, who runs it, with what evidence, and with what forward look. This is the standard we work to, not the minimalist yes / reference to policy variant.

SIDD produces turnkey SoAs for Swiss companies and maintains them across the three-year certification cycle. Within our ISMS / ISO 27001 implementation engagement, we build the risk register, derive the risk treatment plan, and produce an SoA that fully accounts for the 93 Annex A controls. We supply a proven SoA template and tailor it to your sector context (FinTech, MedTech, industrial, public sector, B2B SaaS).

For ongoing maintenance we recommend the Priverion platform: it links the risk register, SoA, control catalog, and audit trail in a single data model, so that inconsistencies are detected automatically and surfaced on the dashboard. Where an ISMS exists, we benchmark your current SoA against the typical audit findings and deliver a prioritized improvement plan in a 5-day engagement. For an external CISO mandate that owns the SoA on an ongoing basis, combine it with our CISO / ISB service.

Send us your current SoA (or a status note) via the contact form, we provide an initial assessment within 48 hours. For a binding mandate, request a quote.