The Statement of Applicability is the single most scrutinized document in your ISMS — the one every auditor opens first, the one that either says "this organization understands its own risk" or quietly confesses that nobody does.
Who This Is For / What You'll Walk Away With
This article is for the person who has just been told, "we need a Statement of Applicability by Friday" — an ISMS manager, a CISO building their first management system, an internal auditor trying to judge whether an existing SoA holds water, or a consultant who has seen too many SoAs that were clearly written backward from a template. It assumes you already understand roughly what ISO 27001 is and that you have — or are close to finishing — a risk assessment and risk treatment plan. If you need that foundation first, start with what ISO 27001 actually is and Clause 6 on planning and risk assessment.
By the end, you will be able to:
Explain exactly what Clause 6.1.3 d) requires the SoA to contain, and why that's narrower — and harder — than "list all 93 controls"
Walk all four Annex A themes and 93 controls, deciding applicable vs. excluded for a specific organization
Write inclusion justifications that reference risk treatment decisions, not the control's own text
Write exclusion justifications that would survive a skeptical auditor's follow-up question
Record implementation status honestly, and link every control back to a risk or a control objective
Distinguish the SoA from the Risk Treatment Plan, and keep both synchronized as living documents
The SoA That Collapsed Under One Question
Marcus Delaney had been ISMS manager at Halloran Freight Analytics for four months when the Stage 2 audit began. Halloran was a mid-sized logistics-data firm — 140 employees, a SaaS platform that ingested shipping manifests for retailers, and a board that wanted the ISO 27001 certificate on the sales deck before the next renewal cycle with a major grocery chain. Marcus had inherited the ISMS from a consultant who had left the company six weeks after the risk assessment workshop, and the Statement of Applicability he inherited was, on the surface, immaculate: 93 rows, every control marked "Applicable — Yes," every implementation status marked "Implemented," every justification column filled with a single recurring phrase — "Required to meet Annex A control objective."
The lead auditor, on day one, opened the SoA before she opened anything else. She picked control 8.23, Web filtering, marked applicable and implemented, and asked Marcus to show her the web filtering policy and the technical configuration. There wasn't one — the company used a consumer-grade router with no content filtering at all. She then picked 5.23, Information security for use of cloud services, also marked implemented, and asked which of the risk assessment's cloud-related risks it was treating. Marcus couldn't answer, because the risk register didn't reference cloud services anywhere. Within ninety minutes, the auditor had traced eleven controls marked "implemented" back to nothing — no evidence, no owner, no link to a risk. She raised a major nonconformity against Clause 6.1.3 d) itself: the SoA did not reflect actual risk treatment decisions, meaning the organization could not demonstrate that its selection of controls was derived from its own risk assessment at all. The certification was delayed five months, the grocery-chain contract renewal slipped a full quarter, and Halloran spent close to $60,000 in consulting fees rebuilding the SoA from the risk register upward — the order it should have been built in the first time.
Marcus's mistake wasn't laziness so much as a fundamental misunderstanding shared by a huge number of first-time ISMS owners: he treated the Statement of Applicability as a compliance checklist to fill in, rather than as the documented output of a chain of decisions that starts with risk. That confusion is the single most common root cause of major nonconformities against Clause 6.1.3, and it's the reason this article exists.
"The SoA is not a form. It's a legal-grade argument about why your organization believes it is secure. Every row has to survive cross-examination." — Renata Osei, ISO 27001 Lead Auditor, 14 years auditing experience
What the Statement of Applicability Actually Is
The Statement of Applicability is a mandatory document required by Clause 6.1.3 d) of ISO/IEC 27001:2022. The clause requires the organization, after determining the controls necessary to implement its risk treatment options (6.1.3 b) and comparing that determination against the reference controls in Annex A to verify nothing necessary has been overlooked (6.1.3 c), to produce a Statement of Applicability that contains four specific things:
The necessary controls — those determined through risk treatment
Justification for their inclusion
Whether the necessary controls are implemented or not (implementation status)
The justification for excluding any of the Annex A controls
Read that list again, because almost every weak SoA fails on the ordering implied by items 1 and 2. The necessary controls come from risk treatment. Annex A is not the starting point — it's the checklist you compare against afterward, specifically to catch anything your risk assessment might have missed. Annex A is a reference set of 93 controls organized into four themes; it exists so that an organization can sanity-check its own risk-driven control selection, not so that an organization can adopt all 93 controls by default and call that "compliance." Excluding an Annex A control is entirely legitimate — provided you can justify why it doesn't apply to your risks, your scope, or your legal and contractual obligations.
Why Auditors Open the SoA First
Every experienced ISO 27001 auditor has a mental model of the ISMS before they walk in the door, built entirely from the SoA. It tells them, in one document, what the organization believes its risk landscape looks like, how mature its risk treatment process is, and — critically — whether the rest of the audit is going to be straightforward or a slow excavation of gaps. A SoA with thoughtful, risk-specific exclusions signals an organization that actually assessed its risk. A SoA where every control is "applicable and implemented" with identical boilerplate justification signals a document assembled to pass an audit rather than to run a security program — and that's exactly the signal Renata's team picked up on at Halloran.
Because the SoA sits at the intersection of Clause 6.1.3 (risk treatment), Clause 8 (operational implementation, covered in Clause 8: Operation), and the control guidance detail found in ISO/IEC 27002 (see ISO 27001 vs ISO 27002 for how the two standards divide labor), it is also the fastest way for an auditor to test whether your documentation is internally consistent. If the SoA says a control is implemented, the auditor expects to find a policy, a configuration, a log, or a person who can speak to it. If the SoA says a control is excluded, the auditor expects a reason tied to your scope (see Defining the Scope of Your ISMS) or your risk assessment — not silence.
Where the SoA Sits in the ISMS Workflow
The SoA is not a starting document — it's a downstream artifact of a chain of decisions. Skipping steps in this chain, or working it backward (starting from Annex A and retrofitting justifications), is exactly what produced Marcus's collapse at Halloran. The sequence below is what a defensible SoA actually traces back to:
flowchart TD
A[Risk Assessment: identify & analyze risks] --> B[Risk Treatment: select treatment option per risk]
B --> C[6.1.3 b: Determine controls necessary to implement treatment]
C --> D[6.1.3 c: Compare against Annex A reference controls]
D --> E{Control needed?}
E -->|Yes - covers a real risk or obligation| F[Include in SoA: justification + implementation status]
E -->|No - risk not present, or already mitigated elsewhere| G[Exclude in SoA: documented justification]
F --> H[Statement of Applicability]
G --> H
H --> I[Risk Treatment Plan: actions, owners, timelines]
I --> J[Clause 8 Operation: implement controls]
J --> K[Clause 9 Monitoring & Internal Audit: verify effectiveness]
K --> ANotice that the SoA has two inputs feeding it — included controls with justification and status, and excluded controls with justification — and one output, the Risk Treatment Plan, which turns "included and not yet implemented" rows into concrete project work. That relationship is explored fully later in this article, but it's worth internalizing now: the SoA is a decision record; the Risk Treatment Plan is a project plan. Conflating the two is the second most common documentation failure auditors report, right behind copy-pasted justifications.
Annex A: The Reference Set You Check Against, Not the Checklist You Adopt
Annex A of ISO/IEC 27001:2022 contains 93 controls organized into four themes. This is the full structure the SoA must work through, theme by theme, control by control:
Table 1: Annex A Themes at a Glance
Theme | Control Range | Number of Controls | What It Covers |
|---|---|---|---|
Organizational controls | 5.1 – 5.37 | 37 | Policies, roles, supplier relationships, incident management, business continuity, legal/regulatory compliance |
People controls | 6.1 – 6.8 | 8 | Screening, employment terms, awareness training, disciplinary process, remote working |
Physical controls | 7.1 – 7.14 | 14 | Perimeters, entry control, equipment protection, secure disposal, clear desk/screen |
Technological controls | 8.1 – 8.34 | 34 | Access control, malware protection, logging, cryptography, secure development, network security |
Total | 5.1 – 8.34 | 93 |
A critical point that gets lost in practice: Annex A is a reference — it exists so that, after you've derived your own control set from risk treatment, you can cross-check it against a common, industry-recognized list and catch anything you might have missed. It is not a mandatory checklist where every organization must implement all 93 controls. A three-person consultancy with no physical office and no on-premises servers has a legitimate basis to exclude most of the Physical theme. A software company with no supplier-managed data processing has a legitimate basis to exclude parts of 5.19–5.22 on supplier relationships. What's not legitimate is excluding a control because implementing it is expensive or inconvenient, while the underlying risk is still very real.
SoA vs. Risk Treatment Plan: Two Related but Different Documents
One of the most persistent points of confusion — and a frequent audit finding on its own — is treating the SoA and the Risk Treatment Plan (RTP) as interchangeable. They are tightly linked but answer different questions.
Table 2: SoA vs. Risk Treatment Plan
Dimension | Statement of Applicability | Risk Treatment Plan |
|---|---|---|
Core question answered | Which controls apply, why, and are they implemented? | How, when, and by whom will each treatment be carried out? |
Clause reference | 6.1.3 d) | 6.1.3 e) |
Scope of content | All 93 Annex A controls (included + excluded) | Only the actions needed to treat identified risks |
Contains justifications? | Yes — inclusion and exclusion justification is mandatory | No — contains actions, not rationale for applicability |
Contains owners/deadlines? | Rarely — status only, not project detail | Yes — owner, target date, resourcing |
Update trigger | Any change to risk assessment, scope, controls, or status | Any change in project progress or new treatment decision |
Audience | Auditors, senior management, regulators | Project owners, implementation teams, ISMS manager |
Typical format | Structured register/table, often spreadsheet or GRC tool | Project plan or tracked action list |
In short: the SoA tells you what and why; the RTP tells you how and by when. A mature ISMS keeps both, cross-referenced by control number, and updates them in the same change cycle — because a control that moves from "not implemented" to "implemented" in the SoA should be traceable to a closed action in the RTP.
Step 1: Start From Risk Treatment, Not From Annex A
The build order matters more than almost anything else in this exercise. If you open a blank SoA template and start reading down the Annex A list asking "do we do this?", you will produce exactly the document Marcus inherited — technically complete, substantively empty. Instead, the SoA should be assembled from three inputs you should already have on the table before you touch Annex A:
The risk register — every risk you've identified and analyzed, with likelihood, impact, and current treatment decision (avoid, reduce, transfer, or accept)
The risk treatment decisions — for every risk you chose to reduce, what control or set of controls was selected to reduce it
Legal, regulatory, and contractual obligations — requirements that exist independent of your risk register, such as a client contract mandating encryption at rest, or a data protection law requiring breach notification procedures
From these three inputs, you build a working list of "controls we need." Only then do you open Annex A, 93 controls in order, and ask two questions for each one: does this control already appear on our working list? and if not, does comparing against it reveal a risk or obligation we missed? That second question is the entire point of Clause 6.1.3 c) — Annex A functions as a completeness check, not a wish list.
Step 2: Walking Every Control — Applicable or Not
With your risk-driven working list in hand, work through all four themes in order — Organizational (5.1–5.37), People (6.1–6.8), Physical (7.1–7.14), Technological (8.1–8.34) — and make one of three determinations for each control:
Applicable and already addressed by an existing control on your working list — record it as included, with justification pointing to the risk or obligation it treats
Applicable but not yet in place — record it as included, justification as above, implementation status "not implemented" or "partially implemented," and a corresponding action opened in the Risk Treatment Plan
Not applicable — record it as excluded, with a specific justification tied to your scope, your risk assessment, or the absence of the underlying activity the control assumes exists
"I tell every client the same thing on day one: if you can't finish the sentence 'we excluded this control because…' without saying nothing after 'because,' you're not ready to exclude it." — Devon Marchetti, Principal Security Consultant, has led SoA workshops for 60+ certification projects
Table 3: Determining Applicability — Decision Criteria
Question to Ask | If Yes → | If No → |
|---|---|---|
Does the control treat a risk identified in the risk assessment? | Likely applicable | Continue checking |
Does a law, regulation, or contract require this control regardless of internal risk rating? | Applicable (obligation-driven) | Continue checking |
Is the underlying activity or asset type present in your ISMS scope? (e.g., cloud services, physical offices, software development) | Continue checking | Likely not applicable — document why the activity doesn't exist in scope |
Is the risk already fully treated by a different control, making this one redundant? | Consider exclusion, referencing the control that covers it | Applicable |
Would excluding this control leave a risk in the register untreated? | Do not exclude | Exclusion is defensible |
Writing Defensible Inclusion Justifications
An inclusion justification should never simply restate the control's own wording back at itself — "Access control is applicable because access needs to be controlled" tells an auditor nothing and is functionally identical to leaving the cell blank. A strong inclusion justification names the risk (ideally by risk register ID), the asset or process it protects, and, where relevant, the obligation driving it.
Table 4: Inclusion Justification — Weak vs. Strong
Control | Weak Justification (Fails Audit Scrutiny) | Strong Justification (Defensible) |
|---|---|---|
5.15 Access control | "Required for information security." | "Treats Risk R-014 (unauthorized access to customer manifest data); enforces least-privilege model defined in the Access Control Policy." |
6.7 Remote working | "All companies need this now." | "Treats Risk R-027 (data exposure via unmanaged home networks) following shift to hybrid work in 2024; scope covers all staff with VPN access to production systems." |
8.24 Use of cryptography | "Good security practice." | "Treats Risk R-009 (interception of data in transit) and satisfies Clause 5.4 of the ClientCo Master Services Agreement requiring TLS 1.2+ for data transfer." |
5.7 Threat intelligence | "Recommended by ISO." | "Treats Risk R-031 (undetected emerging threats targeting logistics-sector SaaS); feeds quarterly threat briefings into the risk register review." |
Writing Defensible Exclusion Justifications
Exclusions carry more audit weight than inclusions, because they are where organizations are tempted to cut corners. The test an auditor will apply, implicitly or explicitly, is: does this justification describe an absence of risk, or an absence of effort? The former is defensible; the latter is a nonconformity waiting to be found.
Table 5: Exclusion Justification — Weak vs. Strong
Control | Weak Justification (Signals Avoidance) | Strong Justification (Defensible) |
|---|---|---|
7.1 Physical security perimeters | "Not a priority right now." | "Organization has no physical offices or on-premises data centers; all staff work remotely and all infrastructure is hosted in a Tier 3+ cloud provider's facilities, whose physical controls are covered under 5.23 and the provider's SOC 2 report." |
8.30 Outsourced development | "Too expensive to assess right now." | "No software development is outsourced to third parties; all development is performed by in-house engineering, covered under 8.25–8.29." |
5.29 Information security during disruption | "We'll deal with it if it happens." | "Risk assessment rated business disruption scenarios as low likelihood and low impact given a single-region, non-critical service (internal analytics dashboard only); reassessed annually as part of BCM review." |
7.14 Secure disposal or re-use of equipment | "IT handles that informally." | "Excluded from initial scope pending confirmation — currently marked as gap, target inclusion Q3 2026." (Note: an honest "not yet decided" is preferable to a fabricated justification — but should not remain open indefinitely.) |
A justification like "not a priority" or "we'll get to it" is not a justification for exclusion — it's an admission of a gap, and it should be recorded honestly as a control that is applicable but not implemented, feeding the Risk Treatment Plan, rather than dressed up as an exclusion to make the SoA look cleaner than reality.
"The worst SoAs I've reviewed aren't the ones with gaps. Gaps are normal — every organization has them on day one. The worst ones are the ones that hide gaps behind a false exclusion." — Priya Nandakumar, GRC Manager, has reviewed SoAs across finance, healthcare, and SaaS sectors
Implementation Status: What "Implemented" Actually Means
The third mandatory element of the SoA — whether necessary controls are implemented — is where documents most often drift from reality, because "implemented" is treated as binary when it's rarely that simple. A defensible SoA distinguishes between genuine implementation states rather than forcing every control into "yes" or "no."
Table 6: Implementation Status Categories
Status | Definition | Evidence an Auditor Will Expect |
|---|---|---|
Implemented | Control is fully designed, deployed, and operating as intended | Policy/procedure document, technical configuration, logs or records showing operation |
Partially implemented | Control is in place for some but not all applicable assets, teams, or locations | Same as above, scoped to the covered subset, plus a documented plan for the remainder |
Planned / not yet implemented | Control is applicable and justified but not yet built | Entry in the Risk Treatment Plan with owner and target date |
Implemented via third party | Control is satisfied by a supplier, cloud provider, or outsourced service rather than internally | Contract clause, SOC 2/ISO certificate, or equivalent assurance evidence from the third party |
Not applicable | Excluded per justification | The exclusion justification itself; no further evidence expected |
Marking a control "implemented" without being able to produce at least one of the evidence types above is the single fastest way to convert a routine audit question into a nonconformity — as Halloran discovered with 8.23 and 5.23 in the opening story.
The Worked SoA Excerpt: A Real Cross-Theme Example
The table below is a representative excerpt — not a complete SoA — showing how a mid-sized SaaS company (modeled loosely on Halloran, post-rebuild) might document a handful of controls from each of the four themes. Use it as a pattern for structure and tone, not as a template to copy wholesale — your justifications must reflect your own risk register.
Table 7: Worked SoA Excerpt (Sample Controls Across All Four Themes)
Control # | Control Name | Applicable (Y/N) | Justification | Implementation Status | Related Risk/Reference |
|---|---|---|---|---|---|
5.7 | Threat intelligence | Y | Treats R-031 (emerging sector-specific threats); informs quarterly risk register review | Partially implemented | R-031 |
5.19 | Information security in supplier relationships | Y | Treats R-018 (data exposure via third-party integrations); all vendors handling manifest data assessed pre-onboarding | Implemented | R-018 |
5.23 | Information security for use of cloud services | Y | Treats R-005 (misconfiguration of cloud-hosted production environment); shared responsibility model documented with AWS | Implemented | R-005 |
5.31 | Legal, statutory, regulatory and contractual requirements | Y | Statutory obligation; tracks data protection and retail-sector contractual clauses | Implemented | Legal Register L-002 |
6.3 | Information security awareness, education and training | Y | Treats R-011 (phishing-driven credential compromise); mandatory onboarding + annual refresher | Implemented | R-011 |
6.7 | Remote working | Y | Treats R-027 (data exposure via unmanaged home networks); VPN + endpoint policy for all remote staff | Implemented | R-027 |
7.1 | Physical security perimeters | N | No physical offices or on-premises facilities; fully remote workforce, infrastructure hosted with certified cloud provider | Not applicable | Scope Statement §3 |
7.4 | Physical security monitoring | N | Excluded for the same reason as 7.1; provider's physical monitoring covered under supplier due diligence (5.19) | Not applicable | Scope Statement §3 |
7.10 | Storage media | Y | Treats R-022 (data leakage via unencrypted removable media); policy prohibits unencrypted USB storage | Implemented | R-022 |
8.7 | Protection against malware | Y | Treats R-003 (malware-driven system compromise); EDR deployed to all endpoints | Implemented | R-003 |
8.8 | Management of technical vulnerabilities | Y | Treats R-006 (unpatched vulnerabilities exploited); monthly vulnerability scanning, quarterly external pentest | Partially implemented | R-006 |
8.15 | Logging | Y | Treats R-014 (undetected unauthorized access); centralized log aggregation for production systems | Implemented | R-014 |
8.23 | Web filtering | Y | Treats R-034 (malicious site access from corporate devices); DNS-layer filtering deployed post-remediation | Implemented | R-034 |
8.28 | Secure coding | Y | Treats R-009 (introduction of exploitable code defects); secure coding standard adopted, static analysis in CI pipeline | Partially implemented | R-009 |
8.30 | Outsourced development | N | No development activity is outsourced; all engineering performed in-house | Not applicable | Scope Statement §4 |
For a complete breakdown of what every one of the 93 controls covers and how they group by intent, a dedicated reference — Annex A Controls Explained: All 93 — is worth keeping open alongside your SoA while you work through this exercise.
Organizational Controls (5.1–5.37) in the SoA
The Organizational theme is the largest, and it tends to have the highest inclusion rate of any theme, because most of its 37 controls concern policy, governance, and process — things nearly every organization needs in some form, even if implementation maturity varies widely.
Table 8: Organizational Controls — Common Applicability Patterns
Control Group | Examples | Typical Applicability | Common Reason for Exclusion (if any) |
|---|---|---|---|
Policy and governance | 5.1 Policies for information security, 5.2 Roles and responsibilities, 5.3 Segregation of duties | Almost always applicable | Rarely excluded outright; may be partially implemented in very small teams |
Asset and information handling | 5.9–5.14 (inventory, acceptable use, classification, labelling, transfer) | Almost always applicable | N/A |
Supplier relationships | 5.19–5.22 | Applicable if any third parties process data or provide services | Excluded only where an organization genuinely has no suppliers with data access |
Cloud services | 5.23 | Applicable to nearly all modern SaaS/cloud-hosted organizations | Excluded only for fully on-premises, air-gapped environments |
Incident management | 5.24–5.28 | Almost always applicable | N/A |
Business continuity | 5.29–5.30 | Applicable where disruption would materially affect operations | Sometimes scoped down for low-criticality internal-only systems |
Legal and compliance | 5.31–5.36 | Almost always applicable | N/A |
People Controls (6.1–6.8) in the SoA
The People theme is small — only 8 controls — but it is one of the highest-risk areas to under-document, because human error and insider risk consistently rank among the top causes of security incidents across industries.
Table 9: People Controls — Common Applicability Patterns
Control | Name | Typical Applicability | Notes |
|---|---|---|---|
6.1 | Screening | Applicable wherever hiring occurs | Depth of screening should map to role sensitivity |
6.2 | Terms and conditions of employment | Almost universally applicable | Ties to HR contracts |
6.3 | Awareness, education and training | Almost universally applicable | Frequently under-evidenced — auditors ask for training records, not just a policy |
6.4 | Disciplinary process | Almost universally applicable | Must link to actual HR process, not just a policy statement |
6.5 | Responsibilities after termination | Almost universally applicable | Offboarding checklist is common evidence |
6.6 | Confidentiality/NDA agreements | Almost universally applicable | Often already in place for legal reasons pre-dating the ISMS |
6.7 | Remote working | Applicable to any organization with remote or hybrid staff | Rapidly increased in relevance since 2020; frequently under-scoped |
6.8 | Information security event reporting | Almost universally applicable | Requires a clear, low-friction reporting channel — not just a policy |
Physical Controls (7.1–7.14) in the SoA
Physical controls are the theme most affected by an organization's actual footprint — and the one where legitimate, well-justified exclusions are most common and most defensible, provided the underlying scope statement supports them.
Table 10: Physical Controls — Common Applicability Patterns
Control Group | Examples | Fully Remote / Cloud-Only Org | Org with Physical Offices/Data Center |
|---|---|---|---|
Perimeters and entry | 7.1 Physical security perimeters, 7.2 Physical entry | Often excluded (no facilities) | Applicable |
Monitoring and environment | 7.4 Physical security monitoring, 7.5 Protecting against physical/environmental threats | Often excluded or covered via supplier (5.23) | Applicable |
Workspace behavior | 7.6 Working in secure areas, 7.7 Clear desk and clear screen | Sometimes still applicable for home offices handling sensitive data | Applicable |
Equipment | 7.8 Equipment siting, 7.9 Assets off-premises, 7.13 Equipment maintenance | Applicable to laptops/endpoints regardless of office footprint | Applicable |
Media and disposal | 7.10 Storage media, 7.14 Secure disposal or re-use of equipment | Applicable | Applicable |
The critical discipline here: even a fully remote organization still issues laptops, handles removable media, and disposes of old hardware — so 7.9, 7.10, and 7.14 are rarely fully excludable even when 7.1 and 7.2 legitimately are.
Technological Controls (8.1–8.34) in the SoA
The Technological theme is the largest after Organizational, and it's where SoAs most often fail on implementation status rather than applicability — nearly every organization needs most of these 34 controls; the honest question is usually "how mature is it," not "does it apply."
Table 11: Technological Controls — Common Applicability Patterns
Control Group | Examples | Typical Applicability | Common Maturity Gap |
|---|---|---|---|
Access and authentication | 8.1–8.5 (endpoint devices, privileged access, source code, secure authentication) | Almost always applicable | MFA coverage often partial at first assessment |
Operations | 8.6–8.14 (capacity, malware, vulnerabilities, configuration, backup, redundancy) | Almost always applicable | Vulnerability management often reactive, not scheduled |
Logging and monitoring | 8.15–8.18 | Almost always applicable | Logging exists; centralized monitoring/alerting often lags |
Network security | 8.20–8.23 (network security, segregation, web filtering) | Almost always applicable | Segmentation frequently incomplete in smaller environments |
Cryptography | 8.24 | Almost always applicable | Key management maturity varies widely |
Secure development | 8.25–8.29, 8.31–8.34 | Applicable to any org that develops software | Security testing often added late in the SDLC |
Outsourced development | 8.30 | Applicable only if development is outsourced | Legitimately excluded for in-house-only engineering |
Linking Every Control to Risk Treatment and the Risk Register
A defensible SoA is traceable in both directions. From any control row, you should be able to point to the specific risk (or legal/contractual obligation) it treats. From any risk in the register, you should be able to point to which control or controls were selected to treat it. When that traceability breaks — a control marked applicable with no corresponding risk, or a high risk in the register with no control referencing it — you have exactly the gap Renata's team found at Halloran.
This is why the "Related Risk/Reference" column in the worked SoA excerpt above isn't decorative. It's the load-bearing column that turns a list of assertions into an auditable chain of evidence. If your risk assessment process is still informal, or you're not confident your risk register is complete enough to drive this mapping, it's worth working through How to Conduct an ISO 27001 Risk Assessment as a companion exercise before finalizing the SoA — trying to build the SoA on a thin risk register is how organizations end up reverse-engineering justifications after the fact, which auditors can usually spot immediately.
A practical cross-check worth running before any audit: pick ten risks at random from the register and ten controls at random from the SoA, and trace each one to its counterpart. If you can't complete the trace within a couple of minutes per item, the mapping isn't ready.
Case Study: The SoA That Survived Stage 2 Without a Single Follow-Up Question
Halloran's rebuild, six months after the failed Stage 2 attempt, offers a useful contrast. Marcus, working with an external consultant this time, rebuilt the SoA from the risk register upward exactly in the order described earlier in this article: risk assessment first, treatment decisions second, Annex A comparison third. When the delayed Stage 2 audit resumed, the same lead auditor, Renata, spent forty minutes on the SoA — roughly a quarter of the time she'd spent the first time — and raised zero findings against Clause 6.1.3. She later told Marcus, off the record, that the difference wasn't the quality of the controls themselves (several had barely changed), it was that every justification named a risk ID she could trace directly into the risk register, and every exclusion named a specific scope boundary rather than a vague dismissal. Halloran was certified eleven weeks later, and the grocery-chain contract renewal — the one that had slipped a quarter the first time — closed on schedule the second time around.
"A good SoA doesn't need to be defended in the room. It defends itself, because every line already answers the question before I ask it." — Renata Osei, ISO 27001 Lead Auditor
Case Study: SoA Drift and a Repeat Nonconformity
A second, illustrative pattern: a regional healthcare billing processor — call it Ferrow Medical Systems, 80 employees — passed initial certification with a solid SoA built the right way, risk-first. Eighteen months later, at the first surveillance audit, the auditor found that the SoA still listed the same 61 applicable controls with the same implementation statuses as the original certification audit — despite the company having migrated its entire billing platform to a new cloud provider, added two new sub-processors, and discontinued an on-premises fax-to-EHR gateway that had originally justified several Physical-theme control inclusions. Nobody had updated the SoA to reflect any of it. The auditor didn't find a single control implemented incorrectly — the finding was that the SoA no longer reflected the current environment, a minor nonconformity under ongoing document control requirements. Ferrow closed the gap within thirty days by instituting a quarterly SoA review tied to change management, but the finding was avoidable: the SoA had simply been treated as a one-time certification artifact rather than a living document.
"The SoA you certified against and the SoA sitting on the shelf eighteen months later should not be strangers to each other." — Devon Marchetti, Principal Security Consultant
Case Study: The Over-Excluded SoA That Lost a Deal
Not every SoA failure surfaces in a certification audit — some surface in a sales cycle. A workforce-management SaaS vendor, referred to here as Corvale Systems, built its first SoA under time pressure ahead of a certification deadline tied to a funding round. To move quickly, the ISMS lead excluded a disproportionate share of controls across the Technological theme — including 8.16 Monitoring activities, 8.9 Configuration management, and 8.34 Protection of information systems during audit testing — with justifications that amounted to "not currently resourced." The certificate was issued; the auditor, working from a sampling plan rather than a full walk-through, didn't happen to sample those specific rows during Stage 2.
Eight months later, a prospective enterprise client's security team requested the SoA directly as part of vendor due diligence — a request that has become increasingly common as clients treat the SoA as a substitute for a lengthy security questionnaire. Reading the document line by line, the prospect's security architect flagged the same pattern the internal auditor had missed: a cluster of excluded controls with vague, effort-based justifications clustered in exactly the areas — monitoring, configuration, vulnerability management — that mattered most for the specific integration being discussed. The deal, worth an estimated $340,000 in annual contract value, stalled for six weeks while Corvale scrambled to produce real justifications or genuine remediation timelines, and ultimately closed at a reduced scope with additional contractual security commitments layered on top. The certificate hadn't lied outright, but the SoA behind it hadn't held up to a motivated reader either.
"Your SoA doesn't just get read by an auditor once a year anymore. Increasingly, it gets read by every serious enterprise prospect's security team before they'll sign anything." — Tomás Reyes, Internal Audit Lead, has run vendor security reviews for a Fortune 500 procurement function
The lesson generalizes beyond audits: because more buyers now request the SoA directly as part of procurement due diligence, a document engineered to slip past a sampling-based certification audit is not the same as a document that will hold up to a determined, technically literate outside reader with a commercial stake in finding the gaps.
How Auditors Actually Sample the SoA
It's worth understanding the mechanics behind Corvale's near-miss and Halloran's direct hit, because they illustrate two different audit realities that shape how defensible your SoA needs to be. Auditors do not typically verify all 93 rows line by line — certification bodies work from a sampling methodology proportional to the size and complexity of the ISMS, often weighted toward higher-risk control areas, recent changes, and any control the organization itself flagged as newly implemented. That means an indefensible row can survive a single audit cycle purely by not being sampled — which is precisely why "it passed the audit" is a weaker signal of SoA quality than it appears to be.
Table 12: How Auditors Typically Select SoA Rows to Test
Sampling Factor | Why It Increases Scrutiny |
|---|---|
Control marked "implemented" but recently changed status | Auditors probe recent changes for premature status updates |
Control tied to a high or critical risk in the register | Higher consequence if the control turns out to be weaker than documented |
Control with unusually generic or repeated justification wording | Boilerplate language across multiple rows signals a template exercise |
Control related to a prior audit finding or nonconformity | Verifying the corrective action actually closed the gap |
Exclusions clustered in one theme or control group | Pattern suggests scope-driven avoidance rather than case-by-case assessment |
Controls central to the organization's stated risk profile (e.g., 8.28 for a software company, 5.23 for a cloud-native business) | These are the controls where a gap would matter most |
The practical implication is not "hope you don't get sampled" — it's that every row should be written as though it will be, because the rows most likely to be sampled are also, not coincidentally, the rows where a gap does the most damage if left untreated.
SoA Structure for Multi-Site and Multi-Business-Unit Organizations
A single flat SoA works well for a single-site, single-business-unit organization, but larger organizations — multiple offices, multiple product lines, or a parent company with several subsidiaries inside one certification scope — often need a slightly different structure to stay both accurate and usable. Two approaches are common in practice:
Table 13: SoA Structuring Approaches for Complex Organizations
Approach | How It Works | Best Fit | Risk |
|---|---|---|---|
Single unified SoA with a "scope/location" column | One document, one row per control, with an added column noting which sites or business units the applicability and status apply to | Organizations with largely consistent control implementation across units | Column can become overloaded and hard to read if variation is high |
Master SoA plus site/unit-level addenda | One master document setting overall applicability logic, with supplementary documents recording site-specific implementation status | Organizations with materially different environments per site (e.g., one site has a data center, others don't) | Requires strong version control discipline to keep master and addenda synchronized |
Whichever structure is chosen, the underlying rule doesn't change: every applicability decision still has to trace back to a risk, an obligation, or a documented scope boundary — multi-site complexity is a formatting challenge, not a license to loosen the justification standard.
Common SoA Mistakes and How to Avoid Them
Across certification projects, the same handful of mistakes recur often enough to be worth naming directly.
Table 14: Common SoA Mistakes
Mistake | Why It Happens | Consequence | Fix |
|---|---|---|---|
Excluding controls to avoid work, not because risk is absent | Pressure to minimize implementation effort before an audit deadline | Major nonconformity if discovered; latent security gap if not | Justify exclusions against risk assessment and scope only, never against effort |
Marking everything "applicable and implemented" without evidence | Assumption that a fuller SoA looks stronger | Auditor spot-checks fail immediately, credibility of entire ISMS damaged | Use the full status taxonomy (implemented, partial, planned, third-party, N/A) honestly |
Copy-pasting a generic or template SoA | Time pressure, lack of confidence in risk assessment output | Justifications don't match the organization's actual environment; easily detected | Build from your own risk register every time — templates only for structure, never content |
Letting the SoA drift out of sync with reality | Treated as a one-time certification deliverable | Nonconformities at surveillance audits, misleading risk picture for management | Tie SoA review to change management and a fixed review cadence |
Vague, boilerplate justifications repeated across many rows | Time pressure, unclear ownership of the exercise | Auditor cannot verify traceability to risk; signals a checkbox exercise | Reference specific risk IDs, assets, or obligations per row |
No link between SoA and Risk Treatment Plan | Documents built by different people at different times | Statuses become unreliable, no visibility into remediation progress | Cross-reference control numbers between both documents; review together |
Keeping the SoA a Living Document
Ferrow's story illustrates the point directly: an SoA is correct on the day it's approved and increasingly wrong every day after that, unless something forces a review. The organizations that avoid drift treat the SoA the way they'd treat any other risk-relevant record — reviewed on a schedule, and reviewed on trigger events, not just at certification and recertification.
Table 15: SoA Maintenance Cadence
Trigger | Review Action | Typical Owner |
|---|---|---|
Scheduled quarterly review | Confirm implementation statuses still accurate; check for any risk register changes since last review | ISMS Manager |
Annual management review cycle | Full re-walk of applicability decisions alongside risk assessment refresh | ISMS Manager + Top Management |
New system, service, or major project | Assess whether new controls become applicable (e.g., new cloud service triggers 5.23 review) | Project Owner + ISMS Manager |
New or changed supplier/sub-processor | Reassess 5.19–5.22 applicability and evidence | Procurement/Vendor Risk Owner |
Significant incident | Reassess related control's justification, status, and effectiveness | Incident Response Lead + ISMS Manager |
Change in scope (Clause 4.3) | Full applicability re-walk against updated scope statement | ISMS Manager + Top Management |
Internal audit finding | Update affected control(s) status and justification as corrective action | ISMS Manager |
Regulatory or contractual change | Reassess controls tied to the changed obligation | Legal/Compliance + ISMS Manager |
A quarterly cadence is a reasonable default for most mid-sized organizations; higher-change environments (rapid cloud migration, frequent M&A, fast headcount growth) may warrant monthly spot-checks on the highest-risk control groups even between full reviews.
Version Control and Change Management for the SoA
Because the SoA is referenced by auditors across multiple audit cycles, version discipline matters as much as content accuracy. Every revision should carry a version number, a date, the name of the approver, and — critically — a change log entry explaining what changed and why, not just that something changed. A control moving from "not implemented" to "implemented" should reference the closed Risk Treatment Plan action that made it true. A newly excluded control should reference the scope or risk assessment change that justified the exclusion. Without this discipline, an auditor reviewing historical versions during a surveillance audit has no way to distinguish a deliberate, risk-informed update from an unexplained, potentially convenient one.
Table 16: SoA Version Control Fields
Field | Purpose |
|---|---|
Version number | Uniquely identifies the SoA revision under review |
Effective date | When the revision took effect |
Approved by | Accountable owner (typically ISMS Manager or Top Management representative) |
Change summary | What changed since the prior version, at a control level |
Trigger reference | Link to the event that prompted the change (risk review, incident, scope change, audit finding) |
Linked RTP version | Ensures SoA and Risk Treatment Plan are read against consistent versions of each other |
Who Owns the SoA
Ownership confusion is a quieter but still common failure mode — the SoA gets built once by a consultant, handed to whoever happens to be the ISMS manager at the time, and never has a clearly assigned steward afterward. A RACI model makes ongoing accountability explicit.
Table 17: SoA Ownership — RACI
Activity | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
Initial SoA drafting from risk treatment output | ISMS Manager | ISMS Manager | Risk owners, control owners, legal/compliance | Top Management |
Approval of SoA | ISMS Manager | Top Management | Internal audit | All control owners |
Quarterly status review | ISMS Manager | ISMS Manager | Control owners | Top Management |
Updating justifications after scope or risk change | ISMS Manager | Top Management | Risk owners, legal/compliance | Internal audit |
Verifying evidence behind "implemented" status | Internal audit | Internal audit | Control owners | ISMS Manager |
Presenting SoA to external auditor | ISMS Manager | ISMS Manager | Control owners (as needed) | Top Management |
Spreadsheets, Templates, and GRC Tools: Choosing How to Maintain the SoA
Most organizations start the SoA in a spreadsheet, and for many small and mid-sized ISMS implementations, that remains entirely adequate — provided version control discipline is maintained manually and rigorously. Larger or more complex environments, especially those managing multiple frameworks alongside ISO 27001 (SOC 2, PCI DSS, GDPR-driven obligations), often outgrow spreadsheets because cross-referencing risks, controls, evidence, and audit history by hand becomes error-prone at scale.
Table 18: SoA Maintenance Approach Comparison
Approach | Best Fit | Strengths | Weaknesses |
|---|---|---|---|
Spreadsheet (structured template) | Small-to-mid ISMS, single framework | Low cost, fast to start, flexible | Manual version control, no automatic cross-referencing, easy to let drift |
GRC platform | Multi-framework, larger organizations, frequent audits | Automated control-to-risk mapping, evidence attachment, audit trail | Licensing cost, implementation effort, can become its own maintenance burden |
Hybrid (spreadsheet + document management system) | Growing mid-sized organizations | Retains spreadsheet flexibility with enforced version history | Still manual mapping; relies on process discipline rather than tooling |
Whichever approach you choose, a ready-made starting point removes a surprising amount of friction — a structured Statement of Applicability (SoA) Template that already carries the six required columns (control number, name, applicability, justification, status, risk reference) saves the first few hours of formatting decisions that otherwise delay the substantive work of actually walking the controls.
Formatting and Numbering Conventions Worth Adopting
A handful of small formatting decisions, made consistently, save significant time during both internal review and external audit. First, always retain the exact Annex A control numbering (5.1 through 8.34) rather than inventing an internal numbering scheme — auditors, consultants, and any future ISMS owner should be able to cross-reference your SoA against the published standard without translation. Second, keep control names verbatim from the standard rather than paraphrasing them, since paraphrased names create ambiguity about which control is actually being addressed. Third, resist the temptation to merge multiple controls into a single row for convenience — each of the 93 controls should have its own row, even where the same underlying implementation (say, a single access control platform) satisfies several related controls; a shared implementation is still recorded as separate applicability and status decisions per control.
Fourth, keep the justification and evidence-reference columns separate rather than combining them — the justification explains why a control is applicable or excluded, while the evidence reference points to where proof lives (a policy document ID, a ticket number, a system name). Conflating the two makes both harder to audit cleanly. Finally, resist compressing the four-theme structure into an alphabetized or re-sorted list; keeping controls grouped and ordered by theme (Organizational, then People, then Physical, then Technological) mirrors how Annex A itself is published and how most auditors expect to navigate the document, which reduces friction during the audit interview itself.
The Board-Level Cost of Getting This Wrong
It's worth pausing on why the SoA carries this much weight beyond audit mechanics. A weak or fabricated SoA doesn't just risk a nonconformity — it means senior management is making risk decisions based on a document that misrepresents the organization's actual security posture. If the board believes 93 controls are implemented when a third of them are aspirational, budget doesn't get allocated to close real gaps, incident response plans get built on false assumptions about what's actually monitored, and — as Halloran discovered — commercial relationships that depend on the certificate get disrupted the moment the fiction is tested. The SoA is simultaneously an audit artifact and a management decision-support tool; treating it as only the former is how it degrades into the latter's enemy.
"Every dollar an organization saves by faking a SoA row, it pays back tenfold the day that row gets tested — by an auditor, a regulator, or an attacker. Usually in that order." — Devon Marchetti, Principal Security Consultant
Preparing to Present the SoA to an Auditor
Beyond writing a defensible document, there's a separate skill in presenting it well during the audit interview itself — and it's worth rehearsing before Stage 2, not discovering under pressure the way Marcus did. Assign one person, typically the ISMS manager, as the primary voice for SoA questions, but make sure control owners for the highest-risk rows are reachable during the audit window rather than on leave or unavailable, since "let me find out and get back to you" repeated across several rows reads very differently than it does once. Walk through the SoA yourself, cold, a week before the audit, picking rows at random the way an auditor would, and time how long it takes to locate supporting evidence for each — if it takes you ten minutes to find the log export proving 8.15 Logging is operating, it will take the auditor the same ten minutes, multiplied by however many rows they sample, and that friction alone can read as a maturity gap even when the control genuinely works.
It also helps to distinguish, out loud, between the SoA's justification language and the deeper technical detail an auditor may want next — a good response to "why is 8.24 applicable" gives the risk-based justification directly from the document, then offers to go deeper into the cryptographic implementation only if asked, rather than front-loading unnecessary technical detail that can introduce inconsistencies with what's actually written down. Rehearsing this distinction is a small investment that measurably shortens audit interviews and reduces the chance of an offhand verbal comment contradicting the documented justification.
"The best audit interviews I run are boring. The SoA answers the question, the evidence confirms the SoA, and we move to the next row. Excitement in an audit interview usually means something doesn't match." — Priya Nandakumar, GRC Manager
Building Your First SoA: A Practical Checklist
Bringing the whole process together, here is the sequence a first-time ISMS owner should follow, drawing on everything above:
Confirm your ISMS scope statement is finalized and stable before starting — applicability decisions depend on it
Confirm the risk assessment and risk treatment decisions are complete for all identified risks
Build a working list of controls implied by risk treatment decisions and known legal/contractual obligations
Walk all 93 Annex A controls in theme order, comparing against your working list
For each control, decide applicable or not applicable, and write a specific justification referencing risk IDs, obligations, or scope boundaries
For applicable controls, record an honest implementation status using the full taxonomy (implemented, partial, planned, third-party, not applicable)
Cross-reference every included control to a Risk Treatment Plan action if not yet fully implemented
Have a second reviewer — ideally internal audit or an external consultant — spot-check a sample of both inclusions and exclusions for defensibility
Get formal approval and version the document
Schedule the first quarterly review before you file the SoA away
Cross-Framework Considerations: SoA in a Multi-Framework Environment
Many organizations building an SoA aren't starting from a blank slate — they already hold a SOC 2 report, align loosely to the NIST Cybersecurity Framework, or carry PCI DSS obligations because they handle payment data. None of these substitute for the SoA, but they can accelerate it: a control already operating to satisfy a SOC 2 Type II audit — logging, access reviews, change management — often maps directly onto an Annex A control, and the existing evidence can be reused rather than rebuilt. If you're trying to understand how ISO 27001's control set relates to these other frameworks at a structural level before you map individual controls, ISO 27001 vs NIST/SOC 2/PCI DSS Compared lays out where they overlap and where they diverge — and where a PCI DSS obligation might force an inclusion in your SoA that your own risk assessment alone would not have flagged. The same logic applies to GDPR obligations feeding into 5.34 Privacy and protection of PII — a legal requirement, not just a risk-driven choice, and one of the clearer examples of where "applicable" is determined by law rather than likelihood and impact.
If your organization is still building foundational ISMS understanding alongside the SoA, it's worth anchoring back to ISMS Core Concepts and the ISO 27001 Terminology and Glossary — both make the applicability conversation faster because everyone on the team is using "control," "risk treatment," and "residual risk" the same way. And because who your stakeholders are often shapes which controls carry contractual weight, Interested Parties and Stakeholder Requirements is a useful companion for identifying obligations that belong in your SoA justifications before an auditor — or a client — points them out for you.
For teams building the supporting documents in parallel, a Risk Register Template and a Gap Analysis Tool both reduce the manual overhead of the mapping exercise described earlier, and a hands-on lab — Build a Sample Risk Treatment Plan — is a useful way to practice turning SoA gaps into a working RTP before doing it for real. For a quick-reference companion while you walk all 93 controls theme by theme, keep the Annex A — All 93 Controls at a Glance one-pager open alongside this article.
Where This Leaves You
The Statement of Applicability is not a document you write once and file — it's the running scoreboard of how well your risk decisions and your actual controls line up, and it's the first thing any competent auditor will use to decide how carefully to look at everything else. Build it in the right order — risk assessment, then treatment, then Annex A comparison — and every justification you write will already have an answer ready before an auditor asks the question. Build it backward from a template, and you're gambling that nobody checks, which is exactly the bet Marcus lost the first time around.
If you're working through your own SoA right now, PentesterWorld's penetration testing and control validation services can pressure-test the "implemented" claims in your SoA before an external auditor does — surfacing the gap between what your documentation says and what your environment actually enforces, while there's still time to close it quietly rather than explain it publicly.