How to Write an ISO 27001 Statement of Applicability

The Statement of Applicability is the single document an ISO 27001 auditor reads most closely, and it’s also the one most first-time applicants get wrong in the same way: they either include every Annex A control to be safe, or they exclude controls without writing down why. Clause 6.1.3(d) of ISO/IEC 27001 requires the SoA to exist as a specific, standalone artifact, and clause 6.1.3(d) footnote requires a justification for every inclusion and every exclusion, not just the ones that seem debatable. Getting the structure right the first time saves a round of auditor findings that otherwise turn into a corrective action before certification closes.

What the SoA Actually Is

The Statement of Applicability is not the risk assessment, and it’s not the risk treatment plan, though it depends on both. The risk assessment identifies threats and vulnerabilities against your information assets. The risk treatment plan decides how each significant risk gets addressed, control implementation being one option alongside risk acceptance, avoidance, or transfer. The SoA is the document that then maps every one of Annex A’s controls to a decision: included or excluded, and why, with a reference back to the risk treatment plan for anything you’ve included specifically to treat an identified risk.

Auditors read the SoA as a table of contents for your entire ISMS, because it tells them which of the 93 Annex A controls in ISO/IEC 27001:2022 are supposed to be operating, which lets them plan exactly what evidence to sample during the audit. A control marked “included” that has no corresponding policy, procedure, or log when the auditor asks for it is a nonconformity. A control marked “excluded” with a thin justification like “not applicable” is very often a nonconformity too, since “not applicable” on its own doesn’t explain the reasoning an auditor is required to test.

The 2022 Annex A Structure

If you certified under ISO/IEC 27001:2013, the control list changed meaningfully in the 2022 revision, and it’s worth knowing the shape of the new structure before drafting, since it changes how you organize the SoA itself.

The 2022 revision consolidated overlapping 2013 controls and added eleven new ones that didn’t exist in the old list, threat intelligence and cloud security among them, reflecting how much the threat landscape and typical technology stack had shifted in the nine years between revisions. If your organization is certifying for the first time, you’re working from the 2022 structure by default. If you’re transitioning an existing 2013 certificate, your certification body will have given you a transition deadline, and the SoA is one of the documents that has to be rebuilt against the new theme structure rather than mapped control-by-control, since several 2013 controls were merged into a single 2022 control.

Selecting Controls: The Applicability Decision

Annex A is not a checklist to work through top to bottom filling in yes or no. The starting point is always the risk assessment: a control becomes a candidate for inclusion because it addresses a risk your organization actually identified, a legal or regulatory requirement you’re subject to, or a contractual obligation a customer or partner has placed on you. Working from the control list first, deciding what sounds reasonable to include, and reverse-engineering a risk to justify it is the pattern that produces a weak SoA and a weak ISMS behind it, because the control selection stops being driven by your actual risk profile.

In practice, most organizations end up including the large majority of the 93 controls, because most controls apply broadly across any organization handling information assets. Genuine exclusions tend to cluster around a small number of predictable categories: controls tied to a technology you don’t use (for example, a physical control for controlling entry to a data center, when your infrastructure runs entirely on a cloud provider whose physical security is out of scope for your own ISMS), controls made redundant by another control you’ve already implemented more broadly, and controls tied to a business function you don’t perform (secure development lifecycle controls, if you don’t develop software in-house). Excluding a control because it looks like extra work is not a valid justification and is the fastest way to generate an audit finding.

Writing Justifications That Hold Up

The justification column is where most first drafts fail, not the inclusion/exclusion decision itself. A justification needs to name the specific reason, not restate the control’s own title back at the auditor.

The same discipline applies to exclusions. “Not applicable, we’re a small company” is not a justification an auditor accepts, because company size alone rarely makes a control genuinely inapplicable, it might justify a lighter implementation, but that’s a different claim than exclusion. A defensible exclusion justification names the specific condition that removes the control from scope: “Excluded. The organization does not operate physical server rooms; all infrastructure is hosted with [cloud provider], whose physical security controls are covered under the vendor’s own ISO 27001 certification, referenced in the supplier due diligence record SDD-014.” That sentence gives an auditor something concrete to verify, the vendor’s certificate, rather than an opinion to accept on faith.

Each justification should also state the control’s implementation status if it’s included: implemented, partially implemented with a target date, or planned. A newly certifying organization is allowed to have controls in a partially implemented state at the time of the initial audit as long as the SoA is honest about it and the risk treatment plan shows a realistic path to full implementation; what an auditor will not accept is an SoA that claims full implementation for a control that turns out, when sampled, to not actually exist in practice.

What Auditors Actually Check

During Stage 1 and Stage 2 audits, the SoA gets used as a sampling guide, not read in isolation. The auditor picks a subset of included controls, typically weighted toward the ones tied to your highest-rated risks, and asks to see the evidence: the policy document, the access log, the training record, the vendor contract clause, whatever the control implies exists. They’ll also spot-check a few exclusions, particularly ones that look convenient rather than clearly justified by your actual operating model, since exclusions are where organizations are most tempted to trim scope to reduce audit burden.

Version control matters here too. The SoA is a living document that changes as your risk assessment, technology, and business change, and most certification bodies expect to see a version history: who approved each revision, and when. An SoA that hasn’t been touched since the initial certification audit, sitting through two annual surveillance visits with the exact same content, is itself a signal to an experienced auditor that the ISMS review process required by clause 9.3 (management review) isn’t actually running, since a genuine annual review of the ISMS would be expected to surface at least minor changes to scope, risk, or control status somewhere along the way.

Putting It Together

A complete Statement of Applicability names the organization, states its ISMS scope, lists all 93 Annex A controls organized by the four 2022 themes, organisational, people, physical, and technological, and for each one records the applicability decision, a specific justification tied to the risk assessment or an operational fact, and an implementation status. It closes with an approval signature and date, since the SoA is a governance document the organization’s management is expected to formally sign off on, not just a spreadsheet an auditor happens to be shown.

Our ISO 27001 Statement of Applicability generator builds this structure directly: it walks through the full Annex A control list organized by theme, captures an included/excluded decision and justification for each one, and assembles the document with your organization details, certification body, and scope already in place, so the SoA you take into a Stage 1 audit is complete against the current control set rather than assembled by hand from a spreadsheet template that may still reflect the 2013 structure. If your ISMS also involves data processed on behalf of customers, see how to write a DPA for the contractual side of that relationship, since several Annex A supplier and third-party controls are typically evidenced by the DPA and vendor agreements you already have in place. And since Annex A control 5.24 through 5.28 covers incident management specifically, how to write an incident response plan is the companion document most of that section of the SoA points back to as its evidence.