Create an Effective ISO 27001 SoA: Control Selection Guide

Creating an ISO 27001 Statement of Applicability (SoA): A practical, audit‑ready guide

The ISO 27001 Statement of Applicability (SoA) is a required ISMS document that lists Annex A controls, records whether each control is implemented, and explains the risk‑based reason for including or excluding it. This guide shows how the SoA connects your risk assessment to control choices, walks you through building and maintaining an audit‑ready SoA for ISO 27001:2022, and shares templates, examples, and automation options to speed the work. Many teams find it hard to turn a risk register into defensible control decisions and clear audit evidence — this article fixes that by covering scope definition, risk assessment best practices, control selection criteria, and ongoing maintenance. You’ll get a step‑by‑step process for SoA creation, example justification language, links to up‑to‑date templates for 2024, and practical tips for keeping the SoA current. We also highlight how AI‑assisted auditing can streamline mapping and justification, and where hosted builders can accelerate completion. Keywords such as SoA ISO 27001, Annex A controls, risk‑based control justification, and ISO 27001 SoA template 2024 are included to help you find and apply these concepts quickly.

What the ISO 27001 Statement of Applicability is — and why it matters

The Statement of Applicability (SoA) documents which Annex A controls apply to your ISMS, why each control is included or excluded, and the current implementation status. It serves as a control register and as audit evidence that ties risk‑treatment choices back to your ISMS scope and objectives — an essential part of certification and ongoing compliance. A clear SoA lets stakeholders and assessors see your risk‑based approach, trace control ownership, and confirm legal or contractual drivers were considered. Well‑written SoA content reduces audit friction and demonstrates governance, traceability, and alignment with ISO 27001:2022 — all critical when preparing for an external assessment.

Further research explores the techniques and documents commonly used to develop and maintain ISO 27001‑aligned systems.

Techniques for ISO 27001 ISMS Development and Documentation

We analyse the ISO 27001 standard to determine what techniques and documentation are necessary and instrumental to develop and document systems according to this standard. Based on these insights, we inspect a number of current security requirements engineering approaches to evaluate whether and to what extent these approaches support ISO 27001 system development and documentation.

Supporting the development and documentation of ISO 27001 information security management systems through security requirements engineering approaches, K Beckers, 2012

At Stratlane, we support teams through SoA preparation with AI‑assisted auditing tools and experienced practitioners who speed mapping and reduce rework. Our process complements internal risk workflows with structured readiness checks and expert review that preserve your risk‑based rationale while preparing evidence for assessors. That support is a natural next step once you have your SoA content drafted and want independent validation before formal certification.

How the SoA ties into ISO 27001:2022 and your ISMS

The SoA satisfies the ISO 27001 requirement to document selected controls and their justifications, linking clauses to implemented safeguards and risk‑treatment decisions. ISO 27001:2022 reorganized Annex A, so your SoA should reflect the updated set of controls (93 controls as revised) and show how each control maps to identified risks, objectives, or regulatory drivers. By referencing the ISMS scope, risk assessment outputs, and the risk treatment plan, the SoA explains whether risks were reduced or accepted and which controls provide mitigation. That makes the SoA a central document in your ISMS — connecting policies, procedures, the risk register, and management approvals.

Key components and practical benefits of an SoA

A compliant SoA includes, at minimum: control identifiers and titles, applicability and rationale, a clear justification or exclusion reason, implementation status, control owner, and last review date. Each field supports governance — justification links controls to risks, implementation status provides audit evidence, and owner fields assign accountability — so the SoA doubles as a concise management dashboard. The practical benefits are faster audits, clearer regulatory alignment, prioritized remediation, and stronger stakeholder assurance. A well‑structured SoA focuses resources on the highest residual risks and gives a defensible record explaining why controls were omitted or replaced.

Common SoA components include:

Control identifier and title: the Annex A control reference.
Applicability and justification: why a control applies or is excluded.
Implementation status and owner: current state and who’s responsible.

These elements make the SoA both a compliance artifact and an operational tool for ISMS governance. Next: how to write one.

How to write your ISO 27001 Statement of Applicability — step by step

Build an effective SoA by following a tight sequence: define the ISMS scope, run a risk assessment, pick controls for treatment, document justification for each decision, record implementation status and owners, and obtain management approval. This turns risk register outputs into control selections and produces the artifacts assessors expect. A methodical approach avoids ad‑hoc choices and ensures every inclusion or exclusion has a documented, risk‑based rationale. The steps below are ordered to deliver repeatable results and audit evidence that maps directly to ISO 27001 clauses and Annex A controls.

Academic work also highlights structured methods that extend risk management into full ISO 27001 compliance and documentation.

Structured Method for ISO 27001 ISMS Documentation & Compliance

