What is a statement of applicability (SoA)?

Every ISO/IEC 27001 certificate rests on one version of one document. The statement of applicability is where an organisation writes down which controls it runs and why, and a certification auditor reads it as a list of claims to test. Most of the work behind it happens before anyone writes a row.

Clause 6.1.3 d) of ISO/IEC 27001:2022 asks the statement for four things: the controls the organisation has decided are necessary, the justification for including each one, whether each one is implemented, and the justification for excluding any control in Annex A, the standard's reference list. The 2022 edition replaced the 114 controls in 14 clauses of the 2013 Annex A with 93 controls in four themes. Every certificate issued against the 2013 edition expired or was withdrawn when the transition period closed on 31 October 2025, so a statement still numbered A.5 to A.18 describes a certificate that no longer exists.

To build one as you read, use the free Statement of Applicability builder. It lists all 93 Annex A controls by theme, records applicability, a justification and an implementation status for each, and keeps the draft in your browser.

Why a statement of applicability matters

The statement is the one document where the risk assessment, the controls and their status meet. A certification body treats it as the specification of what to audit. ISO/IEC 27006-1:2024, the standard certification bodies are accredited against, guides auditors to use the statement and the documents around it as the specification of the organisation's required controls, as one certification body's published procedure renders that guidance. Under the same procedure, the certificate is issued with a version of the statement, and the audit report records which version was read.

Published certificates show it in practice. One, issued against ISO/IEC 27001:2022 and re-issued in August 2025, applies "with regard to the specific requirements for information security as stated in the Statement of Applicability, version 2024.01 dated September 10, 2024". Another, from a different certification body, limits its scope "in accordance with the statement of applicability, version 6.0, dated August 26, 2021". Change the statement and you have changed the document the certificate points at.

Three readers open it. The certification auditor reads it at stage 1, the review of the information security management system (ISMS) as designed, which Schellman describes as "largely an evaluation of your designed ISMS against the requirements", and again at stage 2, when the controls defined in the statement "will be reviewed to ensure they are operating effectively". Surveillance audits follow each year for the two years after certification, and recertification evaluates each applicable Annex A control. LRQA's description of what the auditor holds is exact: the statement "does not provide details of those controls but a traceable reference to a control statement used as the basis of the last ISO 27001 audit". In practice, a customer's security review asks for it next to the certificate, because the certificate's scope says where the controls apply and the statement says which controls they are. Management reads it as one page of what the organisation runs and why.

Without a good statement, four things go wrong. There is no certificate at all, because clause 6.1.3 d) is a requirement. Rows cannot be traced to a risk, which fails the check stage 2 makes for alignment between the controls, the statement, the risk assessment results and the treatment process. Exclusions fall at the first question: CertiKit's experience is that an auditor's "focus will often be on those controls you have excluded". And a statement left on 2013 numbering describes controls the current standard does not contain.

How a statement of applicability works, step by step

The statement is the fourth of six things clause 6.1.3 asks for, and it is quick to write once the first three are done well.

Where the statement comes from

Clause 6.1.3 requires a risk treatment process that does six things in order. It selects treatment options, taking account of the risk assessment results. It determines all the controls needed to implement those options. It compares those controls with Annex A and verifies that no necessary control has been omitted. It produces the statement of applicability. It formulates a risk treatment plan. And it obtains the risk owners' approval of the plan and their acceptance of the residual risk. The organisation keeps documented information about the whole process.

The order matters more than any single item. The risks decide the controls, and Annex A is checked afterwards. The International Accreditation Forum (IAF), which sets the rules accreditation bodies apply to certification bodies, put the purpose of the comparison in its transition document, IAF MD 26: "By comparing the necessary information security controls to those in Annex A, the organization may confirm that any necessary information security control from the reference set in Annex A of ISO/IEC 27001:2022 is not inadvertently omitted." If the comparison turns up a control that was missed, the organisation updates its risk treatment plans and implements it.

