ISO 27001:2022 Statement of Applicability Generator — SoA Template

What is a Statement of Applicability?

The Statement of Applicability (SoA) is a mandatory document required by ISO 27001:2022 clause 6.1.3 d. It sits at the heart of your Information Security Management System (ISMS) and serves as the documented record of your control selection decisions. Every organisation seeking ISO 27001 certification must produce and maintain an SoA — it is one of the first documents your certification auditor will ask to see.

The SoA performs several critical functions. First, it lists all 93 controls from Annex A and records whether each control is applied or not applicable. For applied controls, it captures the implementation status, the justification for inclusion, and who is responsible. For excluded controls, it documents the rationale for exclusion — demonstrating that the decision was deliberate rather than an oversight. Second, it acts as the bridge between your risk assessment (the identification of risks to your information assets) and your risk treatment plan (the specific controls you deploy to address those risks). Without a properly completed SoA, an auditor cannot confirm that your ISMS is complete or that your control selection is systematic rather than arbitrary.

The SoA is not a static document. ISO 27001 requires it to be maintained throughout the life of the ISMS, meaning it must be reviewed and updated whenever your organisation changes — when you adopt new technologies, enter new markets, change your operating model, or experience security incidents that reveal gaps in your control coverage. Most organisations review their SoA annually as part of their management review cycle and update it whenever a significant risk assessment is conducted. The SoA also serves as a useful input to internal audit programmes — internal auditors can use the SoA as a checklist to verify that the controls you claim are implemented actually operate effectively.

The regulatory and standards context

The Statement of Applicability is defined in ISO 27001:2022 clause 6.1.3, which requires the organisation to "determine all controls that are necessary to implement the risk treatment options" and to "produce a Statement of Applicability that contains the necessary controls and justification for inclusions, exclusions, and the implementation status." This clause sits within the Plan phase of the Plan-Do-Check-Act (PDCA) cycle that underpins the entire ISO 27001 standard.

The transition from ISO 27001:2013 to ISO 27001:2022, which all certified organisations must complete by October 2025, introduced several changes relevant to the SoA. The number of controls was reduced from 114 to 93, with 24 controls merged or consolidated, 11 new controls added (including threat intelligence, ICT readiness for business continuity, physical security monitoring, data masking, data leakage prevention, web filtering, secure coding, and security testing in development and acceptance), and the remaining controls renumbered and reorganised into four clauses instead of 14. If your organisation is transitioning between versions, your SoA must be updated to reflect the 2022 control structure — the old 2013 SoA is no longer valid for certification audits conducted after the transition deadline.

Beyond ISO 27001 itself, the SoA is often referenced in other compliance frameworks. Organisations that also need to meet SOC 2, Cyber Essentials Plus, the NCSC CAF, or NIST CSF requirements can use their SoA as a baseline for mapping controls across frameworks — identifying where a single control satisfies multiple requirements and where additional controls specific to each framework are needed. This "control mapping" approach is significantly more efficient than maintaining separate compliance documentation for each standard.

The four clauses of Annex A in detail

Clause A.5 — Organisational controls (37 controls)

Clause A.5 is the largest and most diverse of the four clauses, covering the organisational and governance foundations of your ISMS. It begins with the information security policy (A.5.1) and the assignment of security roles and responsibilities (A.5.2) — the two controls that establish accountability at the executive level. From there it covers segregation of duties (A.5.3) to prevent conflicts of interest, management responsibilities (A.5.4) to ensure leadership engagement, and contact with authorities (A.5.5) and special interest groups (A.5.6) to keep the organisation connected to the wider security community. The new A.5.7 (threat intelligence) reflects the increasing importance of proactive threat awareness in modern security programmes.

A significant portion of A.5 addresses asset management. Controls A.5.9 through A.5.13 cover the complete asset lifecycle — maintaining an accurate inventory of information assets, defining acceptable use, ensuring assets are returned when people leave, classifying information based on sensitivity, and labelling assets according to that classification. These controls provide the foundation for everything else in the ISMS because you cannot protect what you do not know about. The access control cluster (A.5.15–A.5.18) covers the access control policy itself, identity management, authentication information security, and periodic review of access rights — forming the operational core of who can access what.

Supplier security is addressed by controls A.5.19–A.5.23, covering security requirements in supplier relationships, contractual security provisions, ICT supply chain risk management, ongoing monitoring of supplier services, and the new dedicated control for cloud services (A.5.23). Given the prevalence of cloud adoption and supply chain attacks, these controls have become some of the most heavily scrutinised by certification auditors. The incident management cluster (A.5.24–A.5.28) covers planning, assessment, response, learning from incidents, and evidence collection — forming a complete incident management lifecycle. Business continuity (A.5.29–A.5.30) addresses information security during disruption and ICT readiness for continuity, while the remaining controls cover compliance with legal and regulatory requirements (A.5.31), intellectual property rights (A.5.32), protection of records (A.5.33), privacy and PII protection (A.5.34), independent review (A.5.35), compliance with policies (A.5.36), and documented operating procedures (A.5.37).

