What is an ISO 27001 Statement of Applicability?

The ISO 27001 Statement of Applicability (SoA) is a mandatory document that lists all Annex A controls, states whether each is applicable or excluded, and provides a justification for every decision. It links your risk treatment plan to your actual security controls.

Which ISO 27001 controls must be included in the SoA?

All 93 controls from ISO 27001:2022 Annex A must be listed in the SoA. You do not have to implement every control, but you must explicitly include or exclude each one with a documented justification for your decision.

How do auditors evaluate the Statement of Applicability?

Auditors verify that every included control is implemented and evidenced, every exclusion is logically justified and does not create unacceptable risk, and that the SoA aligns with your risk assessment and risk treatment plan.

Can an SMB exclude controls from the ISO 27001 SoA?

Yes. SMBs can exclude controls that are not applicable to their environment, such as physical media transfer controls for a fully cloud-based company. Each exclusion must be justified in writing and must not leave a residual risk that is unacceptable.

What is the difference between the SoA and the risk treatment plan?

The risk treatment plan identifies risks and the controls chosen to address them. The SoA is the formal declaration of which Annex A controls apply, why they apply or are excluded, and their implementation status. The two documents must be consistent with each other.

How often should the Statement of Applicability be updated?

The SoA should be reviewed at least annually and updated whenever there is a significant change to your environment, risk landscape, or business operations. Auditors will check version history and review dates during surveillance and recertification audits.

ISO 27001 Statement of Applicability Guide for SMBs

The ISO 27001 Statement of Applicability is one of the most misunderstood — and most critical — documents in your entire certification journey. For small and mid-sized businesses attempting ISO 27001 without a dedicated compliance team, getting the SoA wrong can derail your audit, waste months of preparation, and leave real security gaps exposed. This guide breaks down exactly what the SoA is, how to build one that satisfies auditors, and how to maintain it without drowning in spreadsheets.

What Is the ISO 27001 Statement of Applicability?

The Statement of Applicability (SoA) is a mandatory document required by ISO/IEC 27001:2022 under clause 6.1.3(d). It serves as the formal record of which information security controls from Annex A your organization has selected, which it has excluded, and — critically — the justification for every decision in both categories.

Think of the SoA as the bridge between your risk assessment and your actual security implementation. It answers three questions that every ISO 27001 auditor will ask:

Which of the 93 Annex A controls apply to your organization?
Are those controls currently implemented, and to what degree?
Why have you excluded any controls, and can you justify that exclusion?

The 2022 revision of ISO 27001 restructured Annex A from 114 controls across 14 domains into 93 controls organized across four themes: Organizational (37), People (8), Physical (14), and Technological (34). If your SoA still references the old 2013 structure, it needs to be updated before your next audit cycle.

Why the Statement of Applicability Matters More Than Most SMBs Realize

Many SMBs treat the SoA as a checkbox exercise — a table to fill in quickly so they can move on to "real" security work. This is a costly mistake. The SoA is the document your certification auditor will scrutinize most carefully during Stage 2 of the audit. Weak justifications, missing implementation evidence, or controls marked "implemented" without supporting proof are among the top reasons audits fail or result in major nonconformities.

Beyond the audit, the SoA has genuine operational value. It forces your leadership team to make deliberate, documented decisions about risk tolerance. When a security incident occurs — and statistically, it will — your SoA demonstrates that your organization applied reasoned judgment, not guesswork, to its security posture.

The Cost of Getting It Wrong

A poorly constructed SoA creates cascading problems:

Audit failure: Auditors may issue major nonconformities if exclusions lack documented risk justification.
Security gaps: Excluding controls without proper risk treatment leaves real vulnerabilities unaddressed.
Rework costs: Rebuilding the SoA mid-audit or post-audit is expensive and time-consuming.
Customer trust damage: Enterprise customers increasingly request your SoA as part of vendor due diligence.

How to Build an ISO 27001 Statement of Applicability: Step-by-Step

Building a defensible SoA is a structured process, not a one-afternoon task. Here is the sequence that works for SMBs operating without a full-time CISO.

Step 1: Complete Your Risk Assessment First

The SoA cannot be built in isolation. ISO 27001 clause 6.1.2 requires you to identify information security risks, assess their likelihood and impact, and determine risk treatment options. Your control selections in the SoA must flow directly from this risk treatment plan. If you select a control that has no corresponding risk, or exclude a control without a risk-based rationale, your SoA will not hold up to scrutiny.

Your risk assessment should identify assets, threats, vulnerabilities, and existing controls. The output — a risk treatment plan — tells you which risks you will mitigate (and with which controls), accept, transfer, or avoid.

Step 2: Map Every Annex A Control

Work through all 93 controls in ISO 27001:2022 Annex A systematically. For each control, document:

Applicability decision: Applicable or Not Applicable
Justification for inclusion or exclusion: Reference specific risks, legal requirements, contractual obligations, or business context
Implementation status: Not implemented, Partially implemented, or Fully implemented
Evidence reference: Link to the policy, procedure, tool, or record that demonstrates implementation

A control can only be excluded if the associated risk does not apply to your organization and there are no legal or contractual requirements mandating it. For example, a fully remote company with no physical office may legitimately exclude certain physical security controls — but this must be explicitly justified, not assumed.

