Statement of Applicability ISO 27001: the template as an audit hinge

The Statement of Applicability, SoA for short, is a mandatory document for every certified information security management system according to Section 6.1.3 d) of ISO/IEC 27001:2022. It lists the applicable measures from Appendix A, justifies any selection or deselection, documents the implementation status and refers to risk treatment plans. With the 2022 revision, Appendix A has been reduced from 114 to 93 controls and divided into four topics: organisational, personnel, physical, technological.

This guide provides a structural template for the SoA, explains the key fields, shows typical audit errors and classifies maintenance into ISMS operations. CIVAC is a compliance platform and officer-as-a-service for German companies and provides an SoA template that is linked to the risk register, treatment plan and audit calendar and therefore does not have to be rebuilt every year.

Section 6.1.3 d) of the standard requires a statement of applicability that justifies the required measures and their inclusion or exclusion. This means that the SoA is not a marketing document, but rather proof that the company has considered Appendix A in its entirety, consciously classified each measure and plausibly justified deselections.

With the 2022 revision, Appendix A has been structurally revised. Four subject areas replace the old 14 domains: A.5 organisational (37 controls), A.6 personnel (8 controls), A.7 physical (14 controls), A.8 technological (34 controls). Eleven controls are new, including A.5.7 Threat Intelligence, A.5.23 Information Security for use of Cloud Services, A.8.9 Configuration Management, A.8.10 Information Deletion and A.8.28 Secure Coding. Fifty-six controls have been merged or reformulated.

The SoA must reflect this structure. Anyone who continues to work with a 2013 template does not have 2022-compliant proof. According to IAF MD 26, existing certificates must be converted to the 2022 version by October 31, 2026 at the latest. The transition period is binding and no extension is planned. Anyone who delays the change will lose their certification when the transition expires and will have to reapply.

An auditable SoA template has six columns. Firstly, control number and title exactly according to Appendix A of the 2022 version. Secondly, applicability, usually yes or no, alternatively partial with clarification. Thirdly, justification, both for selection and deselection, with reference to risk register, legal requirement, contractual obligation or business need. Fourth, implementation status with clear stages, such as not implemented, in implementation, implemented, continuously monitored.

Fifth, reference to concrete evidence: guideline, procedural instructions, configuration standard, audit report, risk treatment plan. These references must be discoverable, linkable in the workspace, not just mentioned as a file name. Sixth, person responsible with name or role and date of last check. Some templates add a seventh column for the risk ID, which speeds up audit traceability.

The most common template errors are three. Firstly, justifications such as “does not apply” without reference to risk, which auditors regularly rate as major. Secondly, outdated references to old guidelines that have since been superseded. Thirdly, maintenance data is missing, so it is not clear whether the document was even opened after the last audit. The appointment certificate, signed, filed, verifiable.

Applicability is not a question of taste. It follows from the risk register, from legal requirements and from the requirements of interested parties according to Section 4.2 of the standard. Anyone who marks Control A.5.30 ICT readiness for business continuity as not applicable must explain why no IT-related business continuity is required. In practice, a complete deselection can rarely be justified.

Justifications should contain three building blocks. Firstly, the risk reference: which risks does the control address, which risks remain open if you deselect it. Secondly, the legal-contractual reference: GDPR, NIS-2, customer contracts or industry-specific standards require control. Thirdly, the relevance to business needs: the control fits the activity, the data classification, the industry.

In the audit, the certifier checks samples against reality. Anyone who enters Control A.8.16 Monitoring activities as implemented must provide SIEM configuration, alarm criteria, evaluation routines and documented incident responses. Anyone who declares A.5.23 Cloud Services to have been implemented needs cloud inventory, risk assessments per provider and AV contracts. Others run compliance like a filing cabinet. We run it like software.

The eleven new controls are the most common stumbling blocks in transition audits. A.5.7 Threat Intelligence requires a documented process for gathering and evaluating threat intelligence, not just a subscription to a threat feed. A.5.23 ICloud Services requires documented procurement, use and termination of cloud services, including exit strategy.

A.5.30 ICT Readiness for Business Continuity explicitly relates business continuity to IT, with BIA, RTO, RPO and testing. A.7.4 Physical Security Monitoring extends physical monitoring to include documented detection and response. A.8.9 Configuration Management requires target configurations, deviation management, inventory. A.8.10 Information Deletion requires verifiable deletion procedures across life cycles, including cloud.

A.8.11 Data Masking, A.8.12 Data Leakage Prevention, A.8.16 Monitoring Activities, A.8.23 Web Filtering and A.8.28 Secure Coding supplement technical controls that were previously implicitly covered by other measures. Auditors have been demanding explicit evidence since 2024. A 2022 SoA template must contain these eleven controls in full, with a clear implementation status and concrete evidence, even if the applicability is restricted in individual cases.

