---
title: "How to Write a Statement of Applicability (With a Worked Example)"
canonical: "https://auditbadger.com/blog/how-to-write-a-statement-of-applicability-with-a-worked-example/"
last-updated: "2026-07-21"
---

# How to Write a Statement of Applicability (With a Worked Example)

By Maciej • Published 2026-07-22 • 5 min read • Categories: ISO, Compliance Governance, Risk Management

Created with AI assistance. AuditBadger retains editorial control and responsibility.

**TL;DR:** The Statement of Applicability is the index of your entire ISMS: one row per Annex A control, with your decision and your reasoning. Clause 6.1.3(d) requires exactly four things — the necessary controls, justification for their inclusion, whether they are implemented, and justification for excluding any Annex A control. Everything else in your SoA is optional structure. The document is produced by the risk treatment process, not the other way around: you determine the controls your risks require, then compare against Annex A's 93 controls to verify nothing necessary was overlooked. A good SoA traces every inclusion to specific risks, contracts, or legal requirements, states implementation status honestly (a "partially implemented" with a plan is more credible than 93 rows of "implemented"), and justifies exclusions by the absence of the underlying asset or risk — "no offices, physical controls inherited from our cloud provider and assessed under A.5.23" survives an audit; "not applicable because we're small" does not. Version it, date it, have it approved, and update it whenever the risk assessment moves — your certificate will reference the SoA version by name, and auditors compare its date against your risk assessment's to check the trace is alive.

Every document in your ISMS gets skimmed. The Statement of Applicability gets _read_. Certification auditors open it before stage 1, structure their audit plan around it, and your certificate will reference its version number by name. It's the index of your entire security program: one row per control, with your decision and your reasoning — which makes it a strange document to leave until the week before the audit, which is when most first-timers write it.

This post covers what ISO 27001 actually requires the SoA to contain, a column structure that holds up, and a worked example — including the part most guides dodge: what a defensible exclusion looks like.

## What clause 6.1.3 actually requires

The SoA is an output of risk treatment, not a standalone deliverable. The sequence in [clause 6.1.3](/blog/iso-27001-clause-6-planning-risk-treatment-and-the-statement-of-applicability/) matters: you choose treatment options for each risk, determine the controls those treatments need, and only then compare your control set against [Annex A](/blog/iso-27001-annex-a-controls-the-complete-2022-guide/) — in the standard's words, to verify that no necessary controls have been overlooked. Annex A is a completeness checklist, not a menu of mandates.

Clause 6.1.3(d) then requires the Statement of Applicability to contain exactly four things:

1. The **necessary controls** — those your risk treatment determined you need, wherever they come from;
2. **Justification for their inclusion** ;
3. Whether they are **implemented or not** ;
4. **Justification for excluding** any of the Annex A controls.

That's the whole legal minimum. Every other column in your SoA is optional structure — worth having only if it makes the document more useful to you and faster for the auditor.

## The columns that earn their place

| Column | Why it's there |
| --- | --- |
| Control ID and name (2022 numbering) | One row per Annex A control, plus rows for any controls from other sources (contractual, legal, sector-specific) |
| Applicable? (yes / no) | The decision itself |
| Justification | The trace: which risks, contracts, or legal requirements make this control necessary — or why it genuinely doesn't apply |
| Implementation status | Implemented / partially implemented / planned — honestly |
| How it's implemented | Pointer to the policy, procedure, or system that embodies the control |
| Owner | Who answers for it in the audit interview |
| Last reviewed | Proof the document is alive |

The justification column is where SoAs are won and lost. "Risk R-07, customer DPA §4" is a trace an auditor can follow. "Security best practice" copy-pasted down forty rows is a trace to nowhere, and it reads as exactly what it is.

## A worked example: five rows

Here's what those columns look like filled in for a fictional 25-person, fully remote SaaS company running on AWS:

| Control | Applicable? | Justification | Status | How implemented |
| --- | --- | --- | --- | --- |
| A.5.7 Threat intelligence | Yes | Risk R-08 (credential-stuffing and novel attacks against customer-facing auth) | Partially implemented | Subscribed to vendor and CERT advisories; triage process being formalized, target Q3 |
| A.5.9 Inventory of information and other associated assets | Yes | Risks R-03 (shadow SaaS), R-11 (unreturned devices); customer contractual requirement | Implemented | Asset Management Procedure v2; [register](/blog/iso-27001-asset-inventory-a-5-9-a-5-11-an-asset-register-that-survives-audits/) generated from MDM, IdP and AWS, curated quarterly |
| A.6.7 Remote working | Yes | Entire workforce is remote; risks R-05 (home network exposure), R-12 (shoulder surfing in public spaces) | Implemented | Remote Working Policy v3; MDM-enforced disk encryption and screen lock |
| A.8.28 Secure coding | Yes | Risk R-02 (vulnerabilities introduced in product code); new-in-2022 control | Implemented | [Secure Coding Standard](/blog/secure-development-controls-in-iso-27001-a-8-25-a-8-28-explained/) v1; enforced via CI checks and mandatory review |
| A.7.4 Physical security monitoring | **No** | No offices or self-managed facilities exist. All production workloads run in AWS; physical premises controls are inherited from the provider and assessed under A.5.23 and the vendor review process (provider attestation reports on file). Home-working risks are treated under A.6.7 and A.8.1. | — | — |

