What is a Statement of Applicability (SoA)?

Overview

The Statement of Applicability (SoA) is a mandatory ISO 27001 document that lists all 93 Annex A controls and explains whether each control is included in your ISMS or excluded. For included controls, it describes how they're implemented. For excluded controls, it provides justification for exclusion.

What it means in practice

The SoA is your control selection blueprint - it connects your risk assessment results to the specific security controls you've chosen to implement. Auditors use it as their roadmap to verify your ISMS addresses identified risks appropriately.

Why the SoA matters for ISO 27001

Mandatory requirement

ISO 27001 Clause 6.1.3(d) explicitly requires maintaining "a Statement of Applicability containing the necessary controls and justification for inclusions and exclusions." You cannot achieve certification without a complete, accurate SoA.

Demonstrates risk-based approach

The SoA proves you're not randomly implementing controls or blindly applying templates. It shows how each control decision traces back to your risk assessment.

Audit roadmap

Auditors use your SoA to plan what they'll verify during certification audits. Included controls need evidence of implementation and effectiveness. Exclusions must be justified based on risk assessment or business context.

Change management

As risks evolve, your SoA should update to reflect new control requirements or allow previously excluded controls to be removed if risks decrease.

What the SoA must include

Complete control listing

All 93 Annex A controls from ISO 27001:2022 must appear in your SoA, organized by theme:

• Organizational controls: A.5.1 through A.5.37 (37 controls)

• People controls: A.6.1 through A.6.8 (8 controls)

• Physical controls: A.7.1 through A.7.14 (14 controls)

• Technological controls: A.8.1 through A.8.34 (34 controls)

Inclusion/exclusion status

For each control, clearly state whether it's included in your ISMS or excluded. Avoid ambiguous statuses like "partially applicable" - controls are either in or out.

Implementation description (for included controls)

Briefly describe how you implement each included control. Include:

• Specific policies, procedures, or technologies used

• Who is responsible for the control

• Where evidence of implementation can be found

• How the control addresses identified risks

Exclusion justification (for excluded controls)

Explain why excluded controls aren't part of your ISMS. Valid justifications:

• Risk-based: "No risks in our assessment require this control"

• Context-based: "Not applicable - we are cloud-only with no physical infrastructure"

• Legal/regulatory: "Prohibited by data residency laws in our jurisdiction"

SoA structure and format

Tabular format (most common)

A table with columns for:

• Control number (e.g., A.5.1)

• Control name (e.g., "Policies for information security")

• Status (Included / Excluded)

• Implementation description or exclusion justification

• Risk reference (linking to risk register)

• Evidence location (optional but helpful)

Narrative format

Some organizations prefer a narrative document describing control implementation grouped by theme. Less common but acceptable if it clearly addresses all 93 controls.

Tool-based format

GRC platforms and ISMS tools often generate SoAs automatically based on control selection and linking to risk assessments. These still need manual validation for accuracy.

Creating your SoA

Step 1: Complete risk assessment

Your SoA is a direct output of risk assessment. Identify all risks requiring treatment before determining which controls to implement.

Step 2: Map controls to risks

For each risk requiring treatment, identify which Annex A controls would reduce it to acceptable levels. One risk may need multiple controls; one control may address multiple risks.

Step 3: Determine inclusion/exclusion

Controls addressing identified risks are included. Controls not addressing any of your risks can be excluded (with justification).

Step 4: Describe implementation

For included controls, document how you're implementing them. Be specific enough that auditors understand your approach without duplicating entire procedures.

Step 5: Justify exclusions

For excluded controls, explain why based on your risk assessment or organizational context. Reference specific findings from your risk register where possible.

Step 6: Review and approve

Management should formally review and approve the SoA, acknowledging the control selection decisions and any residual risks.

Common SoA mistakes

Excluding too many controls

Organizations sometimes exclude controls to reduce implementation effort. Auditors scrutinize exclusions carefully - if your risk assessment is thorough, most controls should be included.

Generic implementation descriptions

Copying control descriptions from ISO 27002 without describing your actual implementation. Auditors need to understand what you do, not what the standard says.

Missing risk linkages

Failing to connect controls back to specific risks in your risk assessment. This breaks traceability and suggests controls were selected arbitrarily.

Incomplete coverage

Forgetting to address all 93 controls. Even if a control seems obviously not applicable, it must appear in the SoA with exclusion justification.

No review cycle

Creating the SoA once during initial implementation and never updating it despite organizational changes or new risks.

SoA vs. other ISO 27001 documents

SoA vs. Risk Treatment Plan

The Risk Treatment Plan details how you'll implement selected controls (timelines, responsibilities, resources). The SoA declares which controls are implemented and why. The two documents are complementary.

SoA vs. Control Evidence

The SoA describes what controls you implement. Evidence proves the controls are actually operating effectively. During audits, auditors sample controls from your SoA and request corresponding evidence.

SoA vs. Policies and Procedures

Policies and procedures provide detailed instructions for implementing controls. The SoA summarizes at a high level which controls exist and how they work.

How auditors use the SoA

Stage 1 audit (documentation review)

Auditors verify your SoA is complete (all 93 controls addressed), logically structured, and aligned with your risk assessment. They check justifications for exclusions make sense.

Stage 2 audit (implementation verification)

Auditors sample controls from your SoA and request evidence they're implemented as described. They'll test controls across all four themes and organizational areas within scope.

Nonconformity triggers

Common reasons auditors issue nonconformities related to SoA:

• Controls marked "included" but not actually implemented

• Exclusions without valid justification

• SoA doesn't reflect actual risk assessment results

• Missing controls (fewer than 93 listed)

• Implementation descriptions too vague to verify

Maintaining the SoA over time

Annual risk assessment updates

When you perform scheduled risk reassessments, review the SoA to determine if control selections remain appropriate. New risks may require previously excluded controls.

Organizational changes

Update the SoA when:

• New technology is deployed (may require new technical controls)

• Business model changes (e.g., moving to cloud changes physical controls)

• Geographic expansion introduces new regulatory requirements

• Mergers or acquisitions change risk profile

Incident-triggered reviews

After significant security incidents, review whether existing controls were effective or if additional controls (previously excluded) should be implemented.

Surveillance audits

Auditors will check during annual surveillance audits whether the SoA has been kept current. Evidence of regular review demonstrates your ISMS is active, not abandoned post-certification.

SoA and control customization

Standard allows tailoring

ISO 27001 permits organizations to implement controls differently based on size, complexity, and risk. Your SoA should reflect your specific implementation, not a generic template.

Additional controls beyond Annex A

If your risk assessment identifies risks not adequately addressed by the 93 standard controls, you can implement additional controls. List these in your SoA or a supplementary document.

Proportionality matters

A 10-person startup's implementation of "A.6.3 Information security awareness training" will differ from a 10,000-person enterprise. Both can be compliant if appropriate to context and effective at reducing risk.

Related concepts

• Annex A Controls - The 93 security controls your SoA must address

• Risk Assessment - Process that drives control selection in your SoA

• Risk Treatment - Implementing controls identified in your SoA

• Control - The security measures you select in your SoA

• How to get started with ISO 27001 implementation using AI

Getting help

Accelerate SoA creation with ISMS Copilot. Generate customized implementation descriptions, validate your justifications against risk assessment results, and ensure all 93 controls are properly addressed.