Annex A is normative, so the comparison is required. It is a reference set to check completeness against, and it does not oblige anyone to implement all 93 controls. The notes to clause 6.1.3 go further: controls can be designed by the organisation or taken from any source, and Annex A is not exhaustive. The guidance in ISO/IEC 27005:2022 closes the loop from the other side, as Chris Hall quotes it: only controls identified in the risk assessment belong in the statement, and the controls needed for the chosen treatments and the statement should be consistent.

What one row holds

A row carries the four items clause 6.1.3 d) names: the control, whether it is applicable, the justification, and whether it is implemented. Practice adds four more that an auditor will ask for anyway: the control's owner, a reference to the evidence, the treatment plan item for anything not yet implemented, and the date the row was last reviewed.

The justification is the field auditors read hardest, and it has two forms. A justification for inclusion names the risk IDs the control treats, or the law, contract or policy that requires it. A justification for exclusion states a fact about the scope that someone can check. "Required by ISO 27001" justifies nothing, because Annex A is a reference set and the standard requires none of its controls by name.

ISO/IEC 27005:2022 allows a single statement of inclusion to cover every control identified in the risk assessment, and it describes implementation status as implemented, partially implemented or not implemented, given per control or as an overall statement. Both shortcuts are permitted, and both cost time at stage 2. A blanket inclusion statement makes the stage 2 auditor rebuild the link between each control and its risks, which is the link the row should have carried, and an overall status hides the controls that are actually behind.

The statement and the risk treatment plan

The statement and the plan are consecutive items in the same clause, and they answer different questions. The statement says which controls are necessary and why. The plan says who will implement each missing or partial control, by when, and with what. Clause 6.1.3 f) then names who approves the plan: the risk owners, who also accept the residual risk that remains. The risk register guide covers how that acceptance is recorded.

ISO names an approver for the plan and none for the statement. Clause 7.5.2 still applies, because it requires documented information to be reviewed and approved for suitability and adequacy when it is created and updated, and clause 7.5.3 asks for control of changes such as version control. So the statement carries a version, a date and an approver, and most organisations have top management or the management system's owner sign it.

Reading Annex A with the 2022 attributes

ISO/IEC 27002:2022, published on 15 February 2022, is where the 93 controls are described, and it gave each one five attributes: control type (preventive, detective or corrective), information security properties (confidentiality, integrity, availability), cybersecurity concepts (identify, protect, detect, respond, recover), operational capabilities, and security domains (governance and ecosystem, protection, defence, resilience). Sorting Annex A by attribute is a fast second pass when checking for omissions. Read every corrective control and ask whether your incidents would need it; read every control tagged availability and ask whether a risk to availability is treated. Readers coming from a 2013 statement should also read the 11 controls new in 2022: 5.7 Threat intelligence, 5.23 Information security for use of cloud services, 5.30 ICT readiness for business continuity, 7.4 Physical security monitoring, 8.9 Configuration management, 8.10 Information deletion, 8.11 Data masking, 8.12 Data leakage prevention, 8.16 Monitoring activities, 8.23 Web filtering and 8.28 Secure coding.

The nine steps

Steps 2 and 3 are the treatment decisions the cyber risk assessment guide hands over, and step 5 is where most statements are won or lost. The free Statement of Applicability builder puts a justification field beside every Annex A control for that step.

A worked example: one payroll company's statement after its 2026 assessment

A 280-person payroll software company in Melbourne runs payroll for about 1,900 employer customers. It has held ISO/IEC 27001:2022 certification since August 2025, and its certificate cites Statement of Applicability version 2.0, dated 30 June 2025. The platform runs in a public cloud provider's Sydney region. The scope of its management system is the payroll platform, the support desk and the Melbourne office that runs them. Priya Raman, Head of Security, owns the statement. All names and figures are fictional, and the company is the one whose annual risk assessment the cyber risk assessment guide follows.

