Practical toolGlobalISO/IEC 27001

ISO/IEC 27001 Statement of Applicability Evidence Workflow

The records the controls the needs, why they are included, whether they are implemented, and why any controls are excluded.

Use it to connect risk-treatment decisions with operating evidence. Include every necessary control, including controls from sources beyond .

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

Under , build the after risk treatment identifies the controls necessary for the documented scope. requires the necessary controls, inclusion justifications, whether those controls are implemented, and reasons for excluding controls. It does not prescribe a form or require evidence files to sit inside the SoA. Use evidence links as an operating convention so each decision can be checked against current records.

Section 1

What must the SoA decision record explain?

The workflow begins after risk treatment identifies necessary controls. For each necessary control, record why it is included and whether it is implemented. Compare that set with to check for omissions, then justify every Annex A control excluded from the necessary-control set.

Keep organization-designed and other-source controls in the same decision record. is a reference set of possible controls, not an exhaustive catalog. A necessary legal, contractual, technical, or organization-designed control still belongs in the even when it has no Annex A identifier.

is an ISO/IEC 27001 conformity requirement. ISO/IEC 27002 provides control guidance, and ISO/IEC 27005 provides risk-management guidance. The extra owner, evidence-pointer, workflow-status, and review fields on this page are Sorena's practical recommendations rather than required fields.

  • Scope and input: identify the covered service, site, system, or process and link the risk assessment or applicable requirement.
  • Decision: record the treatment option, every necessary control and its source, the inclusion rationale, whether it is implemented, and each exclusion rationale.
  • Accountability: assign the internal owner for implementation and evidence, while keeping risk-owner approval of the treatment plan and residual-risk acceptance separately traceable.
  • Output: publish a controlled version and link each entry to the current treatment action, evidence, exception, and review trigger.
Section 2

How should each SoA entry point to operating evidence?

ISO/IEC 27001 requires enough to show that planned processes were carried out and to preserve monitoring results. It does not mandate one evidence format. A useful pointer identifies the authoritative system, record type, owner, period, and latest result. A policy can show design intent; a dated access review, configuration sample, restore test, supplier review, or monitoring result can show operation.

If evidence is missing or a control failed, keep the status honest and link the treatment action, exception, nonconformity, corrective action, or accepted residual risk. Do not mark a necessary control implemented because work is scheduled or a policy exists; record planned, partial, blocked, or failed detail alongside the required implemented-or-not answer.

  • Design evidence: policy, procedure, architecture, baseline, role, contract, or control description.
  • Operating evidence: dated transaction, review, test, log, ticket, approval, or monitoring result.
  • Effectiveness evidence: measure, audit result, exception trend, incident learning, or corrective-action verification.
Section 3

How should risk owners and control owners update the SoA?

ISO/IEC 27001 requires risk-owner approval of the treatment plan and acceptance of residual risk, but it does not prescribe the titles 'control owner' or ' owner.' Where the organization uses those roles, risk owners update treatment decisions, control owners update implementation and evidence, and the ISMS coordinator reconciles the .

A changed status should propagate both ways. A failed control can change residual risk and treatment, while a changed treatment can add, remove, or redesign necessary controls and entries.

  • Control owner submits changed status and evidence with affected scope and effective date.
  • Risk owner reassesses affected risks and approves changed treatment or residual-risk acceptance.
  • owner updates the version, rationale, evidence pointers, approval history, and review trigger.
Section 4

Which SoA mistakes break the risk-to-control chain?

The chain breaks when controls have no risk or requirement rationale, treatment actions have no entry, excluded controls have only 'N/A,' or implementation status has no current operating evidence.

It also breaks when teams assume is exhaustive and omit organization-designed, contractual, legal, or other-source controls needed for treatment.

  • Do not cite a standard title as evidence that a process is operating.
  • Do not reuse an old audit artifact without checking whether it remains relevant after the scope, service, supplier, or risk has changed.
  • Do not hide exceptions; record them as risk acceptance, corrective action, or management-review inputs.
Section 5

Which changes should trigger an SoA review?

ISO/IEC 27001 requires risk assessments at planned intervals and when significant changes are proposed or occur. Use those results to review affected treatment decisions and entries. Changes to requirements, scope, systems, suppliers, control design, or implementation status are practical triggers because they can change which controls are necessary.