Step 3: Document Justifications That Will Survive Scrutiny

This is where most SMBs cut corners. Justifications like "not relevant" or "low risk" are not acceptable to a certification auditor. Strong justifications reference:

Specific risk assessment findings (e.g., "Risk ID R-14 assessed as low likelihood; risk accepted by management on [date]")
Legal or regulatory requirements (e.g., GDPR Article 32 mandates encryption, supporting inclusion of control 8.24)
Contractual obligations from customers or partners
Industry-specific standards or best practices
Business context (e.g., no third-party suppliers means supplier relationship controls have limited scope)

Step 4: Assign Ownership and Implementation Evidence

Every applicable control needs an owner — a named individual or role responsible for implementation and ongoing maintenance. Without ownership, controls drift. Pair each control with a reference to its evidence: a policy document, a configuration screenshot, an access log, a training record, or a vendor contract.

This evidence mapping is what transforms your SoA from a theoretical document into a living compliance artifact that auditors can verify.

Step 5: Get Management Sign-Off

ISO 27001 requires top management involvement in the ISMS. The SoA should be formally approved by a member of senior leadership — not just the IT manager. This sign-off demonstrates organizational commitment and is a requirement auditors will verify.

Common ISO 27001 Statement of Applicability Mistakes SMBs Make

Having reviewed hundreds of SoA documents, these are the patterns that consistently cause problems:

Copy-pasting a template without customization: Generic SoAs are immediately obvious to experienced auditors. Every justification must reflect your actual business context.
Marking controls as "implemented" prematurely: If the policy exists but hasn't been communicated to staff, the control is not fully implemented.
Treating the SoA as a one-time document: The SoA must be reviewed and updated at planned intervals and whenever significant changes occur — new systems, new services, acquisitions, or changes in threat landscape.
Excluding controls to reduce workload: Exclusions must be risk-based, not convenience-based. Auditors are trained to spot this pattern.
Disconnecting the SoA from the risk register: Every inclusion and exclusion should trace back to a specific risk treatment decision.

What a Strong SoA Structure Looks Like

While ISO 27001 does not prescribe a specific format, the following table structure is widely accepted by certification bodies and covers all required elements:

Control ID	Control Name	Applicable?	Justification	Implementation Status	Evidence Reference	Owner
5.1	Policies for information security	Yes	Required by ISO 27001 clause 5.2; legal obligation under GDPR Art. 24	Fully implemented	IS-POL-001 v2.3, approved 2024-01-15	CISO / IT Manager
7.4	Physical security monitoring	No	Organization is fully remote; no physical office premises. Risk R-22 assessed as not applicable.	N/A	Risk Register R-22; Remote Work Policy v1.1	N/A

The ISO 27001 standard itself and its companion guidance document ISO 27002:2022 provide detailed implementation guidance for each control, which should inform both your justifications and your evidence collection.

Maintaining Your SoA After Certification

Certification is not the finish line — it is the starting point of a three-year surveillance cycle. Your SoA must remain a living document. Build a review cadence into your ISMS calendar:

Annual review: Full review of all controls, implementation status, and justifications aligned with your annual risk assessment cycle
Triggered reviews: Any significant change — new cloud infrastructure, a merger, a new product line, a data breach — should trigger an SoA review
Surveillance audit preparation: Update implementation evidence references before each annual surveillance visit

Organizations that treat the SoA as a living operational document consistently perform better in surveillance audits and experience fewer security incidents, because the discipline of maintaining the SoA forces regular engagement with actual security controls.

How Automation Changes the SoA Game for SMBs

Manually maintaining an SoA in a spreadsheet is error-prone and time-consuming — especially for SMBs where the person responsible for compliance is also wearing five other hats. This is where purpose-built compliance platforms fundamentally change the economics of ISO 27001.

ComplyGuard's compliance automation features include a pre-built ISO 27001 SoA framework mapped to the 2022 Annex A controls, with automated evidence collection, control ownership assignment, and implementation status tracking. Instead of manually hunting for evidence across shared drives and email threads, your team gets a centralized, audit-ready SoA that updates in real time as controls are implemented.

For SMBs comparing approaches, our platform comparison page shows how ComplyGuard stacks up against manual spreadsheet-based compliance and traditional consulting engagements — including the time and cost differences that matter most to resource-constrained teams.

The NIST SP 800-53 control framework is another useful reference for organizations that need to align ISO 27001 controls with US federal security standards, particularly if you serve government customers or operate in regulated industries.

Conclusion

The ISO 27001 Statement of Applicability is not a bureaucratic formality — it is the strategic core of your Information Security Management System. Done well, it demonstrates to auditors, customers, and partners that your organization makes deliberate, risk-informed security decisions. Done poorly, it becomes the single document most likely to derail your certification. For SMBs, the key is building an SoA that is genuinely connected to your risk assessment, maintained as a living document, and supported by real implementation evidence rather than aspirational checkboxes.

If you are ready to stop wrestling with spreadsheets and build an audit-ready SoA in a fraction of the time, ComplyGuard was built for exactly this challenge. Talk to our compliance team to see how we help SMBs achieve ISO 27001 certification faster and with greater confidence — or explore our pricing to find the plan that fits your organization's size and budget.

ISO 27001 Statement of Applicability: A Complete SMB Guide