How to Write Your ISO 27001 Statement of Applicability (SoA)

The Statement of Applicability is the central ISMS document an ISO 27001 auditor reaches for first. It records every one of the 93 Annex A:2022 controls, whether each applies, why, and where it stands — and it follows directly from your risk assessment and treatment plan under clause 6.1.3.

What the Statement of Applicability actually is

The Statement of Applicability (SoA) is a single document that lists every control in Annex A of ISO/IEC 27001:2022 and states, for each one, whether it applies to your organization, the justification for including or excluding it, and — in practice — its implementation status. It is not an optional artifact. Clause 6.1.3 d) of the standard names the SoA explicitly as documented information you must produce and maintain, which makes it one of a small number of documents ISO 27001 requires by name. If your information security management system (ISMS) were a map, the SoA would be the legend: it ties your assessed risks to the specific controls you have decided to operate.

Annex A:2022 contains 93 controls grouped into four themes — Organizational (A.5, 37 controls), People (A.6, 8 controls), Physical (A.7, 14 controls), and Technological (A.8, 34 controls). The SoA walks through all 93. That completeness is the point: an auditor opening your SoA should be able to see, control by control, that you considered the entire reference set and made a deliberate decision about each, rather than cherry-picking the ones you found convenient.

It helps to be clear about what the SoA is not. It is not your risk assessment, and it is not your risk treatment plan — those are separate, upstream documents under clauses 6.1.2 and 6.1.3. The SoA is the consolidated statement that results from them. It is also not a place to record only the controls you implemented; it must account for every Annex A control, including those you legitimately exclude, with a defensible reason for each exclusion.

Why the SoA follows from risk assessment and treatment

The SoA does not stand on its own — it is the output of a chain. ISO/IEC 27001:2022 clause 6.1.2 requires you to assess your information security risks; clause 6.1.3 requires you to treat them. Treatment means choosing, for each risk you decided to act on, how you will modify, avoid, share, or retain it, and then determining the controls necessary to carry out those decisions. Only after you have determined the controls your treatment requires do you compare that set against Annex A. The standard uses Annex A as a completeness check — a reference list to confirm you have not overlooked a necessary control — not as a menu you shop from in isolation.

This ordering matters because it shapes how you justify each line of the SoA. A control is "applicable" because your risk assessment and treatment decisions call for it, or because a legal, regulatory, or contractual obligation requires it — not simply because it appears in the standard. A control is "excluded" when no risk you identified and no obligation you carry depends on it, and you can say why. A classic defensible exclusion is in the Technological theme: an organization that performs no software development can reasonably exclude the secure-development controls (around A.8.25 to A.8.30), provided that is genuinely true and stays true.

Get the direction of travel right and the SoA writes itself as a summary of work you have already done. Get it backwards — picking controls off Annex A first and reverse-engineering risks to fit — and an experienced auditor will usually notice. Clause 6.1.3 also requires risk owners to approve the treatment plan and accept the residual risks that remain; that sign-off is what authorizes the program the SoA describes.

Building the SoA, step by step

Start with a workbook that already lists all 93 Annex A:2022 controls, each tagged with its theme, so you are reviewing a complete set rather than transcribing the standard by hand. For every control, you will resolve a small number of fields: the control ID and title, its theme, whether it is applicable (Yes/No), the justification for inclusion or exclusion, the implementation status, and a reference to the documents or evidence that demonstrate it. Those columns are the working spine of a usable SoA.

Work through the controls in order. For each, decide applicability against your risk assessment, treatment plan, and obligations, then write a justification specific to your organization — "required to mitigate the access-control risks identified in our risk register" is defensible; a generic restatement of the control title is not. Most organizations find that nearly all 93 controls apply to them; broad exclusions are a red flag unless the reason is concrete and verifiable. Set the implementation status honestly: auditors expect a mix, and a status of "Planned" backed by a dated implementation plan is acceptable at a Stage 1 audit, where the assessor is largely checking documentation and readiness.

Then connect each applicable control to proof. In the evidence column, reference the relevant policy or procedure and, where it exists, the record that shows the control actually operates — a log, an access review, a ticket, a signed acknowledgment. This is where the SoA stops being a list of intentions and becomes a navigable index into your ISMS. Finally, version and date it. Auditors ask for SoA history, and the standard treats it as documented information you control, so update it after every risk assessment cycle and whenever a significant change alters which controls you need.

Common mistakes that cost you at audit

The most frequent failure is excluding controls to reduce the workload rather than because they genuinely do not apply. Each exclusion needs a justification that would survive a follow-up question. Excluding the physical-security controls because you are fully remote can be reasonable — but only if you truly hold no physical assets and process nothing on premises, and you should expect to be asked. Excluding a control simply because implementing it is inconvenient is not a justification; it is a finding waiting to happen.

A second common mistake is leaving the placeholder justifications that come with any template. Generic wording such as "applies to company systems" tells an auditor you populated a spreadsheet but did not connect it to your environment. The justification should trace back to a specific risk in your register or a specific obligation you carry. A related error is an SoA that disagrees with the rest of the ISMS — controls marked applicable with no supporting policy, or policies that describe controls the SoA omits. Internal consistency is exactly what an auditor samples for.

