Statement of Applicability (SoA)

The Statement of Applicability is one of the most important documents in an ISO 27001 ISMS. It serves as the bridge between your risk assessment outcomes and the controls you implement, providing a complete picture of which security controls your organization has selected, why, and their implementation status.

Auditors consider the SoA a mandatory document, and it is often the first artifact they request during both Stage 1 and Stage 2 of the certification process.

What Is the Statement of Applicability?

The SoA is a document that lists all the controls from Annex A of ISO 27001 and, for each control, states whether it is applicable or not applicable to your organization. For applicable controls, the SoA describes how the control is implemented. For excluded controls, it provides the justification for exclusion.

Clause 6.1.3(d) of ISO 27001 specifies that the SoA must contain:

• The necessary controls (those determined through risk treatment and any additional controls from other sources)
• Justification for their inclusion
• Whether the controls are implemented or not
• Justification for excluding any Annex A controls

The SoA is not just a compliance checkbox. It is the definitive map of your security control landscape and serves as a reference point for auditors, management, and operational teams.

Why the SoA Matters

For Auditors

The SoA is the roadmap auditors use to plan their assessment. During the Stage 2 audit, auditors systematically verify that each control declared as applicable in the SoA is actually implemented and operating effectively. A well-structured SoA makes audits smoother and demonstrates organizational maturity.

For Management

The SoA gives leadership a high-level view of the organization's security posture. It shows which risks are being treated, what controls are in place, and where gaps exist. This makes it a valuable input for management reviews required by clause 9.3.

For Operations

Security and IT teams use the SoA as a reference to understand what controls they are responsible for maintaining. When linked to specific policies, procedures, and evidence, the SoA becomes an operational tool rather than just an audit artifact.

How to Create a Statement of Applicability

Step 1: Complete Your Risk Assessment

The SoA cannot be created in isolation. It depends on the outputs of your risk assessment and risk treatment plan. You need to know which risks you are treating and which controls you have selected to mitigate those risks before you can build the SoA.

Step 2: List All Annex A Controls

Start with the complete list of 93 controls from Annex A of ISO 27001:2022, organized under the four themes: organizational, people, physical, and technological.

Step 3: Determine Applicability

For each control, determine whether it is applicable to your organization based on:

• Risk treatment decisions. Controls selected to mitigate identified risks are applicable.
• Legal and regulatory requirements. Some controls may be required by law regardless of your risk assessment findings.
• Contractual obligations. Customer contracts or partner agreements may mandate specific controls.
• Business requirements. Some controls support business objectives beyond pure security.

A control can be applicable even if your risk assessment did not specifically call for it, for example if it is required by regulation or considered industry best practice.

Step 4: Document Justifications

For each applicable control, document:

• Why it is included. Link it to specific risks, legal requirements, or contractual obligations.
• How it is implemented. Describe the implementation approach at a summary level. This could reference a policy, a technical configuration, a process, or a combination.
• Implementation status. Indicate whether the control is fully implemented, partially implemented, or planned.

For each excluded control, document:

• Why it is excluded. Provide a clear, defensible justification. Common reasons include the control being outside the ISMS scope, the associated risk being accepted, or the control being not relevant to the organization's context (for example, physical perimeter controls for a fully remote organization with no physical offices).

Step 5: Review and Approve

The SoA should be reviewed and approved by management as part of the ISMS governance process. It is a living document that reflects management's decisions about acceptable risk and control implementation.

SoA Structure and Format

ISO 27001 does not prescribe a specific format, but a typical SoA includes the following columns for each control:

Some organizations add columns for control owners, review dates, and notes. The level of detail should be proportionate to the complexity of your ISMS.

Relationship to Annex A

The SoA and Annex A are tightly coupled but serve different purposes. Annex A is the reference catalog of 93 controls provided by the standard. The SoA is your organization's declaration of which controls from that catalog you have adopted and how.

You are not limited to Annex A controls. If your risk assessment identifies a need for a control that is not in Annex A, you can and should implement it. The SoA should note any additional controls beyond Annex A that your organization has adopted.

Conversely, you cannot add controls to the SoA that are not implemented. The SoA must accurately reflect reality. If a control is listed as implemented, auditors will verify it.

Common Mistakes

Excluding Controls Without Justification

Every exclusion needs a documented rationale. Simply stating "not applicable" without explanation will be flagged by auditors. The justification must be specific to your organization's context, not generic.

Copy-Pasting from Templates

Using a template as a starting point is fine, but the SoA must reflect your actual environment. Generic descriptions copied from templates are immediately obvious to experienced auditors and indicate that the SoA was not developed through a genuine risk-based process.

Declaring Controls Implemented When They Are Not

Overstating implementation status is one of the most damaging mistakes. If an auditor finds that a control declared as "fully implemented" is only partially in place or not functioning, it results in a nonconformity. Be honest about implementation status. Listing a control as "partially implemented" or "planned" is perfectly acceptable, especially during initial certification.

Treating the SoA as Static

The SoA should be updated whenever your risk landscape changes, new controls are implemented, or existing controls are modified. A stale SoA that does not match your current control environment will cause problems during surveillance audits.

Disconnecting from the Risk Register

The SoA should have clear traceability to your risk register and risk treatment plan. Every applicable control should map to at least one risk, and every risk treatment decision that involves control implementation should be reflected in the SoA. Auditors specifically look for this linkage.

Making It Too Detailed or Too Vague

The SoA should provide enough detail for an auditor to understand what is in place and verify it, but it is not meant to be a comprehensive security architecture document. Strike a balance between brevity and completeness.

Maintaining the SoA

Build the SoA into your regular ISMS review cycle:

• After each risk assessment cycle, review whether new controls are needed or existing applicability decisions have changed.
• When implementing changes, update the SoA to reflect new or modified controls.
• Before surveillance audits, verify that the SoA matches the current state of your control environment.
• During management reviews, present SoA changes as part of the ISMS status update.

Maintaining the SoA in a spreadsheet is common but error-prone. Platforms like episki generate the SoA directly from your control graph, ensuring that applicability decisions, implementation status, and evidence references stay synchronized automatically. Learn more about how this fits into the broader ISO 27001 compliance workflow.