The SoA does not stand alone. Section 6.1.2 of the standard requires a risk assessment process, 6.1.3 a) to c) the risk treatment plan. SoA, risk register and treatment plan are three linked documents that are checked together in the audit. Auditors pull a risk from the register, look for the assigned controls in the SoA and demand evidence from the treatment plan and the line.

A reliable template therefore maintains a risk ID column in the SoA and vice versa a control list per risk in the register. Mutual linking not only speeds up the audit, but also makes gaps visible: a risk without addressing controls, a control without a risk reference, a treatment plan without an SoA entry. The CIVAC-ISMS automatically links these three layers in the workspace.

In operation, this means that every risk change triggers an SoA check and every control change becomes visible in the register. The ISO/IEC 27001:2022 ISMS standard requires this consistency not just once a year, but as an ongoing process. The auditor calls, the evidence is ready. The SoA is the first point in the audit where a non-functional operation becomes visible.

The SoA is a document that requires control according to Section 7.5 of the standard. Required are identification, format, release, checking at scheduled intervals, protection against unintentional changes and version management. In practice, this means a unique document number, responsibility with the information security officer, approval from top management and a review interval of usually twelve months.

An ongoing maintenance cycle includes six triggers. Firstly, risk assessment updates, secondly, new or changed controls during standard revisions, thirdly, regulatory changes such as NIS-2 or DORA, fourthly, organisational changes such as acquisitions or relocations, fifthly, incidents with lessons learned, sixthly, annual management reviews according to Section 9.3.

If you only clean up the SoA shortly before the audit, you risk inconsistencies with the risk register, treatment plan, internal audits and incident reports. Auditors check care data as an indication of whether the ISMS is alive. An SoA with a date from the day before the inspection is suspicious, an SoA with a twelve-month care history is convincing. The external information security officer takes over this maintenance on a mandate.

Before a certification audit, experienced ISBs use the SoA as a central preparation axis. Three steps lead to audit readiness. Firstly, consistency check against risk register and treatment plan: every risk ID must be found in the SoA, every selected control in the risk register. Secondly, a sample of evidence: two to three controls are selected per subject area and the documented status is compared with the reality in the line.

Thirdly, mock interviews with those responsible. Auditors do not ask the ISMS team, but rather the HR manager about A.6.3 Information Security Awareness or the IT operations lead about A.8.9 Configuration Management. Anyone who hesitates here or gives different answers than the SoA produces findings. Good preparation simulates these conversations.

Stage 1 audits check the documentation and identify gaps, Stage 2 checks the effectiveness in the line. For transition audits in 2022, the inspection is shortened, but the requirements for the SoA are stricter. The CIVAC SoA template is linked to the 490 audit templates and takes you through Stage-1 and Stage-2 in one run, with clear preparation steps and reminders before the planned audits.

The initial creation of an SoA in a medium-sized company without previous experience takes six to twelve weeks, depending on the maturity of the existing documentation. If you start with an empty template and 93 controls, you will need an average of two to four hours per control for assessment, justification, collection of evidence and internal coordination.

Consulting offers for SoA creation range between 15,000 and 80,000 euros, depending on size and depth. An ongoing ISB mandate reduces this effort because the SoA becomes part of the monthly reporting line and does not have to be rebuilt annually. The most common pitfalls are three. Firstly, copy-paste justifications that are immediately noticeable in the sample. Secondly, non-versioned attachments, which are confused with the auditor in the discussion. Thirdly, there is no link to the GDPR-TOM documentation, which creates double effort according to NIS-2 and ISO.

The SoA is not a one-off document, but rather the audit hinge of the ISMS. Anyone who keeps them as a table in a folder has a documentation problem. Anyone who runs it as a linked module in the workspace has a business. CIVAC maintains SoA, risk register and treatment plan in one structure, with EU data residency and audit-proof versioning.

A template does not solve the SoA problem. It only solves the first day. The difficulty lies in the care, in the integration with the risk register and treatment plan and in the proof across audits. Anyone facing the transition obligation in 2026 will need neither a new Word document nor a new Excel spreadsheet, but rather a company that will keep the SoA alive.

CIVAC is a compliance platform and officer-as-a-service. In the workspace you will find an ISO/IEC 27001:2022 SoA template with all 93 controls, linked to risk register, treatment plan, 490 audit templates, internal audit calendar and reporting line to management. EU data residency, audit-proof versioning, appointment certificate for the ISB in the standard. Licence the workspace for your internal representatives, or have our representatives order it.

Turn reading into a mandate. Write to info@civac.de or use the contact form on civac.de. You will receive an initial SoA agreement with your current ISMS status and a migration plan to the 2022 version within two working days, instead of the industry-standard two to six week lead time.