ISO 27001 SoA Guide for Security Teams

AKRUP

4 days ago

8 min read

A certification auditor can spot a weak Statement of Applicability within minutes. Missing rationale, vague exclusions, and controls with no evidence reference quickly expose a gap between documented intent and operational security.

A well-managed ISO 27001 SoA is more than a compliance document. It connects the risks your organisation has identified with the controls it has chosen, the people responsible, and the evidence that proves those controls operate in practice.

The goal is clear: build a Statement of Applicability that supports sound security decisions and stands up to audit scrutiny.

What an ISO 27001 SoA is and why it is mandatory

The Statement of Applicability, usually shortened to SoA, is a required documented output of ISO/IEC 27001:2022 Clause 6.1.3(d). It records the Annex A controls considered by the organisation, whether each is applicable, why it is included or excluded, and whether applicable controls have been implemented.

The ISO 27001 Clause 6.1.3 requirements make the point plainly: the SoA must address every Annex A control. It is not acceptable to select a convenient subset and leave the remainder unaddressed.

The SoA is a record of risk decisions

The SoA should show that control selection was deliberate. Each decision must relate to the ISMS scope, risk assessment results, legal duties, customer commitments, and the organisation's wider security objectives.

It is the record that answers a simple auditor question: "Why have you chosen this control, and how do you know it is appropriate?"

A control may be applicable because it reduces a recognised information security risk. It may also be required by the UK GDPR, a customer contract, insurer expectations, or a group policy. These reasons should be recorded, not assumed.

It links risk assessment to risk treatment

A risk assessment identifies threats, vulnerabilities, assets, and potential business impact. The risk treatment plan sets out the agreed action, such as reducing, avoiding, transferring, or accepting a risk.

The SoA sits between those documents and the working control environment. It translates treatment decisions into a practical control set.

A risk register without a clear SoA link can show what concerns the organisation. It does not show how those concerns are being managed.

The SoA should not replace the risk treatment plan. Both documents need to point to each other through risk IDs, treatment references, or a clear mapping method.

Annex A controls in ISO 27001:2022

ISO/IEC 27001:2022 reorganised Annex A. The earlier 2013 edition contained 114 controls across 14 domains. The 2022 edition has 93 controls arranged within four themes.

The ISO 27001:2022 Annex A structure provides a useful overview of the revised control set.

The four Annex A themes

Theme	Number of controls	Typical focus
Organisational controls	37	Governance, suppliers, incident management, continuity
People controls	8	Screening, awareness, remote working, responsibilities
Physical controls	14	Secure areas, equipment, monitoring, disposal
Technological controls	34	Access control, logging, cryptography, backups, networks

The new structure is easier to scan, but it does not reduce the need for careful analysis. Security teams still need to assess every control against their environment and risk profile.

Annex A is a reference set, not a limit

Annex A gives organisations a recognised control catalogue. It does not contain every security measure an organisation might require.

A manufacturer with operational technology, a cloud software provider, and a professional services firm will have different risk profiles. Each may need additional controls beyond Annex A, such as bespoke segregation rules, secure development gates, or customer-specific supplier checks.

Your SoA should show Annex A decisions clearly. Supporting policies and technical standards can document the extra controls needed to manage specific risks.

What every Statement of Applicability should contain

A usable SoA is a controlled document, not an unstructured spreadsheet with a few ticks. It should give security, compliance, leadership, and auditors a consistent view of the control environment.

Core fields for each control

Every Annex A control should have a separate row or record. At a minimum, include:

Control reference, title, and theme.
Applicability status, normally "Applicable" or "Not Applicable".
A concise justification for inclusion or exclusion.
Implementation status, such as implemented, partially implemented, planned, or not implemented.
Linked risk IDs, legal obligations, customer requirements, or treatment actions.
Control owner and references to evidence, policies, procedures, configurations, or records.

The Clause 6.1.3 risk treatment guidance also confirms that Annex A is a reference point for selecting controls. It should be used alongside your own risk treatment process, not as a substitute for it.

Document control and evidence references matter

Include the SoA owner, version, approval date, review date, ISMS scope statement, and change history. These details reduce confusion when the document is updated before a surveillance audit or after a major business change.

Avoid broad evidence references such as "IT policy" or "security process". Instead, point to an identifiable item. For example: "Access Control Policy v3.2, Azure AD conditional access configuration, quarterly privileged access review record."

This approach makes the document easier to test internally and prevents evidence gathering becoming a last-minute exercise.

How to write defensible control justifications

The quality of a justification matters more than its length. "Best practice", "ISO requirement", and "not relevant" are rarely enough on their own.

Use plain language that connects the decision to risk, scope, or an obligation. A reader should understand the reasoning without needing a separate meeting.

Writing a strong inclusion rationale

For an applicable control, state the reason and the intended outcome. A good entry could read:

"Applicable. The organisation uses cloud-hosted systems to process customer and employee information. Supplier security requirements are needed to reduce the risk of unauthorised access, service disruption, and non-compliance with contractual obligations."

This is stronger than "Applicable because we use suppliers". It identifies the context, the risk, and the reason for the control.

For A.5.7, Threat Intelligence, an organisation might record: "Applicable. The security team reviews relevant threat sources and vendor alerts to inform vulnerability prioritisation and incident response decisions." The supporting evidence could include vulnerability review records, security advisories, and incident procedures.

Excluding controls without creating audit risk

A control can be marked not applicable, but the reason must be credible within the defined ISMS scope. Exclusion is not a way to avoid work.

For example, an organisation that owns no data centres and has no physical server estate may exclude a control relating to equipment siting and protection. Its rationale should still acknowledge the environment: "Not applicable. The ISMS scope covers cloud-hosted services and office operations only. The organisation does not operate data-centre facilities or on-premises server rooms. Relevant physical security risks for office equipment are managed through applicable physical controls."

