Use this field structure to document the necessary controls, why they are included, whether they are implemented, and why any controls are excluded.
Adapt it to the rather than copying mechanically. The SoA should stay aligned with risk treatment, legal and contractual requirements, control evidence, exceptions, and change history.
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.
1
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.
ISO/IEC 27002 provides control implementation guidance; it does not prescribe the SoA form or replace the organization's risk-treatment rationale.
Information security controls
2
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.
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.
This source is the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.
Information security management systems — Requirements
4
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.
This source supports control implementation guidance and control-implementation expectations supporting ISO/IEC 27001 governance.
Information security controls
5
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.
Clauses 7.5 and 8.2 support controlled documented information and risk reassessment at planned intervals or when significant changes are proposed or occur.
Information security management systems — Requirements
This source is the governing requirements context for ISO/IEC 27001 scope, control governance, and review cadence in ISMS operations.
Clause 6.1.3 specifies the SoA's required decisions and permits necessary controls designed by the organization or identified from any source.
Clauses 7.5 and 8.2 support controlled documented information and risk reassessment at planned intervals or when significant changes are proposed or occur.
"Information security management systems — Requirements"