Clause A.6 — People controls (8 controls)

Clause A.6 addresses the human dimension of information security — often described as the most unpredictable and therefore most critical element of any security programme. The clause opens with screening (A.6.1), which covers pre-employment background checks proportionate to the sensitivity of the role, and terms and conditions of employment (A.6.2), which ensures security responsibilities are documented in contracts and job descriptions. Control A.6.3 (information security awareness, education and training) is one of the most operationally significant controls in the entire standard — it requires organisations to deliver regular security awareness training, with role-specific content for people in sensitive positions, covering topics such as phishing recognition, password hygiene, data handling procedures, and incident reporting obligations.

Controls A.6.4 and A.6.5 cover the disciplinary process for security violations and the offboarding process for terminating or changing employment — ensuring that access is revoked promptly, assets are recovered, and departing personnel are reminded of their ongoing confidentiality obligations. Confidentiality or non-disclosure agreements (A.6.6) provide the legal foundation for protecting sensitive information. The new A.6.7 (remote working) has become one of the most relevant controls in the post-pandemic era, requiring policies and secure configurations for remote access including VPN, endpoint security, device encryption, and acceptable use. The clause closes with information security event reporting (A.6.8), which requires organisations to provide a clear and accessible mechanism for personnel to report security events, supported by a non-punitive culture that encourages reporting rather than hiding mistakes.

Clause A.7 — Physical controls (14 controls)

Clause A.7 covers the physical security of premises, equipment, and media — controls that are sometimes overlooked by organisations focused primarily on technical security measures but are equally important for a complete ISMS. Physical security perimeters (A.7.1) and physical entry controls (A.7.2) establish the first line of defence for your premises, while securing offices, rooms, and facilities (A.7.3) addresses internal physical security. The new A.7.4 (physical security monitoring) formalises the requirement for surveillance of physical perimeters using CCTV, intrusion detection, and alarm systems with defined retention periods.

Protecting against physical and environmental threats (A.7.5) covers fire, flood, earthquake, power failure, and extreme temperatures — risks that are often excluded from information security risk assessments but can be as devastating as a cyber attack. Working in secure areas (A.7.6) and clear desk and clear screen (A.7.7) address day-to-day physical security behaviour, while equipment siting and protection (A.7.8) and security of assets off-premises (A.7.9) cover the protection of devices both in the office and in remote working locations. The remaining controls cover storage media lifecycle management (A.7.10), supporting utilities including power and HVAC (A.7.11), cabling security (A.7.12), equipment maintenance (A.7.13), and secure disposal or re-use of equipment (A.7.14) — including cryptographic erasure, degaussing, and physical destruction.

Clause A.8 — Technological controls (34 controls)

Clause A.8 is the largest clause, containing 34 controls covering the technical security measures that most people associate with cybersecurity. It opens with user endpoint devices (A.8.1) — covering laptops, desktops, mobile phones, and tablets with requirements for full-disk encryption, endpoint protection, patch management, and device policy enforcement. Privileged access rights (A.8.2) and information access restriction (A.8.3) establish the principle of least privilege, with A.8.2 specifically requiring just-in-time privileged access and approval workflows for administrative activities. Access to source code (A.8.4) and secure authentication (A.8.5) address developer access controls and authentication methods including password complexity, MFA, and account lockout policies.

The technical operations cluster (A.8.6–A.8.9) covers capacity management to prevent resource exhaustion, protection against malware through endpoint detection and response controls, management of technical vulnerabilities including vulnerability scanning and patch management, and configuration management using secure baseline configurations such as CIS Benchmarks and NCSC guidance. Information deletion (A.8.10), data masking (A.8.11 — new in 2022), and data leakage prevention (A.8.12 — also new in 2022) address data lifecycle controls from secure deletion through anonymisation to DLP. Information backup (A.8.13) and redundancy of information processing facilities (A.8.14) ensure business continuity through data protection and system resilience. Logging (A.8.15), monitoring activities (A.8.16), and clock synchronisation (A.8.17) form the detective control layer — enabling organisations to detect, investigate, and respond to security events.