In this chapter we present ISMS-CORAS, which is an extension of the CORAS method for risk management that supports the ISO 27001 standard. ISMS-CORAS comes with techniques and guidelines necessary for establishing an Information Security Management System (ISMS) compliance with the standard, as well as the artifacts that are needed for the required documentation.

ISMS-CORAS: A structured method for establishing an ISO 27001 compliant information security management system, K Beckers, 2014

Define the ISMS scope clearly and list included assets and boundaries.
Run a risk assessment using documented criteria and create a risk register.
Map risks to candidate Annex A controls and decide on treatment options.
Document justifications, update the SoA fields, and set review dates.
Obtain management approval and schedule regular SoA reviews.

This workflow gives structure and prepares you for the detailed tasks: scoping and running risk assessments that feed the SoA.

How to define your ISMS scope for SoA creation

Scope definition sets the context for which assets, processes, locations, and interfaces your SoA covers — and errors here cause misalignment between controls and real exposures. A solid scope lists business processes, supporting systems, physical sites, cloud services, and third‑party interfaces, and it clarifies inclusions and exclusions so control applicability is unambiguous. For multi‑site or hybrid environments, document boundaries per site or service and note where controls vary. Validate the scope against business objectives and contractual obligations to avoid surprises when auditors probe for missing controls.

Useful scope checks include asset inventories, business‑impact categories, and contractual or regulatory obligations. Correct scope definition makes the risk assessment more accurate and ensures the SoA reflects the true exposure profile for the area you intend to certify.

Steps for conducting a risk assessment that informs the SoA

The risk assessment produces the prioritized register entries that drive which Annex A controls you select and justify. Use a repeatable methodology and explicit impact/likelihood criteria. Typical steps: identify assets, analyse threats and vulnerabilities, estimate impact and likelihood, then calculate risk levels to decide which risks need treatment. Outputs should show residual risk after existing controls and list candidate controls addressing each risk — these form the basis for SoA justifications. Aligning your approach with ISO 27005 helps make the methodology defensible and consistent with best practice.

Below is an example mapping identified risks to controls, illustrating how risk outputs populate SoA entries.

Risk	Impact / Likelihood	Selected Control(s) / Treatment
Unauthorized access to customer data	High / Possible	Access control (A.9.1), MFA, privileged access reviews
Unpatched internet‑facing servers	High / Likely	Patch management (A.12.6), vulnerability scanning, compensating network controls
Third‑party data processing gap	Medium / Possible	Supplier security (A.15.1), contract clauses, periodic audits

That mapping shows how each risk links to Annex A controls and treatments — the core content you’ll record in the SoA. Well‑documented mappings create traceability from the risk register to each SoA line and let auditors follow the treatment logic.

How to select and justify Annex A controls in your SoA

Control selection must be risk‑based, evidence‑driven, and aligned with legal, contractual, or business requirements — not a checkbox exercise. Justifications should state the risk addressed, how the control mitigates it, any compensating measures, and the residual risk after treatment. Weak justifications are vague; strong ones reference a specific risk register item, the expected impact reduction, and how the control achieves that reduction. When excluding a control, document the analysis and any compensating controls that provide equivalent protection.

Typical criteria for selecting controls include:

Risk treatment need: severity and likelihood of related risks.
Legal or contractual obligations that require a control.
Operational or business drivers that demand the safeguard.

These criteria help you make defensible decisions and prepare justification language auditors respect.

Decision criteria for choosing Annex A controls

Combine risk linkage, compliance drivers, and business needs into a simple checklist for each Annex A control. Start with the risk register: if a control materially reduces a high or medium risk, it’s applicable. Next, check legal or contractual obligations that mandate a safeguard. Consider existing compensating controls and document them. A decision‑tree approach works well: if a risk exists and the control reduces it materially, mark applicable; if a contractual obligation requires it, mark applicable; otherwise document exclusion with rationale.

A concise checklist helps different teams make consistent decisions and produces uniform justifications across the SoA.

How to write risk‑based justifications for included and excluded controls

Strong justifications include three parts: the risk or requirement, the chosen control (or compensating measure), and the residual risk or reason for exclusion. Use ready‑to‑use templates to capture these elements and keep entries consistent. For example, instead of “Not applicable,” write: “Control A.B.C is excluded because compensating control X provides equivalent mitigation for R‑12; residual risk is assessed as low and accepted by the risk owner.” That links to the risk register, cites the compensating control, and records acceptance or planned treatment.

Some approaches also incorporate economic justification — weighing control costs against expected risk reduction in the treatment plan.

Economic Justification of ISO 27001 Controls & Risk Treatment

ISAMM uses ALE to form a return of investment approach and economic justification of controls under considerations of the risk treatment plan. ISAMM provides supporting tools and is

