Statement of Applicability

The Statement of Applicability (SoA) is one of the most important documents in your ISMS. It lists all 93 Annex A controls from ISO/IEC 27001:2022, states whether each is applicable, justifies every inclusion and exclusion, and describes how applicable controls are implemented. Auditors review the SoA closely — it is the bridge between your risk assessment and your control implementation, and it is one of the first documents a certification body requests at Stage 1.

The SoA is not optional paperwork. Clause 6.1.3(d) of the standard explicitly requires you to "produce a Statement of Applicability" containing the necessary controls, justification for inclusions, whether they are implemented, and justification for exclusions. It is also the document your certificate references in spirit: what you certified is your ISMS as described by its scope and SoA. Get it wrong and everything downstream — audits, evidence, even the credibility of your certificate — wobbles.

What the SoA Actually Does

Think of the SoA as the keystone joining three layers of your ISMS:

1. Above it: the risk assessment. Every applicable control should trace to one or more risks it treats, or to a legal, regulatory, or contractual obligation.
2. Within it: the applicability decisions. For each of the 93 controls — applicable or excluded, and why.
3. Below it: implementation reality. For applicable controls — status, how it is implemented, and where the evidence lives.

Auditors walk this chain in both directions. They pick a risk from your register and ask which controls treat it, expecting to land in the SoA. Then they pick an SoA line and ask to see the implementation. Any break in the chain — a risk with no treating control, an applicable control with no owner or evidence, an exclusion contradicted by your own risk register — is a finding.

What Each SoA Entry Must Contain

For each of the 93 Annex A controls, document at minimum:

• Control reference and name (e.g., 8.13 Information backup)
• Applicability — yes or no
• Justification for inclusion — the risk(s), obligation(s), or business requirement driving it
• Justification for exclusion — the factual reason the control is unnecessary
• Implementation status — implemented, partially implemented, or planned (with a target date)
• How it is implemented — the specific mechanism: tool, process, policy section

Strongly recommended additions that make audits dramatically smoother:

• Control owner — a named person
• Risk reference(s) — IDs from your risk register
• Evidence pointer — where proof lives (platform check, document, system)
• Related documents — the policy or procedure that governs the control

A Practical Column Layout

Most organizations build the SoA as a spreadsheet or maintain it inside their compliance automation platform, which can pre-populate the 93 controls and link them to monitored evidence. There is no mandated format — clarity, completeness, and traceability are what auditors grade.

Writing Justifications That Survive Audit

The difference between a strong SoA and a weak one is almost entirely in the justification and implementation columns.

Weak inclusion justification: "Best practice." "Required by ISO 27001." — The first is empty; the second is factually wrong (Annex A controls are not automatically required) and tells the auditor you skipped the risk linkage.

Strong inclusion justification: "Treats R-031 (data loss from laptop theft); supports GDPR Art. 32 obligations; customer contract clause 7.2 requires disk encryption."

Weak exclusion justification: "Not applicable." "We are a cloud company." — Both invite the follow-up question you cannot answer.

Strong exclusion justification: "8.30 Outsourced development — excluded: all software development is performed by direct employees; no development is outsourced. Will be reassessed if contractor developers are engaged."

Note the pattern: strong exclusions state a verifiable fact about your operations, not a preference or an assumption. Also note the trap in physical controls: "we have no data center" does not exclude data-center-style controls if you inherit them from AWS or GCP — the defensible framing is applicable, implemented via cloud provider, verified through their SOC 2 / ISO 27001 assurance reports, as covered in the Annex A lesson.

Realistic exclusion counts are small. A typical SaaS company excludes perhaps zero to eight controls — commonly some of 8.30 (no outsourced development), 7.13/7.11 fragments in fully serviced offices, or development controls at companies that build no software. An SoA excluding 20 or more controls signals a scoping or reasoning problem and will be probed hard.

Common Mistakes

Excluding controls without justification. Every exclusion must rest on your risk assessment or a verifiable operational fact. Saying a control is "not applicable" without explaining why is an audit finding waiting to happen — usually caught at Stage 1, before you have even reached the real audit.

Copy-pasting generic descriptions. Auditors want to see how you specifically implement each control, not boilerplate. "Access is restricted per policy" appearing 40 times is a red flag; reference your actual tools, settings, and document sections.

Misaligning with the risk assessment. If your risk register identifies phishing as a top risk but the SoA gives 6.3 (awareness training) a thin justification, or a risk's stated treatment references a control marked excluded, auditors will flag the inconsistency immediately. Traceability is the single quality they test most.

