The Statement of Applicability is the document certification auditors open first and the one most organisations treat as a spreadsheet to fill in once. ISO/IEC 27001:2022 requires it as the record of which controls you need, why, whether they are implemented, and why any Annex A control is excluded. A good SoA links each decision to the risk assessment, names an owner and points to evidence; a weak one lists 93 controls marked "applicable" with no reasoning. This template gives you the document control, decision rules, register columns and worked example rows, including entries for service accounts, API keys and other non-human identities. It is for ISMS managers, internal auditors and consultants preparing for certification or a surveillance audit. For the standard and the certification process, see the ISO 27001 Certification Guide.
How to use this template
- Replace text in square brackets, such as [Organisation], [ISMS Manager] and [Risk Owner], with your own names and roles.
- Build the register in a spreadsheet or GRC tool using the columns in section 6, one row per Annex A control (93 in ISO/IEC 27001:2022) plus any additional controls you have selected from other sources.
- Complete section 5 (decision rules) before filling the register, so every inclusion and exclusion follows the same logic.
- Every row must trace to the risk treatment plan, a legal, regulatory or contractual requirement, or a documented business need. "Best practice" alone is a weak justification.
- The worked rows in section 6 are examples, not recommendations for your organisation. Rewrite the justification and evidence for your own context.
- Have the SoA approved by top management or the designated risk owners, and keep it under version control as documented information.
1. Purpose
This Statement of Applicability (SoA) records the information security controls that [Organisation] has determined are necessary to implement its information security risk treatment, the justification for including each control, whether each control is implemented, and the justification for excluding any control listed in Annex A of ISO/IEC 27001:2022. It satisfies the requirement for a Statement of Applicability in clause 6.1.3 d) of ISO/IEC 27001:2022 and is maintained as documented information under clause 7.5.
2. Scope
This SoA applies to the information security management system (ISMS) of [Organisation] as defined in the ISMS Scope Statement [document reference, version], covering:
- [Business units, products and services in scope]
- [Locations and facilities in scope]
- [Technology platforms in scope, including cloud tenants and SaaS applications]
- [Interfaces and dependencies with out-of-scope parts of the organisation and third parties]
Where a control is implemented by a third party (for example a cloud service provider), the SoA records the control as applicable and identifies the provider and the evidence relied on.
3. Document control and approval
| Field | Value |
|---|---|
| Document ID | [ISMS-SOA-001] |
| Version and date | [1.0, DD Month YYYY] |
| Owner | [ISMS Manager] |
| Approved by | [Chief Information Security Officer / Risk Committee], on behalf of top management |
| Related documents | [ISMS Scope Statement], [Risk Assessment Methodology], [Risk Register], [Risk Treatment Plan], [Legal and Contractual Requirements Register] |
| Standard edition | ISO/IEC 27001:2022 (including Amd 1:2024) |
| Classification | [Internal / Confidential] |
| Review frequency | At least annually and on significant change (section 9) |
4. Roles and responsibilities
- [ISMS Manager]: maintains the SoA, ensures every row is consistent with the risk treatment plan, and presents changes for approval.
- Control owners: confirm implementation status and evidence for their controls at least [quarterly], and report changes.
- Risk owners: approve the risk treatment plan and accept residual risk, including risks arising from excluded controls.
- [Internal Audit]: samples SoA rows during internal audits and verifies that evidence exists and supports the stated status.
- Top management: approves the SoA and its major revisions.
5. Applicability decision rules
[Organisation] applies the following rules when deciding inclusion or exclusion.
- Risk-driven inclusion: a control is included when it is needed to treat one or more risks in the risk register. Record the risk IDs.
- Requirement-driven inclusion: a control is included when a law, regulation or contract requires it (for example [GDPR Article 32], [customer contract clause], [PCI DSS]). Record the requirement reference.
- Annex A comparison: after selecting controls through risk treatment, [Organisation] compares them with Annex A to check that no necessary control has been omitted, as clause 6.1.3 c) requires.
- Exclusion criteria: a control may be excluded only when the related activity, asset or risk does not exist in scope (for example no outsourced development), and the justification states why. Cost or inconvenience is not a valid exclusion reason; a risk that is accepted rather than treated is recorded in the risk register, and the control remains listed with that explanation.
- Additional controls: controls from other sources (for example NIST SP 800-53, CIS Controls or sector standards) are added as extra rows when the risk treatment needs them.
- Status values: Implemented, Partially implemented, Planned (with target date in the risk treatment plan), Not implemented. Only Implemented rows are claimed as operating.
6. Statement of Applicability register
6.1 Register columns
| Column | Content |
|---|---|
| Control ID and name | Annex A reference (for example A.5.15 Access control) or the ID of an additional control |
| Theme | Organisational (A.5, 37 controls), People (A.6, 8), Physical (A.7, 14), Technological (A.8, 34) |
| Applicable | Yes or No |
| Justification | Risk IDs, requirement references or business need for inclusion; reason for exclusion |
| Implementation status | Implemented, Partially implemented, Planned, Not implemented |
| Implementation summary | One or two sentences on how the control is met, naming the policy, procedure or technology |
| Control owner | Role, not individual name, where possible |
| Evidence | Document references, system reports or records an auditor can sample |
| Third party | Provider that operates all or part of the control, and the assurance relied on |
| Last reviewed | Date the owner last confirmed status |
Optionally add the ISO/IEC 27002:2022 attributes (control type, information security properties, cybersecurity concepts, operational capabilities, security domains) to filter the register, and a column mapping each control to NIST CSF 2.0 or other frameworks you report against. See the NIST CSF to ISO 27001 Mapping Guide.
6.2 Worked example rows
| Control | Applicable | Justification | Status | Implementation summary and evidence |
|---|---|---|---|---|
| A.5.15 Access control | Yes | Risks [R-012, R-019]; [customer contract clause 8.2] | Implemented | Access Control Policy v[x] covers user and non-human accounts; evidence: policy, quarterly access review reports |
| A.5.16 Identity management | Yes | Risks [R-012, R-031 unmanaged service accounts] | Partially implemented | Joiner, mover and leaver process via IdP; service account register covers [80%] of known accounts, completion in risk treatment plan [RTP-07]; evidence: register export |
| A.5.17 Authentication information | Yes | Risks [R-031, R-044 leaked secrets] | Implemented | Secrets stored in [vault]; API keys rotated per [standard]; secret scanning in repositories; evidence: rotation logs, scanner reports |
| A.5.18 Access rights | Yes | Risk [R-019] | Implemented | Quarterly reviews including service principals and OAuth grants; evidence: signed review records |
| A.5.19 Information security in supplier relationships | Yes | Risks [R-050 supplier compromise] | Implemented | Supplier tiering and SOC 2 or ISO certificate review; evidence: supplier register, review notes |
| A.5.23 Information security for use of cloud services | Yes | Risks [R-052]; cloud-first strategy | Implemented | Cloud Security Standard; shared responsibility mapped per provider; evidence: standard, provider attestations |
| A.6.7 Remote working | Yes | All staff hybrid; risk [R-060] | Implemented | Remote Working Policy; managed devices only; evidence: MDM compliance report |
| A.7.4 Physical security monitoring | [No] | [No owned premises in scope; office space in a serviced building and data hosted in cloud data centres covered by provider attestations under A.5.23] | n/a | [Provider certificates reviewed annually] |
| A.8.2 Privileged access rights | Yes | Risks [R-013, R-031] | Implemented | PAM for admin roles, just-in-time elevation, no standing admin for automation accounts; evidence: PAM reports |
| A.8.5 Secure authentication | Yes | Risks [R-012, R-040 credential phishing] | Implemented | Phishing-resistant MFA for staff; workload identity federation instead of static keys where supported; evidence: IdP policy export |
| A.8.15 Logging | Yes | Risks [R-070]; [regulatory retention requirement] | Implemented | Central log platform, retention [x] months, includes service account activity; evidence: log source inventory |
| A.8.30 Outsourced development | [No] | [No software development is outsourced; all development performed by employees under A.8.25 to A.8.29] | n/a | [Reassess if a development supplier is engaged] |
Exclusions such as A.7.4 and A.8.30 above only hold while the stated condition is true. Record the condition so the review in section 9 can test it.
7. Non-human identity entries
Service accounts, API keys, OAuth applications, certificates, workload identities and AI agents fall within several Annex A controls. [Organisation] records them explicitly so the SoA does not imply that identity controls cover people only.
| NHI concern | Annex A controls | Evidence to reference |
|---|---|---|
| Inventory and ownership of service accounts and agents | A.5.9, A.5.16 | NHI register with owner, purpose, environment |
| Storage, rotation and revocation of secrets and keys | A.5.17, A.8.24 | Vault policies, rotation logs, key management procedure |
| Least privilege and review of machine permissions | A.5.15, A.5.18, A.8.2 | Access review records including service principals and OAuth grants |
| Strong authentication for workloads | A.8.5 | Certificate or federation configuration, list of remaining static credentials |
| Monitoring machine activity | A.8.15, A.8.16 | Detection rules for anomalous service account use |
| Third-party integrations and tokens | A.5.19, A.5.23 | Integration register and supplier reviews |
See the Service Account Inventory Template and the Secrets Management Guide for the supporting records.
8. Implementation status and evidence
- Control owners confirm the status and evidence for each row at least [quarterly] and update the "Last reviewed" date.
- Rows marked Partially implemented or Planned must reference a risk treatment plan item with an owner and target date.
- Evidence references must point to records that exist at the time of audit, not to future deliverables.
- The [ISMS Manager] reports SoA metrics to the [Risk Committee]: share of applicable controls Implemented; number of Planned controls past target date; rows not reviewed in the last [two] quarters; exclusions whose condition was re-tested in the last review.
9. Review and change control
The SoA is reviewed at least annually, and also when:
- the risk assessment is updated or a significant new risk is identified;
- the ISMS scope changes, including new locations, products, cloud platforms or acquisitions;
- a legal, regulatory or contractual requirement changes;
- a nonconformity or incident shows a control was missing or ineffective;
- a new edition or amendment of ISO/IEC 27001 is published.
Each revision records the version, date, changed rows, reason and approver. Superseded versions are retained for [three] years as documented information.
Implementation guidance
- Start from risk treatment, not Annex A: clause 6.1.3 asks you to determine the controls needed for risk treatment and then compare them with Annex A. Starting from the Annex A list and marking everything applicable produces an SoA with no reasoning, which auditors notice.
- Keep justification specific: a risk ID and one sentence beats a paragraph of generic text. Auditors sample rows and follow the trail to the risk register and evidence.
- Small organisations: a spreadsheet with the section 6.1 columns is enough. Keep it short and accurate rather than elaborate.
- Large organisations: manage the register in a GRC tool, link evidence automatically where possible, and consider one SoA per certificate scope if business units hold separate certificates. See the Audit Evidence and Continuous Controls Monitoring Guide.
- Transition from the 2013 edition: accreditation bodies required certification bodies to complete client transitions to the 2022 edition by 31 October 2025, so any SoA still using the 114-control 2013 numbering is out of date.
- Common audit findings: exclusions without a stated condition; controls marked Implemented with no evidence; SoA versions that do not match the risk treatment plan; identity controls with no mention of service accounts or third-party integrations.
- Use it beyond certification: the SoA is a useful answer to customer security questionnaires and maps well to other frameworks. See the ISO 27002 Controls Guide and the ISO 27001 Certification Readiness Checklist.
Related NHI Mgmt Group resources: ISO 27001 Certification Guide · ISO 27002 Controls Guide · ISO 27001 Internal Audit Programme Template · ISO 27001 Certification Readiness Checklist · NIST CSF to ISO 27001 Mapping Guide