Writing an ISO 27001 SoA Correctly

GQS SingaporeBlogUncategorizedWriting an ISO 27001 SoA Correctly

Organizations implementing an Information Security Management System (ISMS) under ISO 27001 must demonstrate how they manage information security risks and apply appropriate security controls. One of the most important documents that supports this process is the Statement of Applicability (SoA).

The ISO 27001 Statement of Applicability acts as the bridge between an organization’s risk assessment and the security controls it chooses to implement. It clearly documents which controls from ISO 27001 Annex A are applied, which are excluded, and the justification behind each decision.

Auditors rely heavily on the SoA during certification assessments because it provides a transparent overview of how an organization manages information security risks.

This article explains how to write an ISO 27001 SoA correctly, including its purpose, structure, key components, and best practices to ensure compliance and audit readiness.

What Is an ISO 27001 Statement of Applicability?

The Statement of Applicability (SoA) is a mandatory document required by ISO 27001. It identifies the security controls selected by an organization after completing its information security risk assessment.

In simple terms, the SoA answers three important questions:

  • Which Annex A controls are relevant to the organization?

  • Which controls are implemented within the ISMS?

  • Why certain controls are excluded or not applicable?

The SoA ensures that security controls are risk-driven rather than randomly selected.

By documenting control decisions clearly, the SoA demonstrates that the organization follows a structured and justified approach to information security management.

Why the Statement of Applicability Is Important

The Statement of Applicability plays a central role in ISO 27001 implementation and certification.

Demonstrates Risk-Based Decision Making

ISO 27001 requires organizations to implement controls based on risk assessment results. The SoA documents how risks are addressed through selected security controls.

This shows auditors that the ISMS is designed around real business risks rather than generic security practices.

Supports ISO 27001 Certification Audits

During ISO certification audits, auditors review the SoA to verify:

  • The relevance of selected controls

  • The justification for exclusions

  • Evidence of implementation

A well-prepared SoA helps streamline the audit process and prevents compliance gaps.

Improves Transparency in Security Governance

The SoA acts as a central reference document for security governance. Management, auditors, and stakeholders can easily see which controls are applied across the organization.

This transparency improves accountability and security oversight.

Structure of an ISO 27001 Statement of Applicability

A properly written SoA typically follows a structured format that aligns with ISO 27001 Annex A controls.

While formats may vary, most SoA documents include the following components.

Control Reference

Each entry in the SoA begins with the Annex A control number and title.

For example:

A.5.1 – Policies for information security

Including the control reference helps auditors quickly map the SoA to ISO 27001 requirements.

Control Description

The SoA should include a short description of the control.

This allows stakeholders to understand the purpose of each control without constantly referring to the ISO standard.

Applicability Status

For each Annex A control, the SoA must indicate whether the control is:

  • Applicable

  • Not applicable

This decision must always be based on risk assessment results and business requirements.

Controls should never be excluded without proper justification.

Justification for Inclusion or Exclusion

One of the most important parts of the SoA is the justification column.

For each control, organizations must explain why the control is:

  • Required

  • Implemented

  • Excluded

Example:

Control excluded because the organization does not host physical data centers.

Justifications should be clear, logical, and linked to risk assessment outcomes.

Implementation Status

The SoA must also indicate whether a control is:

  • Implemented

  • Partially implemented

  • Planned for implementation

This helps auditors evaluate the maturity of the ISMS.

Reference to Supporting Documents

Each control should be linked to relevant policies, procedures, or technical measures.

Examples include:

  • Access control policy

  • Incident response procedure

  • Vendor security policy

These references allow auditors to verify that controls are properly implemented.

Example Structure of an ISO 27001 SoA Table

Most organizations present their SoA as a structured table.

Typical columns include:

Control ID Control Name Applicable Justification Implementation Status Reference
A.5.1 Information security policy Yes Required for governance Implemented ISMS Policy
A.7.1 Screening Yes Required for HR security Implemented HR Security Policy
A.11.1 Physical security perimeter No No owned physical infrastructure Not applicable N/A

This format helps auditors quickly review control decisions.

Writing an ISO 27001 SoA Correctly

Below are the steps you need to follow for writing an ISO 27001 SoA Correctly

Step 1: Conduct an Information Security Risk Assessment

The first step is identifying information assets and assessing security risks.

Organizations evaluate threats such as:

  • Unauthorized access

  • Data breaches

  • Malware attacks

  • Insider threats

The results of this risk assessment determine which controls are necessary.

Step 2: Review Annex A Controls

ISO 27001 Annex A provides a catalog of 93 security controls in the 2022 version of the standard.

Organizations must evaluate each control and determine whether it is relevant to their environment.

This review should align with risk assessment findings.

Step 3: Select Appropriate Security Controls

Controls should be selected based on their ability to mitigate identified risks.

For example:

  • Access control controls address unauthorized access risks.

  • Encryption controls protect sensitive data.

  • Incident management controls address security breaches.

The selected controls are then documented in the SoA.

Step 4: Document Justifications

Every decision must be clearly justified.

Examples of valid justifications include:

  • Risk mitigation requirements

  • Regulatory obligations

  • Customer contractual requirements

  • Operational security needs

Justifications should be precise and evidence-based.

Step 5: Link Controls to Policies and Procedures

Each implemented control should reference existing documentation.

Examples include:

  • Information security policies

  • Asset management procedures

  • Incident response plans

  • Vendor management policies

This demonstrates that the control is actually implemented.

Step 6: Review and Approve the SoA

Before finalizing the document, the SoA should be reviewed by:

  • Information security leadership

  • ISMS management

  • Senior management or governance bodies

Approval ensures that control decisions align with organizational strategy.

Common Mistakes When Writing an SoA

Many organizations encounter problems during certification because of poorly prepared SoA documents.

Some common mistakes include:

Copying Annex A Without Analysis

Simply listing Annex A controls without linking them to risk assessment results is a common issue. Controls must always be justified through risk-based reasoning.

Weak Justifications for Control Exclusions

Auditors frequently question exclusions that lack clear justification. Every excluded control must have a logical explanation.

Missing Policy References

Controls that lack references to implementation documents create audit gaps. Auditors expect to see evidence supporting each implemented control.

Outdated SoA Documents

The SoA must be updated whenever there are:

  • Changes in business operations

  • New security risks

  • Updates to ISO standards

Keeping the SoA current is essential for maintaining certification.

Best Practices for Maintaining an Effective SoA

Organizations should treat the Statement of Applicability as a living document, not a one-time compliance requirement.

Recommended practices include:

  • Updating the SoA after every risk assessment

  • Aligning it with security policies and procedures

  • Reviewing it during internal ISMS audits

  • Ensuring management approval for major changes

  • Maintaining traceability between risks, controls, and policies

These practices ensure that the SoA remains accurate and useful for governance.

Conclusion

The ISO 27001 Statement of Applicability is one of the most important documents within an Information Security Management System. It connects risk assessment outcomes with the security controls implemented to protect organizational data.

By clearly documenting which Annex A controls are applicable, why they are selected or excluded, and how they are implemented, the SoA provides transparency into an organization’s security framework.

A well-prepared SoA not only simplifies ISO 27001 certification audits but also strengthens security governance and accountability across the organization.

For organizations aiming to build a mature and compliant ISMS, learning how to write an ISO 27001 SoA correctly is a critical step toward achieving strong information security management. Connect with Global Quality Services and we will help you more.