Where the assessment left it. On 7 September 2026 six scenarios went onto the register. Three exceeded the appetite threshold of 10 set for customer funds and payroll data. S1 is a caller posing as a customer's payroll officer who has the support desk reset that officer's multi-factor authentication (MFA), then changes employees' bank details before a pay run, at level 20. S3 is exploitation of the managed file transfer server customers upload pay inputs to, at 15. S2 is ransomware against the payroll ledger in the 48 hours before a pay run, at 12. S4, S6 and S5 sat at or under the threshold. By 18 September the owners had decided to mitigate S1, S3 and S2 and to retain S4, S5 and S6 on their current controls. That is where this example starts.

The necessary controls (step 3, 21 September). Priya Raman and the risk owners name the controls each treatment needs. S1 needs 5.17 Authentication information, which here means a call-back to the employer's registered number before any MFA reset; 6.3 Information security awareness, education and training, so support staff know the published help-desk pattern; and 8.5 Secure authentication. S3 needs 8.8 Management of technical vulnerabilities, 5.7 Threat intelligence, 8.20 Networks security and 8.16 Monitoring activities. S2 needs 8.13 Information backup, 5.30 ICT readiness for business continuity and 8.7 Protection against malware. The retained risks cite the controls they rely on: 8.28 Secure coding and 5.21 Managing information security in the ICT supply chain for S4, 8.5 for S6, and the bank's file-signing requirement for S5.

The comparison with Annex A (step 4, 21 September). Priya Raman and Arjun Mehta, the platform engineering lead, read all 93 controls theme by theme. At 8.11 Data masking they stop. Version 2.0 had excluded it with "production data is never copied to test environments", which is a reason that belongs to 8.33 Test information. The support console shows full bank account numbers and tax file numbers to every support agent, and S1 is an impersonator inside a support session. Masking all but the last three digits limits what a hijacked session exposes, so 8.11 is necessary for S1 and becomes applicable.

Controls from outside Annex A (found while writing the rows). Two necessary controls had never been listed. B-1 signs each payment file and sends it only over the bank's authenticated channel; the company's channel agreement with its bank requires it, and it has operated since 2024. G-1 is application control on support desk workstations to Essential Eight Maturity Level Two, required by a state government customer's contract signed in March 2026 and in place since 31 August 2026. Both are necessary, so both get rows with their source.

The status, from the assessment (step 6). Two statuses go down. 5.17 drops from implemented to partially implemented, because the assessment found MFA resets approved on knowledge-based questions. 8.16 drops to partially implemented, because the file transfer server's logs do not reach central monitoring. 8.11 is not implemented. The exclusion of 8.30 Outsourced development stays, with its justification rewritten from "development is in-house" to a fact an auditor can check: every commit to the platform's repositories comes from employees, and two contract testers hold read-only access, on an access list reviewed on 15 September 2026.

Version 3.0 has 92 of the 93 Annex A controls applicable, with 8.30 the one exclusion, and two controls from other sources. Of its 94 necessary controls, 91 are implemented, 2 are partially implemented and 1 is not implemented.

The plan (step 7, 29 September). RTP-07 introduces call-back verification before any MFA reset, owned by Leah Moretti, Head of Customer Support, due 31 October 2026. RTP-08 sends the file transfer server's logs into central monitoring, owned by Arjun Mehta, due 15 December 2026. RTP-09 masks bank account and tax file numbers in the support console, owned by Arjun Mehta, due 26 February 2027. RTP-10 adds a quarterly restore test for S2, the first on 15 December 2026. The risk owners approve the plan and accept the residual risk the same day.

Approval (step 8, 30 September). Claire Donovan, Chief Executive, approves version 3.0, which supersedes version 2.0. Here is the 8.11 row as that approved document shows it.

Telling the certification body (step 9). The certificate still cites version 2.0. Version 3.0 brings 8.11 and two new controls into the statement, which changes the set of controls it covers, so Priya Raman sends version 3.0 to the certification body before the audit and the certification body decides whether the certificate needs re-issuing.

