The ISO 27001 Statement of Applicability, Explained With an Example

Direct answer: The Statement of Applicability, usually shortened to SoA, lists all 93 Annex A controls of ISO 27001:2022 and records for each one whether it applies to you, why, and whether it is currently implemented. It is mandatory, it is the document a Stage 1 auditor reads first, and it is where most first-time certifications come unstuck.

What it has to contain

For every one of the 93 controls: whether it is applicable, the justification for that decision, whether it is implemented, and a reference to how. The justification is the part that carries the weight. "Applicable, we process customer personal data" is a justification. "Yes" is not.

The SoA also has to line up with your risk assessment. If your risk treatment plan says you are mitigating a risk with a control, and the SoA marks that control as not applicable, the auditor has found a contradiction between two mandatory documents on their first read.

An example row

For control A.8.7, protection against malware: Applicable. Justification: corporate endpoints and production servers process customer data and are exposed to email and internet traffic. Implemented: yes. Reference: Endpoint Security Policy section 4, managed EDR deployed to all endpoints, monthly coverage report.

That single row tells an auditor what you decided, why, and where to go looking for evidence. Ninety-three rows of that standard is a SoA that survives Stage 1.

Excluding a control properly

You are allowed to exclude controls. You are not allowed to exclude them because they are inconvenient. A legitimate exclusion is a control that genuinely does not apply to your scope, and the justification has to hold up: A.7.4, physical security monitoring, can reasonably be excluded by a fully remote company with no offices and cloud-hosted infrastructure, and that justification should say exactly that.

What fails is excluding development security controls because you outsource development, or excluding supplier controls because you only use large vendors. Both are still your risk.

The mistakes that cost a Stage 1

Copying a SoA from a template and leaving justifications that describe somebody else's company. Marking controls implemented when the policy exists but nothing operates. Letting the SoA drift out of date after the risk assessment changes. Treating it as a spreadsheet to fill in at the end rather than the output of the risk work.

Built properly it is the most useful document in the whole management system, because it is the single place that connects your risks, your controls and your evidence. Built badly it is the fastest way to fail a Stage 1.

The SoA is a core deliverable of our ISO 27001 Readiness engagement, and the free ISO 27001 gap assessment will show you where you stand against the 93 controls before you commit to anything.

The chain the SoA sits in

The reason the SoA carries so much weight at audit is that it is the join between two other mandatory outputs. Your risk assessment produces a list of risks with owners and ratings. Your risk treatment plan says what you are doing about each one, and where the treatment is "mitigate", it names the controls doing the mitigating. The SoA then declares, control by control, whether that control is in play and whether it is running. An auditor can walk that chain in either direction, and a competent one will.

Walking it forwards: pick a high-rated risk, read the treatment, find the named controls, check those controls are marked applicable and implemented in the SoA, then ask for the evidence the SoA points at. Walking it backwards: pick a control marked not applicable, then search the risk register for any risk whose treatment depends on it. If they find one, the finding writes itself, and it is usually a major nonconformity rather than an observation because two mandatory documents contradict each other.

Build the SoA last, from the risk work, and this chain holds by construction. Build it first, from a template, and you spend the week before Stage 1 reverse-engineering a risk assessment to match a spreadsheet you already filled in. That reverse-engineering is visible in the dates on the documents, and auditors look at dates.

Four columns the standard does not ask for

The standard tells you what the SoA must contain, not what shape it takes. In practice a workable SoA has eight columns: control reference, control title, applicable yes or no, justification for that decision, implementation status, implementation reference, control owner, and last review date. The four beyond the mandatory minimum are what turn it from an audit artifact into something your team can actually run the ISMS from.

Control owner matters because ISO 27001 auditors interview people, not documents. If A.8.16 monitoring activities is marked implemented and nobody in the room can say who reviews the alerts, the control is not implemented, whatever the SoA says. Naming an owner per control forces that conversation months before the auditor has it.

Last review date matters because the SoA is a living document with a review obligation attached. A SoA where all 93 rows carry the same date, and that date is eleven months old, tells the auditor the document was written once and filed. A SoA with rows reviewed at different times, tracking actual changes in the environment, tells them the management system is real.

Implementation reference should point at something specific enough to fetch. "Access Control Policy" is weak. "Access Control Policy v3.2 section 6, quarterly access review export in the evidence register, Okta group membership report" is what an auditor can sample without a follow-up email.

Rows that are harder than A.8.7

Malware protection is an easy row because the answer is binary and the evidence is obvious. The rows that generate discussion are the ones added or reshaped in the 2022 revision, where reasonable companies genuinely disagree about what counts.

