Bottom Line Up Front
Your ISO 27001 Statement of Applicability (SoA) is the single document every auditor opens first — and the one most teams rush through at the worst possible time. Done right, it’s a clear, defensible map of which Annex A controls apply to your organization, why, and how you’ve implemented them. Done wrong, it’s a 93-row checkbox exercise that falls apart under the first pointed question.
This guide walks you through building a legitimate SoA from your risk assessment through auditor-ready documentation. If you’ve already completed your risk assessment and risk treatment plan, expect 8-15 hours spread across one to two weeks. If you’re starting from scratch, budget two to three weeks once your risk register is solid — because the SoA can’t be done well in isolation from it.
Before You Start
Prerequisites
You need three things in hand before you open a blank SoA template: a completed risk assessment, a risk treatment plan, and a working knowledge of Annex A (the current version’s control set, organized into organizational, people, physical, and technological categories). You also need your ISMS scope statement finalized — the SoA only makes sense relative to a defined scope.
A spreadsheet or your GRC platform both work fine here. What matters isn’t the tool — it’s the rigor behind each justification.
Stakeholders to Involve
- ISMS owner or CISO — drives the document and owns final sign-off
- IT/security engineering — confirms technical controls are actually implemented, not aspirational
- Legal/compliance — flags contractual and regulatory obligations (customer contracts, HIPAA, GDPR, PCI DSS) that mandate specific controls
- HR — weighs in on people controls (background checks, disciplinary processes, termination procedures)
- Executive sponsor — approves risk acceptance decisions and resourcing for excluded-but-required controls
Scope
This guide covers building the SoA itself — not conducting your risk assessment from zero (that’s a separate exercise, though we reference it heavily) and not the broader ISMS documentation set. Think of the SoA as the bridge between your risk analysis and your actual control implementation evidence.
Frameworks This Satisfies
The SoA is an ISO 27001-specific deliverable — it’s explicitly required by the standard and is the first document most certification body auditors request during Stage 1. It also does double duty: the control justification work overlaps heavily with SOC 2 control mapping and NIST CSF profile development, so if you’re managing multiple frameworks simultaneously, this exercise isn’t wasted effort.
Step-by-Step Process
Step 1: Pull Your Finalized Risk Treatment Plan
What to do: Export your risk register with treatment decisions clearly marked — treat, accept, transfer, or avoid — for every identified risk.
Why it matters: Your SoA justifications must trace back to actual risks, not generic boilerplate. Auditors increasingly test this linkage directly, asking “show me the risk that drove this control decision.”
What can go wrong: Teams often write risk assessments and SoAs in parallel, disconnected from each other. If your risk register says “ransomware” is a high risk but your SoA doesn’t reference backup or malware controls, that’s an immediate nonconformity.
Time estimate: 1 hour if your risk register is already finalized.
Step 2: Build Your Control-by-Control Working Sheet
What to do: Create a row for every control in Annex A — all of them, regardless of whether you expect to include or exclude it. Columns should include: Control ID, Control name, Applicable (Yes/No), Justification, Implementation status, and Reference to evidence/policy.
Why it matters: Starting with the full list — rather than only the controls you plan to include — forces you to make a deliberate decision on every single control. Auditors specifically check for this completeness.
What can go wrong: Copy-pasting a template SoA from another organization and lightly editing it. Auditors have seen the same generic templates hundreds of times; justifications that don’t reflect your actual environment are an instant red flag.
Time estimate: 1-2 hours to set up the structure.
Step 3: Determine Applicability for Each Control
What to do: For each control, decide: does this apply to your organization? Base this on your risk assessment results, legal/regulatory/contractual requirements, and business context — not on how hard the control is to implement.
Why it matters: This is the heart of the SoA. “Applicable” doesn’t mean “we do this perfectly” — it means this control is relevant to managing your risks. “Not applicable” needs a real reason: you don’t develop software in-house, you have no physical offices, you don’t process payment card data.
What can go wrong: Marking controls “not applicable” because they’re inconvenient or costly, rather than because they’re genuinely irrelevant. Example: excluding secure development controls because “we’re mostly no-code” when you actually maintain custom integrations — that’s a justification that won’t survive scrutiny.
Compliance checkpoint: A reasonable baseline for most organizations is excluding somewhere between 5-15% of controls, not 40%. If you’re excluding large blocks, revisit your scoping.
Time estimate: 3-5 hours for a mid-sized organization (50-250 employees).
Step 4: Write Specific, Defensible Justifications
What to do: For every control, write one to three sentences explaining why it’s applicable (tied to risk ID, legal requirement, or contractual obligation) or why it’s excluded (tied to scope boundaries or business model).
Why it matters: Generic justifications like “best practice” or “industry standard” tell an auditor nothing. Specific justifications like “Applicable — mitigates Risk R-014 (unauthorized production access); required under customer MSA Section 8.2” demonstrate real risk-based thinking.
What can go wrong: Justification fatigue sets in around control 60 of 93, and quality drops. Budget real time for this step rather than rushing the back half of Annex A.
Time estimate: 3-4 hours.
Step 5: Document Implementation Status and Evidence Links
What to do: For each applicable control, note whether it’s fully implemented, partially implemented, or planned — and link to the specific policy, procedure, or technical configuration that satisfies it.
Why it matters: This is where the SoA stops being theoretical and becomes operational. Your auditor will sample controls and expect you to produce the linked evidence on the spot.
What can go wrong: Marking controls “implemented” when they’re actually “we have a policy document nobody follows.” Implementation status should reflect operating reality, not intent.
Time estimate: 2-3 hours, assuming your control implementation work is largely done.
Step 6: Get Formal Management Approval
What to do: Have your executive sponsor or management team formally review and approve the SoA, including explicit acceptance of residual risk for any excluded controls.
Why it matters: ISO 27001 requires top management to own risk acceptance decisions — this isn’t a rubber stamp, and auditors will ask who approved it and when.
What can go wrong: Skipping documented approval entirely, or having it approved by someone without actual authority to accept organizational risk.
Time estimate: 1-2 hours including meeting time.
Verification and Evidence
Before you consider the SoA complete, run it through these checks:
- Completeness check: Every single Annex A control has an applicability decision — no blanks, no “TBD.”
- Traceability check: Every “applicable” justification references a specific risk ID or external requirement; every “not applicable” has a defensible business reason.
- Evidence check: Pick 10 controls at random and confirm you can produce the linked policy or technical evidence within five minutes.
- Consistency check: Cross-reference your SoA against your risk treatment plan — every treated risk should map to at least one applicable control.
For your compliance file, collect: the signed/approved SoA document, the risk assessment it’s derived from, meeting minutes from the management approval, and a version history showing when and why the SoA changed.
Your auditor will want to see the SoA alongside your risk treatment plan side by side, and will likely trace two or three specific risks all the way through to control implementation evidence. They’re testing the chain, not just the document.
Common Mistakes
| Mistake | Why It Happens | Fix |
|---|---|---|
| Copying a template SoA wholesale | Time pressure, unfamiliarity with Annex A | Quick fix: rewrite justifications in your own words referencing actual risks |
| Marking too many controls “not applicable” | Avoiding implementation work | Architectural fix: revisit scope definition and risk assessment honestly |
| Disconnecting SoA from risk register | Built by different people, at different times | Architectural fix: assign one owner responsible for both documents |
| Vague justifications (“industry best practice”) | Justification fatigue, lack of specificity training | Quick fix: require every justification to cite a risk ID or requirement |
| Never updating after changes | Treating SoA as a one-time deliverable | Fix: build SoA review into your change management process |
Maintaining What You Built
The SoA isn’t a document you file away after certification — it’s a living artifact that should change whenever your risk picture changes.
Review cadence: Reassess the full SoA at least annually, tied to your internal audit and management review cycle.
Change triggers: Update it whenever you adopt new technology, enter new markets with new regulatory obligations, experience a security incident, or complete your annual risk assessment refresh.
Documentation maintenance: Keep a clear version history with dates, what changed, and who approved it. During surveillance audits, your certification body will specifically check whether your SoA reflects your current environment — not the one that existed at initial certification.
FAQ
Does every organization need to include all 93-ish Annex A controls?
No — the SoA is explicitly designed to let you exclude controls that don’t apply to your risk profile and scope. What matters is that every exclusion is justified by genuine business reasoning, not convenience. Auditors expect thoughtful tailoring, not blanket inclusion or exclusion.
How long should our SoA document be?
Length varies, but expect one row per control with concise, specific justifications — typically a document in the range of 15-30 pages when formatted clearly. Padding it with generic text doesn’t help; clarity and traceability matter far more than page count.
Can we use a spreadsheet instead of a formal document?
Yes — many organizations maintain their SoA as a spreadsheet or within a GRC platform, and auditors accept this as long as it’s version-controlled and formally approved. The format matters less than the rigor and traceability behind it.
Who should actually write the justifications?
Whoever owns your ISMS should draft them, but with direct input from the engineering, legal, and HR stakeholders who understand the operational reality of each control area. Justifications written in isolation by one compliance person tend to be generic and don’t survive audit scrutiny.
What happens if our auditor disagrees with an exclusion?
They’ll raise it as a finding or ask for additional justification before Stage 2 certification proceeds. This is normal and usually resolved by strengthening your written rationale or, if they’re right, reclassifying the control as applicable.
Conclusion
A strong Statement of Applicability isn’t about checking 93 boxes — it’s about demonstrating that your security program is driven by actual risk, not by a template someone downloaded the night before an audit. Build it from your risk assessment, keep it traceable, and treat it as a living document rather than a one-time deliverable, and your ISO 27001 certification process gets measurably smoother.
If this process feels like a lot to manage alongside everything else on your plate — risk assessments, policy writing, evidence collection, audit prep — you’re not wrong, and you don’t have to do it alone. SecureSystems.com helps startups, SMBs, and scaling teams get audit-ready without building an internal 20-person security function first, with clear timelines and transparent pricing for ISO 27001 implementation, SOC 2 readiness, HIPAA compliance, and ongoing security program management. Book a free compliance assessment and we’ll tell you exactly where your SoA — and the rest of your ISMS — stands today.
