|

ISO/IEC 27001:2022 SoA Made Practical: How to Justify, Control, and Apply With Confidence

ByInnoVirtuoso

If you’ve ever stared at a blank Statement of Applicability (SoA) and wondered where to start, you’re not alone. The SoA is mandatory in ISO/IEC 27001, yet many organizations treat it like an afterthought—a checklist to appease auditors rather than a strategic map for security.

Here’s the truth: when you build the SoA the right way, it becomes the most useful, living document in your ISMS. It helps you explain what you secure, why you secure it, and how you’ll keep improving. In this guide, I’ll show you how to select, justify, and document the right controls in ISO/IEC 27001:2022—from first principles to audit-ready execution.

What is the Statement of Applicability (SoA) and Why It Matters

Let’s start simple. The SoA is your organization’s formal register of the security controls from Annex A of ISO/IEC 27001:2022. It states: – Which controls you’ve selected. – Why you’ve selected—or excluded—them. – How far along you are in implementing them. – Where evidence of implementation lives.

Think of it as the executive summary of your security strategy. The SoA is not just for auditors; it’s for your leadership, your engineers, and anyone who needs clarity on “what good looks like” in your ISMS. Here’s why that matters: when your SoA reflects real risks, real obligations, and real operations, it helps everyone make consistent, risk-aware decisions.

Critically, the SoA ties together your risk assessment, legal and contractual requirements, and your current capabilities. It proves that your control selection is not random—it’s justified, proportional, and aligned to what your business actually does. The standard requires it; your credibility depends on it.

Want to try it yourself—Check it on Amazon.

ISO/IEC 27001:2022 and 27002: What Changed and What It Means for Your SoA

ISO/IEC 27001:2022 and ISO/IEC 27002:2022 streamlined the control set from 114 to 93 controls, grouped into four themes: – Organizational – People – Physical – Technological

This matters because your SoA now maps to a more modern set of controls that reflect cloud, remote work, and evolving threats. New controls include threat intelligence, cloud security, business continuity for ICT, and physical monitoring, among others.

Useful references for context: – ISO’s overview of 27001 requirements: ISO/IEC 27001 — Information security management systems – Details on the updated control set: ISO/IEC 27002:2022 – Related frameworks for mapping or inspiration: NIST SP 800-53 Rev. 5 and the NIST Cybersecurity Framework

If you’re transitioning from the 2013 version, avoid a one-to-one migration mindset. Instead, re-run your risk assessment, then select controls based on today’s threats, your actual architecture, and new obligations.

The Three Pillars of a High-Value SoA

Use this mental model to shape every line of your SoA: 1. Justify: Every control should trace back to an explicit reason—risk, regulation, contract, or business need. 2. Control: Your SoA should state the control’s objective, scope, and owner, not just a control ID. 3. Apply: Prove implementation with references to policies, procedures, and evidence; note status and timelines.

When these pillars are in place, your SoA becomes actionable. It guides projects, supports audits, and prevents “checkbox security.”

Step-by-Step: How to Build an ISO/IEC 27001:2022 SoA That Works

Follow this flow for clarity and speed.

1) Define context and scope
– Document internal and external issues, interested parties, and ISMS scope.
– Be crisp: include business units, processes, systems, and locations under the ISMS.

2) Identify requirements
– List legal, regulatory, and contractual obligations: data protection, industry-specific rules, SLAs, customer security clauses.
– Record who these obligations apply to and how they constrain design.

3) Do a risk assessment that informs control selection
– Use a recognized approach (qualitative or quantitative) and define criteria.
– Identify threats, vulnerabilities, likelihood, impact, and risk owners.
– Set your risk acceptance criteria.

4) Map risks and requirements to controls
– For each significant risk or obligation, identify one or more Annex A controls that mitigate or fulfill it.
– Don’t over-control; aim for sufficiency.

5) Decide inclusion or exclusion with solid justification
– Include controls when risks require them or when obligations demand them.
– Exclude controls with a clear rationale (e.g., “No on-prem facilities; physical equipment security control A.7.9 not applicable”).
– Document compensating controls if excluding something common or expected.

6) Record implementation status and evidence
– For each control, note: implemented, partially implemented, or planned.
– Link to evidence: policies, standards, procedures, configurations, logs, tickets, training records.

7) Assign ownership and set review cadence
– Give each control an owner.
– Define how often you’ll review the SoA—quarterly at minimum, or event-driven for major changes.

8) Version control and approval
– Keep revision history, change notes, and approvals.
– Treat your SoA like a living asset, not a static artifact.

Ready to upgrade—Shop on Amazon.

How to Justify Inclusion and Exclusion (With Examples)

Weak justifications undermine trust. Strong justifications build it. Here’s how to write them well.

  • Bad inclusion: “Included to be safe.”
  • Good inclusion: “Included due to high risk of credential stuffing on our public login; mitigates risk R-12 with MFA and adaptive challenge under A.8.2 (Identity management).”
  • Bad exclusion: “Not applicable.”
  • Good exclusion: “Excluded A.7.13 (Secure disposal of media) because we operate 100% cloud with provider-managed media destruction; compensating controls include encryption at rest (A.8.24) and contractual clauses with CSP for certified destruction.”
  • Bad status: “Implemented.”
  • Good status: “Implemented; evidence: IAM policy v3.2, Okta MFA enforcement screenshot, SIEM report showing weekly anomalies; owner: Head of Platform; last reviewed: 2025-05-20.”