The audit walk (24 November 2026). The surveillance audit the risk assessment set up will start with the header: the auditor records version 3.0 and its approval in the report. Then come the rows, each read as a claim with something behind it.

The auditor will leave with one version, one approver, and every row traceable to a risk, a requirement or a fact that can be checked.

Common mistakes

Eight failure modes recur, and they share one root: a statement written from the standard toward the organisation, instead of from the organisation's risks toward the standard. Here are three rows written both ways, numbered to the mistakes below.

1. Annex A is copied in as the list of necessary controls. The statement then describes the standard instead of the organisation, and no row traces to a risk. Decide the controls from the treatment first, then compare with Annex A.
2. A control is excluded because a supplier runs it. "Not applicable: we are cloud hosted" fails the first question, because the office still has a perimeter and the provider's data centre still needs one. Mark the control applicable, record what the supplier implements and the evidence you hold for it, and manage the supplier under 5.19 to 5.23.
3. Justifications restate the control or say "required by ISO". ISO requires none of the Annex A controls by name. An inclusion names the risk IDs or the requirement; an exclusion states a fact about the scope.
4. A control is excluded for cost or because it is "not yet" built. Drata puts it plainly: "'We haven't implemented it yet' or 'it's too expensive' are not valid reasons for exclusion." Mark it applicable and not implemented, with a plan item that has an owner and a date.
5. A row says implemented with nothing behind it. Stage 2 tests whether the controls declared implemented actually are, and an implemented status the auditor cannot see is the costly one. Take the status from an assessment, and put an evidence reference on every applicable row.
6. Controls from other sources are left out. A contract or a regulator's control is necessary even if Annex A never mentions it. Add it as a row with its source, as the payroll company did with B-1 and G-1.
7. The statement is written for the certificate and never touched again. It then describes the organisation on the day of the first audit. Re-open it with every risk assessment and scope change, and version, date and approve each issue, because the certificate cites one.
8. The statement is still on 2013 numbering. Rebuild it on the 93 controls of the 2022 Annex A, use the correspondence between the two editions to carry the old justifications across, and re-check every exclusion: 24 controls were merged and 11 are new.

A statement of applicability compared with its neighbours

Most confusion about the statement disappears once you sort each document near it on two tests: whether it covers risks or controls, and whether it records a decision, a plan or the current state. The statement covers controls, and it records a decision with a status attached.

The last row is the one most often mixed up across regimes. A system security plan describes how every control is implemented for one system; a statement of applicability says which controls were chosen and why.

Standards and references

ISO sells its standards rather than publishing them, so the clause wording summarised in this guide comes from dated secondary sources and should be checked against a licensed copy before anyone quotes it word for word. The content of ISO/IEC 27006-1:2024 comes through one certification body's published procedure, which follows that standard's clause numbering.

ISO/IEC 27001:2022, with Amendment 1:2024. The third edition, published on 25 October 2022. Read clause 6.1.3 a) to f) together, then clauses 7.5.2 and 7.5.3 for approval and version control. IAF MD 26 records that the 2022 wording of 6.1.3 d) was reorganised to remove potential ambiguity, a change first made by Corrigendum 2 to the 2013 edition. Amendment 1, "Climate action changes", was published on 23 February 2024 and runs to one page. It asks organisations to determine whether climate change is a relevant issue (clause 4.1) and notes that interested parties can have climate-related requirements (clause 4.2). The IAF and ISO joint communiqué treats it as a clarification and says "a full transition programme is not needed". The amendment touches clauses 4.1 and 4.2 only, so clause 6.1.3 and Annex A are unchanged by it; where climate change produces a risk, its treatment can change a justification like any other risk.

ISO/IEC 27002:2022, Information security controls. Published on 15 February 2022, and the source of the 93 controls Annex A references: 37 organisational, 8 people, 14 physical and 34 technological. IAF MD 26 summarises the change from 2013 as 11 new controls, 24 merged and 58 updated. ISO27001security.com reports that a revision is being explored.