Network security controls (A.8.20–A.8.23) cover securing network services, network segregation into security zones, and web filtering to block access to malicious websites and phishing sites. Use of cryptography (A.8.24) requires organisations to define cryptographic policies covering algorithm selection, key management, certificate lifecycle, and encryption for both data-in-transit and data-at-rest. The secure development cluster (A.8.25–A.8.31) addresses the full software development lifecycle — from security requirements and secure architecture principles through secure coding practices (A.8.28), security testing (A.8.29), outsourced development (A.8.30), and separation of development, test, and production environments (A.8.31). The clause closes with change management (A.8.32), test information protection (A.8.33), and protection of information systems during audit testing (A.8.34).

How to determine applicability — a practical framework

Determining whether each of the 93 controls is applicable to your organisation is the central intellectual work of creating an SoA. There is no simple formula — applicability depends on your organisation's context, the results of your risk assessment, your legal and regulatory obligations, and your risk appetite. However, a structured decision framework can make the process systematic and defensible.

Step 1: Reference your risk assessment. For each control, ask: "Does my risk assessment identify a risk that this control would address?" If the answer is yes, the control should typically be marked as Applied. For example, if your OCTAVE or equivalent risk assessment identifies a risk of data exfiltration, then data leakage prevention (A.8.12) is clearly applicable. If no risk is identified, proceed to Step 2.

Step 2: Check legal, regulatory, and contractual obligations. Some controls are applicable regardless of your risk assessment because the law requires them. Control A.5.34 (privacy and protection of PII) is applicable to any organisation processing personal data of UK or EU residents, regardless of risk appetite. Similarly, if your contracts require specific controls — such as access control (A.5.15) or logging (A.8.15) — those controls are applicable by agreement. If no obligation exists, proceed to Step 3.

Step 3: Assess organisational context. Some controls are applicable because of the nature of your organisation, industry, or operations. Financial services organisations will find controls related to segregation of duties (A.5.3) and logging (A.8.15) particularly relevant. Healthcare organisations will prioritise privacy controls (A.5.34). Organisations with significant remote workforces will need remote working (A.6.7). Organisations that develop software will need the secure development controls (A.8.25–A.8.31). If none of these contextual factors apply, proceed to Step 4.

Step 4: Consider exclusion. If a control does not address an identified risk, is not required by law or contract, and is not relevant to your organisational context, it may be legitimately excluded. Common examples include excluding cloud services (A.5.23) if your organisation does not use any cloud services, excluding physical security controls (A.7.x) if your organisation is fully remote and has no physical premises, or excluding outsourced development (A.8.30) if all development is in-house. Each exclusion must be documented with a clear rationale — a sentence or two explaining why the control is not relevant to your organisation.

One important principle is that excluding controls does not weaken your ISMS — a targeted, well-justified SoA with 60 applied controls is stronger than a blanket SoA with all 93 controls marked as applied but with no evidence of genuine implementation. Certification auditors are trained to recognise SoAs where controls have been included without proper justification, and will probe the implementation evidence for those controls during their assessment. It is far better to be honest about what is and is not relevant to your organisation than to claim applicability for all controls without the implementation to back it up.

Common mistakes to avoid

First-time SoA creators often fall into several predictable traps. The most common is blanket applicability — marking all 93 controls as Applied because it feels safer than justifying exclusions. This approach backfires because auditors will verify implementation evidence for every control you claim, and failing to produce evidence for even a few controls can result in non-conformities. A better approach is to be selective and honest, focusing on the controls that genuinely address your risks and context.

Another common mistake is vague or circular justifications. Writing "this control is applied because it is required by ISO 27001" does not demonstrate that you have actually considered whether the control is relevant to your specific organisation — it simply restates the standard. A proper justification explains why the control matters in your particular context, such as: "A.8.12 (data leakage prevention) is applied because our risk assessment identified a high risk of sensitive customer data being exfiltrated through email and cloud applications, and DLP controls are necessary to detect and prevent such transmission."

A third trap is treating the SoA as a one-time exercise. Organisations that create their SoA solely for the certification audit and never review it again will find themselves with an outdated document that does not reflect their actual operating environment. The SoA must be maintained throughout the certification cycle — updated whenever significant changes occur and reviewed at least annually. Many certification bodies expect to see evidence that the SoA has been reviewed as part of the management review process (clause 9.3).

Finally, avoid disconnect between the SoA and your risk assessment. If your risk assessment identifies a risk of ransomware but your SoA excludes A.8.7 (protection against malware) and A.8.8 (management of technical vulnerabilities), an auditor will immediately flag the inconsistency. The SoA must logically follow from the risk assessment — every control you apply should trace back to a specific risk or obligation, and every risk should be addressed by one or more controls. This traceability is what auditors look for when reviewing your ISMS documentation.

Preparing for an ISO 27001 audit with your SoA