Tip: Always point to a risk ID, requirement reference, or asset inventory entry. When an auditor asks “why this control?” you should be able to answer in one sentence plus a link to evidence.

Build Traceability That Auditors (and Engineers) Love

Traceability is what turns your SoA into a decision system: – Each control links to risk IDs, requirement IDs, and assets/systems in scope. – Each risk links back to one or more controls and treatment plans. – Evidence links point to change tickets, architecture diagrams, tool configs, and training records.

Use simple IDs and keep them consistent across your Risk Register, SoA, and treatment plans. This allows quick pivoting in audits and simplifies internal reviews.

For risk methodology inspiration, see ENISA’s risk management guidance and ISO’s risk standard ISO/IEC 27005.

A Realistic SoA Mini-Snapshot (SaaS Example)

Imagine a B2B SaaS company hosting multi-tenant applications on a major cloud provider.

  • Context and scope
  • ISMS includes product engineering, platform operations, and customer support for the main SaaS product; excludes marketing site and internal HR tools for now.
  • Key risks driving controls
  • Account takeover risk on customer-facing login (R-12).
  • Data exfiltration via compromised API keys (R-19).
  • Ransomware risk on build pipeline artifacts (R-27).
  • Availability risk for critical APIs with strict SLAs (R-33).
  • Regulatory obligations: privacy laws, industry SLAs, and customer security addenda.
  • Selected controls (illustrative snippets)
  • A.8.2 Identity management: Included to address R-12; MFA enforced for all users; SSO for admins; evidence in IAM policy and IdP configuration.
  • A.8.23 Web filtering: Included due to threat intel on phishing and malicious sites affecting engineers; evidence in secure browsing standard and proxy policy.
  • A.5.30 ICT readiness for business continuity: Included to meet RTO/RPO objectives; ties to DR runbooks, failover tests, and cloud region strategy; evidence in latest failover test report.
  • A.5.7 Threat intelligence: Included to improve detection/prevention of credential stuffing and supply chain threats; evidence includes subscription to curated feeds and SIEM use cases.
  • A.7.13 Secure disposal of media: Excluded due to cloud-only model; mitigated by encryption at rest (A.8.24) and CSP-certified disposal; justification recorded.

Note how each line answers: why included or excluded, where evidence lives, who owns it, and which risks or requirements it addresses. That’s the difference between a perfunctory SoA and a powerful one.

See today’s price and details—See price on Amazon.

What Auditors Expect From Your SoA

Auditors aren’t hunting for gotchas; they’re looking for coherence. Here’s what they expect: – Completeness: All Annex A controls considered, with clear in/out decisions. – Consistency: SoA aligns with your risk register, policies, and actual practice. – Evidence: Implementation claims link to objective evidence. – Recency: Document is current, versioned, and recently reviewed. – Proportionality: Controls match risk levels and obligations; no obvious gaps.

Many certification bodies align with guidance like IAF’s documents for applying ISO/IEC 27001; see the IAF site for context on ISO audit practices: IAF documents. If auditors question an exclusion, be ready to show compensating controls and why the net risk is acceptable.

Governance: Keep Your SoA Alive, Not Archived

Treat your SoA as a living asset: – Review cadence: Quarterly reviews, plus trigger-based updates (new product features, architecture changes, customer obligations, incidents). – Change control: Log changes with reason, approver, and date. – Metrics that matter:
– Percent of controls implemented vs. planned.
– Mean time to implement planned controls.
– Number of controls with stale evidence (>6 months).
– Coverage of high-risk scenarios vs. accepted risk.

  • Cross-functional ownership:
  • Security steers, but engineering, IT, legal, and compliance contribute.
  • Control owners attest to effectiveness and update evidence links.

If you prefer a field-tested template, support our work and Buy on Amazon.

Practical Writing Tips for Strong SoA Entries

  • Write for non-specialists: Use plain language and avoid jargon where possible.
  • Make justifications one-liners: “Included due to X risk and Y obligation; mitigates Z; evidence here.”
  • Use active voice: “We enforce,” “We test,” “We review.”
  • Set owners and due dates: Accountability accelerates implementation.
  • Avoid copy-paste from 2013-era SoAs: The 2022 controls are reorganized; start fresh based on your current risk picture.

What to Look For in an SoA Guide or Template (Buying Tips)

Choosing a guide or template? Use this checklist so you don’t buy busywork: – ISO/IEC 27001:2022 alignment: Ensure Annex A mapping matches the 93-controls set and four themes. – Built-in traceability: Risk IDs, requirement IDs, evidence fields, and owners should be native, not add-ons. – Clear inclusion/exclusion examples: Look for realistic, audit-tested wording. – Implementation status and evidence fields: Save time by standardizing how you prove controls. – Versioning and workflow: Templates with change logs and review dates reduce audit friction. – Cross-framework mapping: Helpful if you also reference CIS Controls v8 or NIST SP 800-53 in customer responses.

