ISO 27001 Statement of Applicability: How to Write One That Passes Certification Audit

The Statement of Applicability is the single most important document in your ISO 27001 implementation. It is the document that connects your risk assessment to your control implementation. It is the first thing most auditors request during a certification audit, and it is the document they will reference continuously throughout the assessment.

Despite its importance, the SoA is frequently treated as a checkbox exercise. Organizations download a template, mark every control as "applicable," write vague implementation descriptions, and move on. This approach creates problems during certification because auditors know exactly what a rushed SoA looks like, and it triggers deeper questioning in every area where the documentation is thin.

This guide explains what the SoA is, how it connects to your risk assessment, how to handle exclusions without raising audit flags, and the specific mistakes that cause organizations to receive nonconformities during certification.

What the Statement of Applicability Is and Why It Matters

Clause 6.1.3 of ISO 27001 requires the organization to produce a Statement of Applicability that contains the necessary controls, justification for their inclusion, whether they are implemented or not, and justification for excluding any Annex A controls. This is a mandatory documented information requirement, meaning you cannot achieve certification without it.

The SoA serves three distinct purposes in the ISMS:

1. It documents your control selection decisions. The 93 Annex A controls are a reference set, not a mandatory checklist. The SoA records which controls you have determined are necessary based on your risk assessment, which you have excluded, and why.
2. It provides traceability from risk to control. Each applicable control should trace back to one or more risks in your risk assessment. This traceability is how you demonstrate that your control selection is risk-based rather than arbitrary.
3. It defines the audit scope. The auditor uses the SoA to plan which controls to examine. If a control is marked as applicable and implemented, the auditor will verify that claim. If a control is excluded, the auditor will evaluate whether the exclusion is justified.

Structure of an Effective SoA

There is no prescribed format for the SoA, but effective ones share a common structure. The document should be organized by the four Annex A themes (Organizational, People, Physical, Technological) and include the following columns for each of the 93 controls.

Version Control and Approval

The SoA must include version control metadata: version number, date, author, reviewer, and approver. The approver should be someone with authority over the ISMS, typically the information security manager or a member of senior management. Auditors check that the SoA has been formally approved and that the approval is current.

How the SoA Connects to Risk Assessment

The relationship between the risk assessment and the SoA is where many implementations go wrong. The standard requires a specific sequence: identify risks, assess risks, determine risk treatment options, select controls from Annex A (and any additional controls needed), then document the selections in the SoA.

In practice, this means your risk assessment should be completed before the SoA is finalized. Each control marked as applicable in the SoA should correspond to at least one risk in your risk treatment plan. This does not mean every control needs a one-to-one mapping to a specific risk. Some controls address multiple risks, and some risks are treated by multiple controls.

What Happens When the Chain Breaks

• SoA written before risk assessment. If you selected controls before completing the risk assessment, the SoA is not risk-based. Auditors verify this by checking dates: if the SoA was approved before the risk assessment was completed, the sequence is wrong and the SoA must be revised.
• Risks identified but no corresponding controls. If your risk assessment identifies a risk related to secure development, but the SoA does not include the relevant technological controls (A.8.25-A.8.28), the auditor will question why identified risks are not being treated.
• Controls included without corresponding risks. If you mark a control as applicable but there is no risk in your assessment that it treats, the control inclusion is not justified. While this is less severe than the reverse, it suggests the SoA was completed as a template exercise rather than a risk-based selection.
• Risk treatment plan references controls not in the SoA. The risk treatment plan and the SoA must be consistent. If the treatment plan says "implement A.8.24 (use of cryptography)" but the SoA says A.8.24 is excluded, you have a documented contradiction.

How to Justify Control Exclusions

Exclusions are where auditors spend the most time, because an unjustified exclusion means the organization has a gap in its control framework that it has chosen not to address. The standard permits exclusions, but only with justification, and that justification must withstand auditor scrutiny.

Valid Exclusion Justifications

• The risk does not exist in your environment. A fully cloud-based organization with no physical premises can reasonably exclude physical perimeter security controls (A.7.1-A.7.4). The justification must reference the risk assessment confirming that physical access risks are not relevant to the ISMS scope.
• The risk is addressed by a different control. If control A.7.10 (storage media) is not applicable because your organization uses no removable media and has a policy prohibiting it enforced through endpoint management (A.8.1), you can exclude A.7.10 with a reference to the compensating control.
• The control is outside your ISMS scope. If your ISMS scope is limited to a specific product or business unit, controls related to areas outside that scope can be excluded. However, auditors will challenge narrow scoping that appears designed to avoid difficult controls.
• The activity does not occur. If your organization does not develop software, you can exclude secure development lifecycle controls (A.8.25-A.8.28). If you do not use third-party development, you can exclude A.8.30 (outsourced development). The justification must accurately describe your operating model.

Invalid Exclusion Justifications

• "Too expensive to implement." Cost is not a valid reason to exclude a control. If the risk exists, you must either implement the control, implement an alternative control, or accept the residual risk through your risk treatment process. Excluding it from the SoA implies the risk does not exist, which is different from choosing not to treat it.
• "Not a priority right now." Timing is not a valid exclusion reason. If the control is applicable, mark it as applicable with an implementation status of "planned" and include it in your risk treatment plan with a target date.
• "We use a third party for that." Using a third party does not eliminate the control. It may change how you implement it (through contractual requirements, vendor assessments, and monitoring), but the control is still applicable. A.5.19-A.5.23 specifically address supplier relationship security.
• No justification provided. An empty justification field for an excluded control is an immediate finding. Every exclusion needs a documented reason.