Current challenges in information security risk management, S Fenz, 2014

Below is a compact EAV table you can copy into an SoA to standardize justification entries.

Control ID	Applicability / Justification Type	Value (Risk linkage / Reason)
A.9.1	Applicable / Risk treatment	Addresses R-07 (unauthorized access); implements role‑based access and MFA; owner: IT Security
A.12.6	Applicable / Operational requirement	Addresses R-03 (vulnerability exposure); patch cadence and scanning required
A.15.2	Not applicable / Contractual reason	No third‑party processing of personal data in scope; evidence: supplier contracts reviewed

Standardized entries like these reduce reviewer time and create a repeatable SoA structure auditors can follow. Stratlane’s AI‑assisted control mapping can suggest candidate controls and draft justifications to speed population of such tables — always paired with human review before approval to preserve defensibility.

Where to find ISO 27001 SoA templates and examples for 2024

Up‑to‑date SoA templates are available from standards guidance, certification bodies, auditor toolkits, and vendor builders. Prioritise templates that match ISO 27001:2022 Annex A and include fields for justification, owner, and review dates. Interactive SoA builders and downloadable templates both have value: offline templates suit hands‑on editing, while builders enforce consistency and preserve version history. Look for templates that include an implementation status taxonomy (Implemented / Partially implemented / Planned / Not applicable) and a field to link each line to a risk register ID for traceability.

The table below lists essential SoA template fields and example values to help customise for 2024 requirements.

Template Field	Purpose	Example / Notes
Control ID & Title	Identifies Annex A control	A.9.1 — Access control policy
Applicability / Justification	Records risk linkage or exclusion reason	Applicable — mitigates R-07 (unauthorized access)
Implementation Status	Shows current deployment level	Implemented / Partially implemented / Planned
Control Owner	Accountability for the control	IT Security Manager
Last Reviewed	Audit‑readiness and currency	2024-10-01 (link to review notes)

Stratlane offers hosted templates, interactive SoA builders, and downloadable examples tailored to ISO 27001:2022 to help teams accelerate SoA completion. Our service pairs AI‑driven suggestions with expert review — book a demo or request a quote to see how a hosted builder would fit your certification workflow. Using these tools reduces formatting work and improves consistency across multiple SoAs.

Essential fields every ISO 27001 SoA template should include

At minimum: control ID, control title, applicability, justification, implementation status, control owner, last review date, and links to the risk register and evidence items. Each field serves an audit purpose: identification, rationale, operational status, accountability, and traceability. Templates should also include metadata for version control and approver signatures to meet governance requirements. Including these fields avoids common audit findings about missing justification or unclear ownership.

Standardising fields makes cross‑referencing easier and simplifies maintenance — which leads into how to tailor templates to your organisation.

How to customise SoA templates for your organisation

Map template fields to organisational roles, asset inventories, and applicable regulations (privacy or sector rules), and add vendor‑specific tags for third‑party relationships. SMEs can use simplified templates with aggregated owners and fewer status categories; larger organisations should include site/service‑specific applicability columns and regulatory mapping fields. Keep version control and a change log so updates are transparent and auditable. Always preserve the ability to link each SoA line to a risk register entry and to evidence artifacts for audit verification.

Customising templates this way keeps the SoA aligned with operational reality and supports consistent decision‑making during reviews and audits.

How Stratlane’s AI‑driven auditing speeds SoA creation

Stratlane combines AI‑assisted auditing tools with experienced industry experts to streamline SoA creation, control mapping, and audit preparation — reducing rework and controlling costs. Our tools can analyse a risk register, suggest likely Annex A controls, draft justification language, and generate an implementation‑status first pass of the SoA for human review. Experienced auditors then verify AI outputs, refine evidence links, and guide management approval. This hybrid approach improves consistency and accelerates readiness checks. Stratlane is an accredited certification body operating in over 27 countries and provides support including FAQs, training, and a certificate database to help teams manage post‑certification obligations.

That commercial offering helps organisations accelerate SoA completion without sacrificing the defensibility of risk‑based decisions, aligning AI efficiency with auditor judgement during preparation.

Benefits of AI‑powered risk assessment and control mapping

AI tools speed up risk→control mapping, standardise justification phrasing, and improve traceability between risks, controls, and evidence — reducing manual mistakes and inconsistent language that can slow auditors. By suggesting candidate controls from your documented risks, AI shortens the time to populate SoA fields and flags missing evidence items for collection. The traceability an AI generates provides an audit trail that supports consistent responses to assessor queries. For example, AI can cut initial mapping time for a medium‑sized risk register from days to hours by proposing candidates and drafting justification text for risk owners to review.

These efficiencies free internal teams to focus on remediation and governance rather than repetitive documentation, while keeping a human‑in‑the‑loop for accountability and final sign‑off.