Compare options and previews—View on Amazon.

Nice-to-Haves

  • Example SoA snippets for common environments (SaaS, fintech, healthcare).
  • Embedded guidance for newer controls like threat intel, cloud security, and ICT continuity.
  • Links to policy/evidence placeholders to reduce hunting.

Common Mistakes That Derail SoAs (and How to Avoid Them)

  • Treating the SoA like a static checklist
  • Fix: Review quarterly and after material changes; assign an owner to each control.
  • Weak or circular justifications
  • Fix: Tie every justification to a risk ID, legal requirement, or contract clause.
  • Over-engineering controls for low risks
  • Fix: Use risk acceptance criteria to right-size your control set.
  • Missing evidence or stale links
  • Fix: Centralize evidence and add “last verified” dates; automate link checks where possible.
  • Excluding common controls without compensating measures
  • Fix: If you exclude something most peers include, explain the context and show compensations.

Integrating the SoA With Your ISMS Artifacts

Your SoA gains power when integrated with: – Risk Register: Control selection flows from risks; risks point to treatment plans. – Asset Inventory: Controls cover specific systems, data classes, and processes. – Policies and Standards: SoA references the documents that define “how.” – Procedures and Runbooks: Evidence of “do” lives here—tickets, reports, configs, dashboards. – Audit Trails: You can demonstrate what changed, when, and why.

This integration reduces audit time, improves transparency, and accelerates onboarding of new team members.

Want to try it yourself—Check it on Amazon.

Advanced Tips: Make Your SoA Operationally Useful

  • Link to live dashboards: Point certain controls (like vulnerability management or backup status) to read-only views.
  • Use tags: Tag controls by product line, environment (prod/dev), or data classification to filter quickly during audits.
  • Create “control stories”: For complex areas (e.g., identity), write a short narrative that ties multiple controls together.
  • Run SoA drills: Quarterly, pick three controls at random and walk through evidence as if in an audit.

These practices move your SoA from documentation to day-to-day decision support.

Frequently Asked Questions About ISO/IEC 27001:2022 SoAs

Q: Is the SoA mandatory for ISO/IEC 27001 certification?
A: Yes. The SoA is required and must cover all Annex A controls with inclusion/exclusion decisions, justifications, implementation status, and references to evidence. See ISO’s overview here: ISO/IEC 27001 — Information security management systems.

Q: How do I justify excluding a control without raising auditor concerns?
A: Be specific. Reference your scope, architecture, and risk profile. Provide compensating controls where relevant and show why the residual risk is acceptable based on your risk criteria.

Q: What’s the difference between the SoA and the Risk Treatment Plan?
A: The SoA lists control decisions, status, and evidence; the Risk Treatment Plan documents how you’ll treat specific risks, timelines, and responsibilities. They should cross-reference each other.

Q: How often should we update the SoA?
A: At least quarterly, and whenever there’s a material change—new product release, major incident, customer requirement change, or architectural shift.

Q: Do we need to implement every control in Annex A?
A: No. You must consider every control, but you only implement those applicable to your risks and obligations. Well-justified exclusions are acceptable.

Q: How does ISO/IEC 27002:2022 relate to the SoA?
A: ISO/IEC 27002 provides detailed guidance for implementing controls. You use 27001 to define the management system and SoA requirements, and 27002 to inform how you implement.

Q: Can the SoA be stored in a GRC tool?
A: Yes. A GRC or ISMS platform can improve traceability, evidence management, and version control. Spreadsheets work too, but make sure they’re well-structured and versioned.

Q: What evidence types do auditors prefer?
A: Policies and standards, procedure documents, system configurations, access control reports, logs, tickets/change records, training records, and test reports (e.g., DR tests, incident response exercises).

Q: How do we handle shared responsibility in the cloud?
A: Document the split. For each control, state whether you or your cloud/service provider is primarily responsible and link to provider attestations, contracts, or settings as evidence.

Q: Where can I see examples of good control mappings?
A: Review recognized frameworks like NIST SP 800-53 and CIS Controls v8 to understand common control families and objectives, then map them to 27001 Annex A.

Final Takeaway

A great SoA isn’t longer—it’s clearer. If you justify each control with a real reason, connect it to evidence, and keep it current, your SoA becomes a strategic asset that powers audits, guides roadmaps, and earns stakeholder trust. Start by linking risks to controls, write crisp justifications, assign owners, and review quarterly. If this helped, consider subscribing for more practical ISO/IEC 27001 guides and field-tested templates to keep your ISMS both compliant and genuinely effective.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring! 

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

Read more related Articles at InnoVirtuoso

InnoVirtuoso

Hello there! I'm passionate content writer navigating the digital landscape. With a deep love for words and an insatiable curiosity about technology.

With 10 years of experience in IT field, I write mostly about emerging tech, sharing news, informational articles and covering other topics I find interesting.

Let's craft the future of content together – one word at a time!

Browse InnoVirtuoso for more!