Treating it as a one-time document. The SoA is a living document with a required review rhythm. New vendors, new products, a new office, an incident, a reorganization — each can change applicability or implementation descriptions.

Letting "planned" linger. "Planned" status is acceptable pre-certification with a dated treatment plan. An SoA still showing planned controls with expired target dates at a surveillance audit is a nonconformity in the making.

Version chaos. Auditors ask for the current, approved SoA with version, date, and approver. Three conflicting spreadsheets on a shared drive is itself evidence of a documented-information control failure (clause 7.5).

Building Your SoA: Step by Step

1. Complete the risk assessment and risk treatment plan first — the SoA is an output of clause 6.1.3, not a starting template.
2. List all 93 controls (from the standard or your compliance platform).
3. For each control, ask: does a risk, law, regulation, or contract make this necessary? Record the linkage.
4. Mark genuine exclusions with factual justifications.
5. Record implementation status honestly — partial and planned are fine before certification if dated.
6. Write specific implementation descriptions naming tools, processes, and documents.
7. Assign owners and evidence pointers.
8. Have the SoA formally reviewed and approved (typically by the ISMS owner or management review), with version and date.
9. Cross-check: every risk treatment references SoA controls; every applicable control traces back to something.

SoA Quality Checklist

Run this before Stage 1:

• All 93 ISO 27001:2022 controls listed — none missing, no 2013-era numbering
• Every control marked applicable or excluded, no blanks
• Every inclusion justified by risk IDs, legal/contractual obligations, or explicit business requirements
• Every exclusion justified by a verifiable operational fact
• Implementation status current, with dated plans for anything not fully implemented
• Implementation descriptions specific — tools, configurations, document references, no repeated boilerplate
• Named owner for every applicable control
• Evidence location identified for every applicable control
• Full traceability: risk register ↔ risk treatment plan ↔ SoA agree with each other
• Cloud-inherited controls framed as supplier-implemented with assurance reports on file
• Document control applied: version number, date, author, approver, changelog
• Reviewed within the last 12 months or since the last significant change

Maintenance Across the Certification Cycle

Review the SoA at least annually and whenever significant change occurs — new systems or vendors, scope changes, incidents revealing new risks, reorganizations, or updates to the standard itself. Practical triggers to wire into your process: the annual risk assessment refresh, management review meetings, major architecture changes, and post-incident reviews.

Each revision should update the version number and changelog. At surveillance audits (annually) and recertification (year three), auditors compare the current SoA against the one they last saw and ask what changed and why — a clean changelog turns that conversation into five minutes.

Frequently Asked Questions

Is the SoA shared with customers?

Sometimes, under NDA. The certificate itself is public, but savvy enterprise buyers request the SoA (or at least the scope statement) to see what the certificate actually covers and whether any surprising exclusions exist. Write the SoA assuming a sophisticated customer may one day read it.

How is the SoA different from the risk treatment plan?

The risk treatment plan is organized by risk: for each risk, the chosen treatment, controls, owners, and timelines. The SoA is organized by control: for each of the 93, applicability, justification, and status. They describe the same reality from two directions and must reconcile — auditors check exactly that.

Can our compliance automation platform generate the SoA?

It can scaffold it: pre-list the 93 controls, attach implementation status from monitored checks, and link evidence. What it cannot generate is the justification column — the risk linkage and exclusion reasoning are your judgment, and auto-generated boilerplate there is one of the fastest ways to earn an auditor's distrust. Use the platform for structure and status; write the reasoning yourself.

What happens if the auditor disagrees with an exclusion?

At Stage 1 it is usually raised as an area of concern to fix before Stage 2. At Stage 2 an indefensible exclusion becomes a nonconformity — minor if isolated, major if it exposes a broken risk process. The fix is to mark the control applicable, implement it (or plan it with dates), and correct the risk assessment linkage.

Do we need a new SoA for the 2022 version if we certified under 2013?

The transition deadline was October 2025, so this is now behind everyone: all current certificates require the 2022 SoA with the 93-control structure. If you are working from an old 114-control SoA found in company archives, rebuild against the 2022 catalogue rather than patching — the merges and 11 new controls make line-by-line conversion error-prone.

Who should own and approve the SoA?

The ISMS owner (compliance lead, CISO, or equivalent) typically maintains it; approval should come from management — commonly recorded in management review minutes. What auditors want is evidence that leadership has seen and endorsed the applicability decisions, since those decisions define the organization's accepted security posture.

In the next lesson, we will cover the internal audit process.

A well-instrumented platform keeps SoA status and evidence in sync automatically. AuditXYZ helps you compare compliance automation platforms and find ISO 27001 auditors who will tell you plainly whether your SoA will hold up.