ISO/IEC 27005:2022. Guidance on managing information security risks, including how to produce a statement of applicability and what to say about implementation status. Quoted in this guide through Chris Hall's May 2023 summary.

ISO/IEC 27003:2017. Guidance on implementing an information security management system. Its third edition is at draft stage, with publication expected in 2027, possibly 2028.

ISO/IEC 27006-1:2024. The first edition of a new multi-part series for certification bodies, published in March 2024. It replaces ISO/IEC 27006:2015, adds provisions for remote audits and for organisations with few or no physical sites, and covers the certification documents, the stage 2 focus and the audit report in clauses 8.2.2, 9.3.2.2 and 9.4.3.

IAF MD 26:2023, Transition Requirements for ISO/IEC 27001:2022. Issued on 15 February 2023. It required certification bodies to carry out initial certifications and recertifications against the 2022 edition only from 30 April 2024 at the latest, required every transition to finish by 31 October 2025, and listed "the updating of the statement of applicability (SoA)" among the things every transition audit covers.

ISO/IEC 42001:2023. The AI management system standard asks for its own statement of applicability in its clause 6.1.3, with justification for including and excluding its controls.

Department of Employment and Workplace Relations, RFFR Statement of Applicability template. Australian employment services providers accredited under Right Fit For Risk must use it. It combines controls from contractual obligations, the Information Security Manual and ISO/IEC 27001 Annex A, is updated each quarter to align with the ISM, and the current issue is based on the June 2026 ISM.

How Alvor helps

Start with the free Statement of Applicability builder if you need the document this week. It lists all 93 Annex A controls by theme, records applicability, a justification and an implementation status for each, exports CSV and prints a clean copy, and the draft never leaves your browser.

With Alvor, an organisation keeps the statement as a view of the control record instead of a file. Installing ISO/IEC 27001:2022 from the framework library puts every Annex A control on screen with its ISO/IEC 27002 attributes as filters, so the second pass in step 4, every corrective control or every control tagged availability, is a filter instead of a re-read.

Each control records its applicability, as applicable, not applicable, inherited or out of scope, and the rationale a person writes for it. Alvor asks for a rationale before it records a control as anything other than applicable, so no exclusion goes in unexplained. Inherited is how Alvor records a control a cloud provider operates for you, the case mistake 2 is about: the row reads inherited, with the provider's part in the rationale, instead of not applicable. Each control also carries an owner and implementation notes, and links to the risks it treats from its own Risks tab.

The Statement of Applicability report lists every control in the framework with its applicability, rationale, status, owner and linked risks, filters by applicability, and exports to CSV. It is generated from the record when you open it, so the risk references this guide asks every inclusion to carry come from the links themselves.

Status comes from evidence. A control's status is set by an assessment in an audit, by automated configuration checks against AWS, Okta, Microsoft Entra ID, GitHub or GitLab bound to the control, or by a recorded override with a reason and an expiry date, and every change lands in a hash-chained audit log. Evidence is uploaded or linked once, reused by every control it satisfies, and carries a valid-until date. Inside an audit, evidence requests go to each control owner, and findings carry a severity, an assignee and a due date and can be escalated into a risk.

Any framework installed or built in Alvor gets its own statement in the same form. You can add any framework in Alvor, so a customer contract's control set, a bank's requirements or the ISM can be built in the framework builder and scoped beside ISO/IEC 27001, and ISO/IEC 42001:2023 installs from the same library. Versioning and approving each issue of the statement stay the organisation's acts, as step 8 describes; the audit log shows every change to the record behind it and who made it.

The AI Assistant runs on your own model. It can draft an assessment of a control and replacement implementation notes for a person to record, and during an audit it can propose a status change as an approval card a person accepts or rejects. The applicability decision and its rationale stay with a person.

Alvor runs as a dedicated single-tenant instance in the region you choose, on your own servers, or air-gapped. Compliance covers the module in full, and the ISO 27001 framework page covers the standard.