Look at what the exclusion does: it traces to the _absence of the underlying asset_ (no premises), names where the residual risk went (the cloud provider, assessed under a different control), and points at evidence (the provider's attestation reports). Compare the version auditors see constantly — "Not applicable, we are a small company" — which doesn't justify anything; it announces that nobody assessed it. Company size is never a justification. The absence of the asset or risk is.

Note also the honest "partially implemented." At the audit, status claims get tested against evidence — 93 rows of "implemented" followed by a stage 2 that says otherwise is a much worse position than a visible, dated plan for the gaps.

## Approval, versioning, and keeping it alive

The SoA is documented information under clause 7.5: it needs a version, a date, and an approver. Then it needs to stay synchronized with the risk assessment that justifies it. Update it when the risk assessment changes — which [clause 8.2](/blog/iso-27001-clause-8-operation-where-your-controls-actually-run/) requires at planned intervals and at significant changes — and when new systems, vendors, or incidents shift what "necessary" means.

Two facts worth knowing before your first audit. Your certificate will typically cite the SoA version and date it covers — this is a named, versioned artifact, not an internal working file. And auditors routinely compare the SoA's date against the risk assessment's: an SoA older than the current risk assessment means the trace between them is broken, and that's a finding about the system, not the paperwork.

## The findings auditors keep raising

- **No trace to the risk assessment.** Justifications that never reference a risk, so the SoA floats free of the process that's supposed to produce it.
- **Lazy exclusions.** Missing justifications, or boilerplate ("not relevant to our business") that shows the control was never actually considered.
- **Status inflation.** Everything marked implemented; evidence at stage 2 disagrees.
- **Identical justifications.** The same sentence on forty rows — a sure sign the column was filled, not thought.
- **The frozen SoA.** Version 1.0, dated the month of certification, unchanged through two surveillance audits while the company shipped a new product line.

The pattern behind all five is the same: the SoA is supposed to be the visible surface of a working risk process, and auditors read it precisely to check that the process underneath exists. Write it as the output of your [Clause 6 machinery](/blog/iso-27001-clause-6-planning-risk-treatment-and-the-statement-of-applicability/) and it stays defensible by construction. Write it as a standalone spreadsheet the week before the audit, and it becomes the document most likely to unravel the whole [management system](/blog/iso-27001-clauses-4-10-the-requirements-behind-the-controls/) in front of the one reader guaranteed to notice.


## Frequently asked questions

### What must an ISO 27001 Statement of Applicability contain?

Clause 6.1.3(d) requires exactly four things: the necessary controls (determined by your risk treatment, from Annex A or any other source), justification for their inclusion, whether each is implemented or not, and justification for excluding any Annex A control. Everything else — owners, evidence pointers, review dates — is optional structure that makes the document more useful but isn't formally required.

### Can you exclude Annex A controls from the Statement of Applicability?

Yes — Annex A is a completeness checklist, not a list of mandates, and exclusions are legitimate when justified. A defensible justification traces to the absence of the underlying asset or risk: a fully remote company with no premises can exclude physical security monitoring (A.7.4) by showing provider-inherited physical controls assessed under A.5.23. Company size or effort is never a valid justification — "not applicable because we're small" reads as "we didn't assess it," and auditors treat it accordingly.

### Does the Statement of Applicability need to list all 93 Annex A controls?

Effectively yes. Because 6.1.3 requires you to justify the exclusion of any Annex A control, the only practical way to demonstrate every control was considered is one row per control with an explicit applicable/not-applicable decision. The SoA should also include necessary controls that don't come from Annex A — for example, ones driven by contracts, laws, or sector requirements.

### How often should the Statement of Applicability be updated?

Whenever the risk assessment it's built on changes — which Clause 8.2 requires at planned intervals and at significant changes — and when new systems, vendors, or incidents shift which controls are necessary. Auditors compare the SoA's date against the risk assessment's date to check the trace between them is alive. Note that your certificate typically references the SoA version and date it covers, so it's a formally versioned, approved document, not an internal working file.

### What is the difference between the Statement of Applicability and the risk treatment plan?

The SoA is the index: which controls are applicable, why, and their implementation status — one row per control. The risk treatment plan is the execution document: how each treatment will be implemented, by whom, and by when, and it must be approved by the risk owners, who also formally accept the residual risk. They're linked outputs of the same Clause 6.1.3 process, but auditors expect them as distinct artifacts.