Control the current under the rules. ISO/IEC 27001 sets no universal SoA review interval, so define a planned cadence that fits the and reassess sooner when a significant change occurs. Versioning, approval history, and durable evidence pointers are practical ways to preserve the current rationale and prevent an obsolete copy from being used.

  • Set a review date and a change-trigger rule.
  • Track findings until closure and connect them to corrective actions or risk acceptance.
  • Use management review to decide needed changes and improvement actions, including resources, scope, risk criteria, or evidence controls where relevant.
Primary sources

References and citations

iso.org4 citations
Referenced sections
  • This source is the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.
  • Clause 6.1.3 requires the organization to determine necessary controls, compare them with Annex A, produce the SoA, formulate a treatment plan, and obtain risk-owner approval and residual-risk acceptance.
  • Clause 8.1 requires documented information to the extent necessary to have confidence that processes were carried out as planned; Clause 9.1 requires documented information as evidence of monitoring and measurement results.
Show 1 more
  • Clause 8.2 requires information security risk assessments at planned intervals or when significant changes are proposed or occur.
"Information security management systems — Requirements"
iso.org2 citations
Referenced sections
  • This source supports control implementation guidance and control-implementation expectations supporting ISO/IEC 27001 governance.
  • ISO/IEC 27002 provides implementation guidance for information security controls; it does not replace the organization's Clause 6.1.3 control-selection decision.
"Information security controls"
iso.org
Referenced sections
  • This source supports risk treatment and monitoring context that informs control decisions and residual risk handling.
"Guidance on managing information security risks"
Show all related guides (21)

ISO/IEC 27001 Internal Audit and Management Review Guide

Keep ISO/IEC 27001 internal audit and management review distinct and connected: independent audit evidence, top-management decisions, corrective actions, resources, and improvement records.

ISO/IEC 27001 Requirements Guide

Plain-language guide to ISO/IEC 27001:2022 Clauses 4-10: context, leadership, planning, support, operation, performance evaluation, improvement, and Annex A control selection.

ISO/IEC 27001 Risk Treatment and Residual Risk Guide

Connect ISO/IEC 27001 risk-treatment choices, necessary controls, the treatment plan, Statement of Applicability, residual-risk acceptance, owners, evidence, and review triggers.

ISO/IEC 27001 Risk Treatment Register Workflow

Build an ISO/IEC 27001 risk-treatment register that links assessed risks to treatment options, controls, SoA entries, actions, owners, residual-risk approval, evidence, and review triggers.

ISO/IEC 27001 Statement of Applicability template: Annex A control selection and justification

Practical ISO/IEC 27001:2022 Statement of Applicability template fields for necessary controls, Annex A applicability, inclusion and exclusion rationale, status, owners, evidence, and review history.

ISO/IEC 27001 vs NIS2 Comparison

Compare voluntary ISO/IEC 27001 ISMS conformity and optional certification with NIS2 legal duties, entity scope, management accountability, incident reporting, supervision, and penalties.

ISO/IEC 27001 vs NIST CSF 2.0 Comparison

Compare ISO/IEC 27001:2022's certifiable ISMS requirements with NIST CSF 2.0's cybersecurity outcomes, Profiles, Tiers, Functions, evidence uses, and adoption choices.

ISO/IEC 27001 vs SOC 2 Comparison

Compare ISO/IEC 27001 certification with SOC 2 examination reports: criteria, scope, assurance period, auditor and certification-body roles, deliverables, evidence reuse, and claim limits.

ISO/IEC 27001 Annex A Control Ownership FAQ

How to assign practical owners for ISO/IEC 27001 Annex A controls without confusing control ownership with the standard's required risk-owner accountability.

ISO/IEC 27001 Certification Body Evidence FAQ

What ISO/IEC 27001 certification auditors may sample, how to connect requirements to operating evidence, and what the certification body does not own.

ISO/IEC 27001 Internal Audit FAQ

How should teams run ISO/IEC 27001 internal audits: who should own each step, what evidence is expected, and how findings are resolved.

ISO/IEC 27001 Management Review FAQ

What ISO/IEC 27001 management review must consider, what top management must decide, what evidence to retain, and how to set the cadence.

ISO/IEC 27001 Risk Acceptance FAQ

How ISO/IEC 27001 risk acceptance works: criteria, risk-owner approval, residual-risk evidence, external obligations, and reassessment triggers.

ISO/IEC 27001 SoA Exclusions FAQ

Justify ISO/IEC 27001 Annex A exclusions from scope and risk treatment, distinguish implementation gaps, and retain approval and review evidence.

ISO/IEC 27001 Surveillance Audits FAQ

What ISO/IEC 27001 surveillance audits check, how they differ from internal audit and recertification, and what evidence to maintain between audits.