Practical toolGlobalISO/IEC 27001

ISO/IEC 27001 Statement of Applicability Template

Use this field structure to document the necessary controls, why they are included, whether they are implemented, and why any Annex A controls are excluded.

Adapt it to the ISMS rather than copying Annex A mechanically. The SoA should stay aligned with risk treatment, legal and contractual requirements, control evidence, exceptions, and change history.

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

This field design helps any organization applying create a for its documented scope; ISO does not prescribe a form. Start with the four decisions: necessary controls, inclusion justification, whether each necessary control is implemented, and justification for excluding controls. Add owners, evidence links, dates, and workflow status only where they help operate and control the record.

Section 1

Which fields belong in an auditable SoA?

requires the SoA to contain the necessary controls, justification for their inclusion, whether those necessary controls are implemented, and justification for excluding controls. The standard does not prescribe a spreadsheet, status vocabulary, approver title, or row layout, so label added fields as internal controls rather than ISO requirements.

Necessary controls can be designed by the organization or selected from any source. Use a field that distinguishes references from organization-specific or other-source controls so the SoA does not imply that Annex A is exhaustive.

is an ISO/IEC 27001 conformity requirement. ISO/IEC 27002 gives control guidance, and ISO/IEC 27005 gives risk-management guidance. This template's owner, evidence-pointer, review, and workflow fields are Sorena's practical recommendations.

Control identifier and source: , organization-designed, legal, contractual, or another framework.
Decision and rationale: necessary-control inclusion or exclusion, linked to risk or requirement.
Required implementation status: state whether each necessary control is implemented. Internal sub-statuses such as planned, partial, or blocked can add detail but must not obscure that required answer.
Recommended owner: name the person or role responsible for implementation and current evidence.
Recommended evidence pointer: identify the authoritative record, test, log, policy, approval, period, and repository.
Recommended review control: record the last decision date, next planned review, change trigger, version, and approval history.

Sources for this answer

ISO/IEC 27001:2022 standard page

Clause 6.1.3 specifies the SoA's required decisions and permits necessary controls designed by the organization or identified from any source.

ISO/IEC 27002:2022 standard page

ISO/IEC 27002 provides control implementation guidance; it does not prescribe the SoA form or replace the organization's risk-treatment rationale.

Section 2

How should the template link decisions to evidence?

The SoA should point to the risk or requirement that makes a control necessary, the treatment-plan action, the implementation description, and current operating evidence. Keep evidence at its authoritative source rather than copying stale screenshots into the SoA.

For exclusions, link the scope and risk facts that support the rationale and record the event that would make the control relevant. For included but incomplete controls, show the treatment owner, due date, and residual-risk decision rather than presenting them as implemented.

Example: if an outsourced support provider has privileged production access, a control row can link the supplier and access risks, the necessary restriction and monitoring controls, the contract and access procedure, current approval and log records, the implementation owner, and the next review. The specific control choice and status still depend on the scoped service, treatment decision, and evidence.

Example exclusion: an control may be unnecessary for a scope that does not use the relevant technology or activity, but the row should state the verified scope fact and a review trigger. A future service, supplier, architecture, legal requirement, or risk change can invalidate the exclusion.

Risk link: risk ID, treatment option, necessary-control rationale, and risk owner.
Implementation link: procedure, configuration, contract, training, or other control design.
Operation link: dated sample, monitoring result, test, review, log, ticket, or exception.
Review link: auditor result, corrective action, effectiveness result, and next review.

Sources for this answer

ISO/IEC 27002:2022 standard page

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

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

Put the SoA fields into use

Record required decisions first, then add owners, evidence pointers, review dates, change triggers, and approval history.

Assessment workflow

Open Assessment Autopilot for ISO/IEC 27001

Create assigned tasks, evidence requests, and review checkpoints from the SoA fields.

Explore next step

Talk to Sorena

Talk through implementation

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

Explore next step

Section 3

Who should draft, challenge, approve, and maintain the SoA?

The organization chooses who maintains the SoA. A practical split is for an coordinator to control the record, risk owners to approve the treatment plan and accept residual risk, and control owners to confirm implementation and evidence. Only the risk-owner approvals are stated explicitly in ; the other role names are internal governance choices.

ISO/IEC 27001 does not prescribe a universal SoA approver title. Define approval in the governance process and include specialists where legal, contractual, privacy, supplier, resilience, physical, or technical requirements affect the decision.

Draft: owner consolidates controls, rationales, status, owners, and evidence pointers.
Challenge: risk, control, legal, privacy, supplier, and technical owners test completeness and consistency.
Approve: use the organization's defined governance while preserving required risk-owner approvals.

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 template shortcuts create misleading control claims?

A prefilled list of 93 rows is useful only if each row reflects the organization's actual risk-treatment comparison. Copying 'applicable' into every row does not determine necessary controls, and copying 'not applicable' does not justify an exclusion.

Another misleading shortcut is marking a control implemented because a policy exists. The status should match the scoped implementation and operating evidence, including material exceptions and dependencies.

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

When should the SoA be versioned and reapproved?

ISO/IEC 27001 does not set a universal SoA review interval or require a named SoA reapprover. Define those controls internally. Reassess affected entries when planned or significant-change risk assessments alter treatment, or when scope, applicable requirements, suppliers, systems, control design, implementation status, or material exceptions change.

Keep prior rationales and approvals as controlled history under the rules. A current SoA should explain today's necessary controls and implementation state without erasing the decision trail used in earlier audits or reviews.

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

Clauses 7.5 and 8.2 support controlled documented information and risk reassessment 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

References and citations

ISO/IEC 27001:2022 standard page

iso.org

Referenced sections

Clauses 7.5 and 8.2 support controlled documented information and risk reassessment at planned intervals or when significant changes are proposed or occur.