How AI can automate control justification and boost audit readiness

A practical workflow is: upload the risk register to the AI SoA builder → AI suggests controls and drafts justifications → control owners and auditors review and edit → finalise the SoA with version history and evidence links. AI can propose compensating controls, suggest wording that cites risk IDs, and surface regulatory drivers that affect applicability decisions. Human verification remains essential to confirm context and accept wording, but AI drafts provide a consistent baseline that speeds review cycles. Built‑in governance notes and approval workflows give the audit trail assessors expect.

This hybrid model balances automation with necessary human oversight, improving both efficiency and defensibility as you prepare for certification.

How to maintain and review your ISO 27001 Statement of Applicability

Maintaining the SoA requires scheduled baseline reviews, ad‑hoc updates after incidents or scope changes, and strict version control so past decisions remain traceable. Review the SoA at least annually as part of ISMS management review and update it immediately after significant changes — new services, major incidents, or regulatory shifts. Linking SoA entries to risk register items and evidence artifacts makes updates straightforward: changes in the register propagate into the SoA fields. Record approvals for each change with owner sign‑off and version history to support audit questions about past decisions.

Automated tooling can surface items that need review by scanning evidence links, policy changes, or supplier updates, reducing manual effort and increasing responsiveness. Regular maintenance keeps the SoA a living compliance artifact and prevents last‑minute audit scrambles.

Recommended frequency and process for SoA review

We recommend an annual baseline review plus ad‑hoc updates triggered by incidents, scope changes, or new regulatory requirements — balancing governance with agility. Baseline reviews should involve risk owners, process owners, and ISMS leadership to validate statuses and justifications. Ad‑hoc reviews should follow a documented workflow: identify the trigger → assess impact on SoA entries → update justifications and evidence links → obtain owner and management approvals → publish the new version. Using a checklist for each review ensures consistent coverage of ownership, evidence sufficiency, and control effectiveness.

Clear role definitions and approval steps speed reviews and reduce auditor time spent verifying change history during assessments.

Annual Baseline Review: Management‑led validation of all SoA lines.
Incident‑Driven Update: Triggered when security incidents change risk ratings.
Scope‑Change Update: Required when services, locations, or assets are added or removed.

These routines, combined with version control and owner sign‑offs, keep the SoA current, defensible, and aligned with the ISMS.

Change Type	Typical Trigger	Required Action
Annual review	Scheduled management review	Validate entries, update statuses, re‑approve
Incident response	Security incident logged	Reassess affected risks, update justifications
Scope change	New service/location added	Add/remove controls, update owners, document rationale

Frequently Asked Questions

What role does the ISO 27001 Statement of Applicability play in risk management?

The SoA documents which controls apply to your ISMS and links identified risks to specific controls. It explains why controls are included or excluded and provides a clear reference for stakeholders and assessors to see how risks are managed and mitigated. In short, the SoA makes your risk‑treatment decisions visible and verifiable.

How often should the Statement of Applicability be reviewed and updated?

Review the SoA at least annually as part of your ISMS management review, and update it whenever significant changes occur — new services, incidents that change risk ratings, or regulatory updates. Regular reviews keep the SoA accurate and useful for audit and governance.

What common challenges do organisations face when creating an SoA?

Common challenges include translating risk assessments into clear control decisions, ensuring complete coverage of applicable controls, and keeping documentation audit‑ready. Organisations also struggle to keep the SoA aligned with evolving regulations and operational changes. Structured methods and the right tools can dramatically reduce these issues.

Can AI tools help create the Statement of Applicability?

Yes. AI can help by suggesting control mappings, drafting justification language, and flagging missing evidence. These drafts speed the initial work, but human review remains essential to confirm accuracy and context. The best results come from a hybrid approach: AI drafts plus expert validation.

Why is control justification important in the SoA?

Justification explains why a control is included or excluded and links that decision back to identified risks or requirements. Strong justifications make the SoA defensible during audits by showing decisions are based on a documented risk assessment and legal or contractual obligations.

How can organisations ensure their SoA stays compliant with ISO 27001:2022?

Keep the SoA current by performing annual reviews, updating it after incidents or scope changes, and linking every justification to a risk register entry and evidence. Use templates aligned with ISO 27001:2022 and invest in ongoing training for staff involved in SoA maintenance to preserve compliance.

Conclusion

A clear, well‑maintained Statement of Applicability is essential for ISO 27001 compliance and practical risk management — it ties controls directly to identified risks. Using structured methods and AI‑assisted tools can speed the work while preserving defensible, human‑approved decisions. Regular reviews and good version control keep the SoA relevant as your organisation and its risks change. Start improving your SoA process today by exploring the templates and tools we offer to help teams achieve audit‑ready documentation.