Third, treating the SoA as a one-time deliverable. It is living documented information. When you adopt a new system, take on a major supplier, change what you process, or respond to a serious incident, your control needs can shift — and an SoA that still reflects last year's environment undermines the credibility of the whole management system. Finally, conflating editions: an SoA built on the 2013 structure (114 controls across 14 domains, A.5 to A.18) is out of date. Certification audits are conducted against ISO/IEC 27001:2022, so your SoA must reflect the 93-control, four-theme Annex A. Confirm specifics against the official 2022 text rather than older summaries.

How auditors read your SoA

For a certification body, the SoA is often the first document opened and the spine of the rest of the audit. It tells the auditor what you claim to be doing, and it becomes the worklist they sample against. They will look for completeness — that all 93 controls are accounted for — and then probe the seams: an exclusion with a thin justification, an "implemented" status with no evidence behind it, or an applicable control whose referenced policy does not actually exist.

A typical line of questioning starts at the SoA and moves outward. The auditor picks a control marked applicable and implemented, follows your evidence reference to the policy, and then asks to see the records that prove the control operates in practice — the access review that was actually performed, the log that was actually kept, the supplier assessment that was actually completed. The SoA is the index; the audit is the auditor checking that the index points to something real. This is why the evidence column is not busywork: it is the path the auditor will walk.

The relationship runs the other way too. Because the SoA is required by clause 6.1.3 d) and is referenced throughout the audit, an SoA that is accurate, specific, internally consistent, and current does a great deal to set a confident tone for the whole assessment. A vague or stale one signals that the management system may be more paper than practice — and invites deeper sampling.

Using a toolkit to get a usable starting point

Building an SoA from a blank page is slow and error-prone: you have to transcribe all 93 Annex A:2022 controls, assign each to the right theme, and lay out columns for applicability, justification, implementation status, and evidence before you can do any of the actual thinking. That setup work adds nothing unique to your organization, which is exactly the kind of task a documentation toolkit is meant to remove.

The ComplianceDocs ISO 27001 toolkits include a 93-control Statement of Applicability workbook pre-populated with every Annex A:2022 control, its theme, and starter justification wording, alongside a matching risk register and an audit evidence checklist — and the policies the SoA's evidence column points back to. That gives you an editable starting point: a complete, correctly structured SoA you adapt to your environment, rather than a structure you build from scratch. It is the documentation layer, designed to speed readiness.

What the toolkit cannot do is the judgment that makes the SoA valid. The applicability decisions, the organization-specific justifications, the honest implementation statuses, and the evidence that proves each control operates all have to reflect your actual ISMS — and only your organization can supply them. Just as important, no template, workbook, or document set makes an organization "ISO 27001 certified." Certification is issued only by an accredited certification body after it audits a working management system. A toolkit accelerates and structures the documentation; the certification, and the operating controls behind it, remain yours to earn. (Any cost or time references here are illustrative estimates, not quotes; actual figures vary by organization, scope, and certification body.)

Frequently asked questions

Is the Statement of Applicability mandatory for ISO 27001?

Yes. ISO/IEC 27001:2022 clause 6.1.3 d) names the Statement of Applicability explicitly as documented information you must produce and maintain, making it one of the few documents the standard requires by name. It must account for every one of the 93 Annex A controls, stating for each whether it applies and the justification for inclusion or exclusion. An auditor will expect to see it, and it is typically one of the first documents reviewed in a certification audit. There is no version of an ISO 27001 ISMS that legitimately omits the SoA.

How many controls are in the SoA under ISO 27001:2022?

The 2022 edition of Annex A contains 93 controls across four themes: Organizational (A.5, 37 controls), People (A.6, 8 controls), Physical (A.7, 14 controls), and Technological (A.8, 34 controls). Your SoA must address all 93, including the ones you exclude. This differs from the 2013 edition, which had 114 controls organized into 14 domains numbered A.5 to A.18. Because certification audits are conducted against ISO/IEC 27001:2022, an SoA built on the older 114-control structure is out of date.

What is the difference between the risk treatment plan and the SoA?

They are separate documents with different jobs, both arising from clause 6.1.3. The risk treatment plan decides what to do about each risk you chose to treat — modify, avoid, share, or retain it — and determines the controls those decisions require. The Statement of Applicability is the consolidated statement that results: it lists all 93 Annex A controls and records, for each, whether it applies, why, and its implementation status. In short, the treatment plan is where you make decisions; the SoA is where you account for those decisions against the full reference set of controls.

Can I exclude controls from my Statement of Applicability?

Yes, but every exclusion needs a defensible, specific justification, and an auditor may question it. A control is reasonably excluded when no risk you identified and no legal, regulatory, or contractual obligation requires it. A common example is excluding the secure-development controls (around A.8.25 to A.8.30) when your organization performs no software development — valid only if that is genuinely and durably true. Excluding a control because implementing it is inconvenient is not a justification, and broad exclusions across a whole theme tend to draw scrutiny.

Does a pre-built SoA workbook make my organization ISO 27001 certified?

No. A workbook gives you all 93 Annex A:2022 controls, correct themes, and a structure for applicability, justification, status, and evidence so you are not building from a blank page — but the applicability decisions, organization-specific justifications, honest statuses, and supporting evidence must reflect your real environment. ISO 27001 certification is issued only by an accredited certification body after it audits a working information security management system. A document set, on its own, cannot confer certification. A toolkit speeds and structures the documentation; the certification and the operating controls behind it remain yours to earn.

Related guides: ISO/IEC 27001

Toolkits that help

← All articles