Common SoA Controls That Organizations Struggle With

Certain controls consistently create difficulty in the SoA, either because organizations are unsure whether they apply, or because the implementation description does not match what the auditor finds during assessment.

Writing Implementation Descriptions That Satisfy Auditors

The implementation description column is where most SoAs fall short. Generic descriptions copied from the standard provide no useful information to the auditor and suggest that the organization has not actually thought about how the control operates in their specific environment.

Bad vs. Good Implementation Descriptions

Notice the pattern: good descriptions name specific tools, reference specific documents, include measurable parameters, and demonstrate that the control is genuinely operational. The auditor reading a good description can immediately plan what evidence to request. A bad description forces the auditor to ask open-ended questions, which extends the audit and often uncovers deeper issues.

Common Audit Findings Related to the SoA

These are the nonconformities and observations we see most frequently during ISO 27001 certification audits related to the Statement of Applicability.

• SoA not aligned with current risk assessment. The risk assessment was updated six months ago, but the SoA still reflects the original version. New risks were identified but no corresponding controls were added to the SoA. This is a nonconformity against Clause 6.1.3.
• Exclusions without justification. Controls are marked as not applicable with no explanation, or with a one-word justification like "N/A." Each exclusion requires a specific, documented reason that references the risk assessment or operating model.
• Implementation status does not match reality. The SoA says a control is "fully implemented," but during the audit the auditor finds it is only partially implemented or not implemented at all. This is one of the most damaging findings because it undermines the credibility of the entire document.
• No version control or approval. The SoA exists as an undated, unsigned spreadsheet. Auditors need to verify when it was last reviewed, who approved it, and whether it is the current version. Missing metadata is a documentation nonconformity.
• Missing controls. The SoA lists only 88 controls instead of 93, with five controls simply absent from the document. Every Annex A control must be listed, even if excluded. Omitting a control is different from excluding it.
• Generic implementation descriptions. Descriptions that could apply to any organization provide no assurance that the control is actually implemented. Auditors will probe harder on every control with a generic description.

Maintaining the SoA After Certification

The SoA is not a one-time document. It must be maintained as a living document throughout the certification cycle. Surveillance auditors review the SoA at every visit and expect to see evidence of ongoing maintenance.

When to Update the SoA

• After risk assessment updates. Any changes to your risk register that affect control selection must be reflected in the SoA. New risks may require new controls; eliminated risks may allow control modifications.
• After significant organizational changes. Mergers, acquisitions, new products, new markets, or changes to the ISMS scope all potentially affect which controls are applicable and how they are implemented.
• After technology changes. Migrating to a new cloud provider, adopting a new identity platform, or changing your backup infrastructure all affect implementation descriptions. The SoA should reflect your current environment, not the environment you had when you first certified.
• After internal audit findings. If an internal audit identifies that a control is not operating as described in the SoA, update the implementation status and description to reflect reality, then address the gap through corrective action.
• At minimum, annually. Even if no specific triggers occur, review the entire SoA at least annually as part of your management review process to confirm it remains accurate.

If you are managing both ISO 27001 and SOC 2 compliance, your SoA maintenance process should be coordinated with your dual certification approach. Many controls overlap, and keeping both frameworks synchronized reduces the total maintenance burden.

SoA Best Practices for Different Organization Types

SaaS Companies

SaaS organizations typically apply the vast majority of technological controls and exclude some physical controls. Pay particular attention to A.5.23 (cloud services), A.8.11 (data masking), A.8.23 (web filtering), and A.8.25-A.8.28 (secure development). If you are expanding into European markets, your SoA should also address data residency and cross-border transfer controls.

Professional Services Firms

Professional services firms often have a narrower technology footprint but more complex people and organizational controls. Focus on A.5.10 (acceptable use), A.5.14 (information transfer), A.6.1-A.6.8 (people controls), and A.5.19-A.5.23 (supplier relationships). Client confidentiality requirements may drive stricter implementation of access control and data handling controls.

Organizations Using Compliance Automation

If you use a compliance automation platform like Drata, Vanta, or Secureframe, the platform likely generates a draft SoA based on your integrations. This is a useful starting point, but treat it as a draft. Automated SoAs tend to be generic in their implementation descriptions and may not accurately reflect your exclusion justifications. Review and customize every line before presenting it to an auditor.

Pre-Certification SoA Review Checklist

Before submitting your SoA to the certification body, verify each of these items. Every item on this list represents a check that experienced auditors perform.

• All 93 Annex A controls are listed. Count them. Missing controls are an immediate finding.
• Every exclusion has a documented justification that references a specific reason (no relevant risk, outside ISMS scope, addressed by alternative control).
• Implementation descriptions are specific to your organization and reference actual tools, processes, documents, or systems.
• Implementation status is honest. Mark controls as partially implemented if they are. A plan to complete implementation is better than a false claim of full implementation.
• Risk references trace back to the current risk assessment. Verify that every applicable control maps to at least one risk in the current risk register.
• The SoA is version-controlled with date, version number, author, and approver clearly documented.
• The SoA is consistent with the risk treatment plan. Controls in the treatment plan appear in the SoA, and vice versa.
• Exclusion count is reasonable. If you have excluded more than 20 controls, review each exclusion critically. The auditor will.
• The SoA has been reviewed by someone other than the author to catch inconsistencies, generic descriptions, and unjustified exclusions.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

We've completed 170+ security engagements across web apps, APIs, cloud infrastructure, and AI-generated codebases. Everything we publish here comes from patterns we see in real client work.