Practical toolGlobalISO/IEC 27001

ISO/IEC 27001 Statement of Applicability Evidence Workflow

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

Treat it as the decision index between risk treatment and operating evidence, not as a copied Annex A checklist or a claim that only Annex A controls may be used.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 24, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 24, 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.

Sources for this answer

ISO/IEC 27001:2022 standard page

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.

ISO/IEC 27002:2022 standard page

ISO/IEC 27002 provides implementation guidance for information security controls; it does not replace the organization's Clause 6.1.3 control-selection decision.

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.

Sources for this answer

ISO/IEC 27001:2022 standard page

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.

ISO/IEC 27005:2022 standard page

This source supports risk treatment and monitoring context that informs control decisions and residual risk handling.

Recommended next step

Track SoA decisions and evidence

Assign owners, request operating evidence, record control decisions, and keep review dates and change triggers visible.

Assessment workflow

Open Assessment Autopilot for ISO/IEC 27001

Create assigned tasks, evidence requests, and review checkpoints for each SoA decision.

Explore next step

Talk to Sorena

Talk through ISO/IEC 27001 implementation

Review your current scope, evidence gaps, and next implementation steps.

Explore next step

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.

Sources for this answer

ISO/IEC 27005:2022 standard page

This source supports risk treatment and monitoring context that informs control decisions and residual risk handling.

ISO/IEC 27001:2022 standard page

This source is the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

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.

Sources for this answer

ISO/IEC 27001:2022 standard page

This source is the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.

ISO/IEC 27002:2022 standard page

This source supports control implementation guidance and control-implementation expectations supporting ISO/IEC 27001 governance.

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.

Sources for this answer

ISO/IEC 27001:2022 standard page

Clause 8.2 requires information security risk assessments at planned intervals or when significant changes are proposed or occur.

ISO/IEC 27005:2022 standard page

This source supports risk treatment and monitoring context that informs control decisions and residual risk handling.

Primary sources