For A.5.23, Information Security for Use of Cloud Services, exclusion will be difficult for most modern organisations. Email, collaboration platforms, hosted applications, and infrastructure services all create supplier and cloud security considerations.

A weak rationale hides uncertainty. A strong rationale states the scope boundary and links to risk evidence.

Use Excel or GRC software with discipline

Microsoft Excel is suitable for many small and medium-sized organisations. It is familiar, flexible, and easy to export for an auditor. A structured workbook can hold controls, risk links, owners, evidence references, review dates, and action status.

The weakness is governance. Multiple copies, inconsistent updates, and broken evidence links can undermine the document quickly. Use restricted editing, version control, a defined owner, and a formal review process.

When a spreadsheet remains the right choice

Excel works well when the ISMS scope is stable, the control environment is not overly complex, and the team has a disciplined document-management process. It can also support a focused first certification project.

Use one authoritative file. Keep referenced evidence in controlled locations, not on personal drives. Review formulae, filters, and status fields before every internal audit.

When a GRC platform may help

A GRC platform can be useful when the organisation manages several frameworks, large supplier populations, distributed evidence, or frequent risk changes. Products such as ISMS.online, HighTable, and Orbiq offer structured ways to manage SoA content.

The platform does not make the risk decision for you. It cannot turn generic rationale into a defensible control choice. The underlying work still requires accountable owners, accurate risks, and evidence that reflects daily practice.

Maintain the SoA as the business changes

An ISO 27001 SoA should change when the organisation changes. Treat it as part of the ISMS operating cycle, alongside risk reviews, internal audits, management review, and corrective actions.

Virtual CISO services can provide governance oversight where internal teams need additional support to keep these activities focused and accountable.

Review after defined triggers

Review the SoA after a material change, including:

A new cloud platform, major supplier, acquisition, office move, or remote-working change.
A security incident, audit nonconformity, or significant risk assessment update.
New contractual security clauses, regulatory obligations, or customer assurance requirements.
A change to the ISMS scope, risk appetite, business services, or information classification scheme.

An annual review alone may not be enough. If a new SaaS platform processes sensitive customer data in March, waiting until December to assess cloud controls leaves an avoidable gap.

Keep control status honest

"Implemented" should mean the control operates as intended and has evidence behind it. If a procedure exists but staff have not followed it, record the position accurately and track corrective action.

Partially implemented controls are not automatically a certification failure. They do, however, need an agreed treatment action, owner, target date, and clear explanation of any residual risk accepted by management.

Preparing the ISO 27001 SoA for audit

Certification audits normally involve a Stage 1 review of ISMS readiness and documentation, followed by Stage 2 testing of implementation and effectiveness. The certification body will sample evidence, interview staff, and trace how your documented processes work in reality.

When selecting a provider, confirm its accreditation status. UKAS accreditation for certification bodies covers management-system certification against ISO/IEC 17021-1.

What Stage 1 is likely to expose

At Stage 1, auditors commonly look for completeness and consistency. They will compare the SoA with the ISMS scope, risk assessment method, risk register, treatment plan, policies, and internal audit programme.

Before the audit, check that every Annex A control has a recorded decision. Make sure exclusions have a meaningful rationale and applicable controls have implementation status recorded.

A practical pre-audit checklist

Confirm the SoA aligns with the edition of ISO/IEC 27001 used by your certification body.
Trace a sample of high risks to treatment actions, applicable controls, and retained evidence.
Test evidence references with control owners. Broken links and outdated policies create unnecessary findings.
Check that control implementation reflects the SoA status, particularly for suppliers, access reviews, logging, incident management, and cloud services.
Review approved exclusions with risk owners and senior management where appropriate.
Complete an internal audit before certification, then close or formally manage findings.

Independent review is often the quickest way to identify gaps between documentation and practice. ISO 27001 specialists can support gap analysis, internal audit activity, and certification readiness.

Key Takeaways

The SoA is a mandatory record of Annex A control decisions under ISO/IEC 27001:2022 Clause 6.1.3(d).
It must connect risk assessment results, the risk treatment plan, selected controls, owners, and evidence.
Every Annex A control needs a recorded applicability decision and justified inclusion or exclusion.
A defensible ISO 27001 SoA is specific, controlled, current, and supported by evidence that auditors can test.

Frequently asked questions

Does every Annex A control have to be implemented?

No. Every control must be considered and recorded in the Statement of Applicability, but not every control will be applicable to every organisation. Exclusions need a clear justification based on scope, risk, legal duties, contracts, or the operating environment.

Can one SoA format guarantee ISO 27001 certification?

No format guarantees certification. A spreadsheet, template, or GRC platform can support the process, but certification depends on the full ISMS, the quality of risk treatment, and evidence that controls operate effectively. Check the requirements against the applicable ISO/IEC 27001 edition and your certification body's guidance.

How often should the Statement of Applicability be reviewed?

Review it at planned intervals and after material changes to risks, scope, suppliers, technology, regulation, or business operations. It should also be reviewed after significant incidents, internal audit findings, and management decisions that affect risk treatment.

What is the most common SoA weakness?

Generic justifications are a frequent problem. "Not applicable" without a scope or risk-based explanation does not demonstrate a considered decision. Another common weakness is listing a control as implemented without current evidence to support that claim.

Build an SoA that reflects real security practice

The strongest Statement of Applicability is not the longest one. It is the document that gives a clear, honest account of how the organisation manages information security risk.

Keep each decision connected to the risk register, treatment plan, control owner, and retained evidence. That discipline makes audit preparation more manageable and keeps the ISMS aligned with how the business actually operates.

If you would like more information or require any ISO 27001 services, please Contact Us