Your SoA will be one of the first documents your certification auditor requests, typically during Stage 1 of the certification process. The auditor will review it to understand the scope of your ISMS, your approach to risk treatment, and whether your control selection appears complete and justified. They will look for several specific things: whether all 93 controls have been addressed (none omitted), whether the justifications for inclusion and exclusion are clear and specific to your organisation, whether the implementation status claims are realistic, and whether the SoA is consistent with your risk assessment report and risk treatment plan.

During Stage 2 (the main assessment), the auditor will select a sample of controls from your SoA and verify that they have been implemented as claimed. If your SoA states that A.8.13 (information backup) is fully implemented with daily backups and quarterly restoration testing, the auditor will ask to see backup logs, restoration test results, and the documented backup policy. The quality of your evidence directly affects the audit outcome — a well-maintained SoA supported by strong evidence demonstrates a mature ISMS, while discrepancies between the SoA and actual practice will result in non-conformities that must be remediated before certification can be granted.

After certification, the SoA continues to play a role in surveillance audits (typically annual) and recertification audits (typically every three years). During surveillance audits, the auditor will check whether the SoA has been maintained and whether any changes to the organisation have been reflected in updated applicability decisions. A common finding during surveillance audits is that the SoA has not been updated since the initial certification — demonstrating the importance of treating the SoA as a living document rather than a static artefact.

Maintaining and reviewing your SoA

ISO 27001 clause 6.1.3 requires the SoA to be "maintained as documented information," meaning it must be kept up to date throughout the life of the ISMS. Practical triggers for SoA review include: when your risk assessment is updated (new risks may require new controls, or controls addressing previously identified risks may no longer be relevant), when your organisation undergoes significant change (mergers and acquisitions, new services or products, entry into new markets, new regulatory obligations), when you adopt new technologies (cloud migration, new software platforms, IoT devices), when security incidents occur (incidents may reveal gaps in control coverage that need to be addressed in the SoA), and at planned intervals (most organisations schedule an annual SoA review as part of their management review process).

The review process should involve the information security manager, the DPO where privacy controls are affected, the heads of relevant business units, and the ISMS management representative. Changes to the SoA should be documented with version control and approval records, and the updated SoA should be communicated to relevant stakeholders. For organisations using this SoA generator, we recommend exporting the final SoA as both XLSX (for ongoing maintenance and analysis) and PDF (for audit submission and management approval), and storing both versions in your document management system alongside your risk assessment and risk treatment plan.

Using the SoA with other GovernStack tools

This SoA generator is designed to work as part of an integrated ISMS documentation toolkit alongside other GovernStack tools. The OCTAVE Risk Assessment Tool provides the risk assessment output that directly informs your SoA decisions — risks identified in your OCTAVE assessment should map to specific Annex A controls that you mark as Applied. The Risk Matrix Generator can visualise the risks that drive your control selections, providing a clear graphical representation of your risk profile for management presentations and board reporting.

The DPIA Tool addresses the privacy-specific requirements referenced in A.5.34 (privacy and protection of PII), helping you document your data protection impact assessments in accordance with UK GDPR Article 35. The GDPR Fine Estimator and Data Breach Cost Calculator help quantify the financial impact of control failures, providing a business case for investment in ISMS improvements. Together, these tools cover the full ISMS lifecycle — from risk assessment through control selection, implementation, and compliance monitoring — all within your browser with no data transmitted to any server.

Frequently asked questions about the Statement of Applicability

Does my SoA need to be approved by management?

Yes — ISO 27001 requires that the SoA, like other ISMS documentation, is approved by the relevant management authority. This typically means the information security manager and the senior management representative for the ISMS. Approval demonstrates management commitment and accountability for the control selection decisions documented in the SoA.

Can I add controls that are not in Annex A?

Yes. Annex A provides a reference set of controls, but organisations are not limited to these. If your risk assessment identifies risks that require controls not listed in Annex A, you should include them in your risk treatment plan and reference them in your SoA. This demonstrates a risk-driven rather than checklist-driven approach to information security.

How many controls should I expect to mark as Not Applicable?

This depends entirely on your organisation's context. A small professional services firm with no physical premises, no cloud services, and no software development might reasonably exclude 20–30 controls. A large technology company with physical data centres, cloud infrastructure, software development, and a global workforce might exclude fewer than 5. There is no target number — the right number is whatever is justified by your risk assessment and organisational context.

Can an external auditor or consultant help with my SoA?

Absolutely — and for first-time certification, it is strongly recommended. An experienced ISO 27001 lead auditor or consultant can review your draft SoA for completeness, consistency, and audit-readiness. They can identify gaps in your justifications, flag controls that may be relevant based on their experience with similar organisations, and help you prepare evidence packages for the controls you have implemented. However, the SoA must ultimately reflect your organisation's decisions — a consultant should guide, not dictate, control selection.