A.5.7, threat intelligence. Most small companies mark this applicable and then struggle to evidence it, because they are not buying a feed. The defensible position is usually that threat intelligence is consumed rather than produced: vendor advisories, CVE monitoring for your stack, your cloud provider's security bulletins, and a documented route from those into your patching decisions. Write that as the justification and the implementation reference points at the actual review record, not at a subscription you do not have.

A.5.23, information security for use of cloud services. Companies mark this implemented on the strength of using a reputable provider. That is not the control. The control is about how you select, configure, manage and exit cloud services. The evidence an auditor expects is a documented selection process, the shared responsibility position for each significant service, and an exit consideration. If you have never written down what happens to your data if you leave your main provider, this row is not implemented yet.

A.8.11, data masking. The honest answer for a lot of engineering teams is that production data appears in staging. If that is true, do not mark this implemented. Mark it applicable, not yet implemented, with a target date and a named owner. A partially implemented SoA with dates is a management system in motion. A fully implemented SoA that is untrue is a fraud finding waiting to happen when the auditor asks an engineer where the staging data comes from.

Writing a shared responsibility justification

The most common bad exclusion is some version of "not applicable, our provider handles it". Physical controls in a cloud-hosted environment are the usual case, and the instinct is right while the wording is wrong. You have not eliminated the risk, you have transferred the operation of the control to a third party while keeping the accountability.

The wording that survives is applicable, implemented by a supplier, with the assurance named. For example: applicable, all production infrastructure is hosted in a provider data centre, physical entry controls are operated by the provider and assured through their current SOC 2 Type II report reviewed on 14 March, review record held in the supplier assessment register. That row tells the auditor you understood the boundary, you checked, and you can produce the check.

Where this bites is when the assurance does not exist. Plenty of companies claim provider assurance and have never downloaded the report, never read the complementary user entity controls section, and are therefore unaware that the provider explicitly assigns several controls back to them. Those user entity controls are the ones you are responsible for, and an auditor who reads your provider's report will know what they are.

What Stage 1 actually looks like on this document

Stage 1 is a documentation review, and the SoA is the map the auditor uses to navigate everything else. Expect them to spend real time on it, then trace a small number of rows to ground. The pattern is usually four or five samples: one control everybody implements, one control excluded, one control from the 2022 additions, one control tied to your highest-rated risk, and one control the auditor picked because your justification was oddly worded.

The questions are predictable. Who decided this control was not applicable, and when? Show me where this decision is recorded outside the spreadsheet. Your risk register has a risk about supplier access, which controls treat it, and are they all marked applicable? This row says implemented, when did it last operate? Who signed the SoA, and does that person have the authority to?

That last one catches people. The SoA is a management-approved document. If it has no approver, no version, and no date, it is a draft, and a draft is not evidence of a functioning management system. Version it, approve it at a management review, and keep the previous versions.

Keeping it current after certification

Certification is a three-year cycle with surveillance audits in years one and two, and the SoA is reviewed at every one of them. The failure mode after the initial certification is drift: you deploy a new product, adopt a new cloud service, hire your first office-based staff, and the SoA still describes the company you were eighteen months ago.

Set explicit triggers rather than relying on an annual review. A new supplier with access to customer data, a change of hosting region, a first office lease, an acquisition, a new class of data, or any change to the ISMS scope should each require the SoA to be re-read. Most of the time nothing changes and you record that it was checked. Occasionally a single change makes three excluded controls applicable, and catching that in the week it happened is far cheaper than explaining it to a surveillance auditor.

When you should not pay anyone for this

If you are a company of under thirty people with a single product, one cloud provider, no office and no regulated data, the SoA is a document you can write yourself over about two working weeks, and you will end up with a better one than a consultant produces at arm's length. The justifications have to describe your company, and you know your company. Buying that work means paying somebody to interview you and then write down what you said.

The free traztech Workspace carries the control set and the evidence register with no card and no paid tier, which covers the mechanics. What it will not do is make the judgement calls, so if you go this route, budget a few hours of somebody experienced reading your finished SoA before Stage 1 rather than a full engagement. That is the cheapest useful intervention available.

Where outside help genuinely earns its fee is scope disputes, a first certification running against a contractual deadline, an environment complicated by acquisitions or on-premise legacy systems, or a company that has already failed a Stage 1 and needs to understand why. If your situation is none of those, run it yourself and spend the money on the audit firm instead. Our ISO 27001 work and the retainer options on /engage are there when the judgement calls are the expensive part, not before.