When organizations pursue ISO 27001 certification, few documents are more critical or more misunderstood than the Statement of Applicability (SoA). It is the single, authoritative bridge between what your risk assessment says you should do and what your company actually does to protect data.
Think of the SoA as your master control list. It shows auditors, management, and customers which of the 93 Annex A controls your organization has chosen to implement, which are excluded, and why.
A well-built SoA turns a compliance checklist into a living roadmap for your Information Security Management System (ISMS). A sloppy one, on the other hand, raises red flags, slows audits, and weakens your security credibility.
What the Statement of Applicability Really Is
Clause 6.1.3 (d) of ISO/IEC 27001:2022 requires every certified organization to create a Statement of Applicability.
Definition: The SoA is a document that lists every control in Annex A of ISO 27001, specifies whether each control is applicable or not applicable to your organization, provides a justification for that decision, and records the implementation status of applicable controls.
In practice, it serves four main purposes:
Traceability
It connects your risk assessment and risk treatment plan to the actual controls chosen to mitigate those risks.
Transparency
It shows auditors how each risk, regulation, or business requirement is addressed or why a certain control was excluded.
Accountability
It assigns ownership and responsibility for each control.
Audit Evidence
It becomes the auditor's reference map for testing and verifying your ISMS.
If your ISO 27001 project were a courtroom, the SoA would be your sworn testimony. Every control decision, every rationale, and every implemented safeguard must be clear and defensible.
Why the SoA Matters So Much
a) It Is Mandatory
Without a compliant SoA, you cannot pass certification. Auditors expect to review it during Stage 1 and test its accuracy during Stage 2.
b) It Defines Your Audit Scope
Your SoA shows auditors the boundaries of your ISMS and the controls that fall within those boundaries. It is effectively the blueprint of your security architecture.
c) It Demonstrates a Risk-Based Approach
ISO 27001 does not require every possible control. It expects organizations to apply what is relevant based on risk. The SoA proves that your decisions were logical, structured, and risk-based.
d) It Builds Confidence with Stakeholders
Customers and partners often request a copy or summary of your SoA to verify that your ISO 27001 certification actually covers the systems and data that matter to them. A clear, well-reasoned SoA builds trust and shortens sales cycles.
e) It Enables Continuous Improvement
Because it must be reviewed and updated regularly, the SoA becomes your ongoing tool for tracking progress, identifying outdated controls, and improving maturity over time.
The Backbone: Annex A of ISO 27001:2022
In the 2022 update, Annex A was modernized from 114 controls across 14 domains to 93 controls grouped into four categories:
| Group | Focus | Number of Controls |
|---|---|---|
| A.5 | Governance, risk management, supplier security, incident response, compliance | 37 |
| A.6 | People: Screening, awareness, training, responsibilities | 8 |
| A.7 | Physical: Facility protection, secure areas, equipment security, remote work | 14 |
| A.8 | Technological: Access control, encryption, logging, software development, cloud security | 34 |
Each control represents a potential safeguard your organization can adopt, but ISO 27001 expects you to justify inclusion or exclusion logically.
What Must Be in Your SoA
Every SoA should include at least the following fields:
| Field | Description |
|---|---|
| Control ID | The official Annex A reference (for example, A.8.11). |
| Control Name | The full title from the ISO 27001 standard. |
| Applicability | Applicable or Not applicable. |
| Justification | Reason for inclusion or exclusion, tied to risk or business context. |
| Implementation Status | Implemented, Planned, or Not Implemented. |
| Control Owner | The role or department responsible for the control. |
| References | Links to policies, procedures, tickets, or system evidence. (Optional) |
| Date / Version | Track changes for version control. |
Missing even one control will result in a non-conformity during audit.
Ready to Implement ISO 27001?
Enter your email to receive a free ISO 27001 checklist and start your compliance journey today.
How to Build Your Statement of Applicability in 6 Steps
Step 1: Conduct a Risk Assessment
Your SoA starts with understanding what could go wrong. Identify your information assets, the threats and vulnerabilities they face, and assess each risk's likelihood and impact. Frameworks like ISO 27005 or NIST SP 800-30 can guide you.
The outcome is a ranked list of risks that your ISMS must address.
Step 2: Create a Risk Treatment Plan
For each risk, decide whether to:
- •Mitigate it with controls.
- •Avoid it by changing the process.
- •Transfer it, for example through insurance or outsourcing.
- •Accept it if it is low enough.
Your chosen treatments feed directly into which controls you will include in the SoA.
Step 3: Review All 93 Annex A Controls
Go through each control systematically and decide:
- •Does this control mitigate a risk we identified?
- •Is it required by law, regulation, or contract?
- •Does it align with our business context and risk appetite?
Mark each as Applicable or Not Applicable. Even excluded controls must appear with justification.
Step 4: Justify Every Decision
This is where most organizations fail. "We don't need this" is not a justification. Your explanation must show why the decision makes sense in light of your risk assessment and operations.
| Control | Applicability | Justification |
|---|---|---|
| A.7.4 Physical Security | Not Applicable | All company infrastructure is hosted on AWS. No physical servers or data centers are managed internally. AWS certifications cover physical security. |
| A.8.11 Data Masking | Applicable | Mitigates the risk of exposing PII in lower environments. Implemented via anonymization scripts in CI/CD pipeline. |
Auditors look for concise, defensible logic. Clarity matters more than length.
Step 5: Approve and Record Ownership
Your SoA must be formally approved by senior management. Their sign-off proves leadership commitment, which is required under clause 5. Assign control owners who are accountable for implementation and evidence upkeep.
Maintain version control and change logs. If the SoA evolves, auditors must see what changed and why.
Step 6: Maintain and Review Regularly
Treat your SoA as a living artifact. Review it:
- •At least once a year.
- •After any major organizational or technical change.
- •After security incidents or audit findings.
- •When new legal or contractual obligations arise.
Link the review cycle to your risk assessment so both evolve together.
Common Pitfalls and How to Avoid Them
Pitfall 1: Marking all 93 controls as applicable
That defeats the purpose of ISO 27001 and invites scrutiny. Select controls that fit your actual environment.
Pitfall 2: Generic justifications
"We don't do this" or "handled by IT" is not acceptable. Reference risks, regulations, or assets.
Pitfall 3: Missing management approval
Auditors require proof of leadership review, such as a signature or electronic approval record.
Pitfall 4: No version history
Your SoA should show evolution. Keep each revision dated and archived.
Pitfall 5: Treating it as paperwork only
If teams cannot explain how a listed control works, you will fail the Stage 2 audit.
SoA vs. Risk Assessment Report
While they are related, they serve different purposes:
| Aspect | Risk Assessment Report | Statement of Applicability |
|---|---|---|
| Purpose | Identifies and evaluates risks. | Documents controls chosen to address those risks. |
| Focus | Risks and their treatment options. | Controls and their applicability. |
| Detail | Often lengthy and technical. | Concise, tabular summary for auditors. |
| Frequency | Reviewed annually or when the risk landscape changes. | Reviewed alongside the risk assessment. |
Together they form the backbone of your ISMS documentation. One defines why you need controls, the other shows which ones you applied.
ISO 27002: The Companion Standard
ISO 27002 complements ISO 27001 by providing practical guidance on how to implement each Annex A control. While ISO 27001 defines what must exist, ISO 27002 explains how to apply it effectively. Using ISO 27002 strengthens your justifications and shows auditors that your reasoning aligns with industry best practice.
Modernizing the SoA: From Spreadsheet to Automation
Manually tracking 93 controls, evidence, and updates in spreadsheets is not sustainable. The modern approach is to manage your SoA in a compliance automation platform that:
- Maps risks and Annex A controls automatically.
- Pulls evidence directly from systems like AWS, GCP, Azure, GitHub, and HR tools.
- Flags when controls fall out of compliance.
- Generates real-time audit-ready reports.
This approach reduces manual effort and transforms your SoA from a static document into a live dashboard of control health.
Example of a Strong Statement of Applicability Entry
| Control ID | Name | Applicable | Justification | Status | Owner | Reference |
|---|---|---|---|---|---|---|
| A.8.9 | Configuration Management | Yes | Prevents misconfigurations in cloud services that could expose sensitive data. Supports CIS Benchmarks and SOC 2 mapping. | Implemented | DevSecOps Lead | Terraform Baseline v3 Policy |
| A.7.3 | Securing Offices, Rooms and Facilities | No | Fully remote organization with no physical office space. Laptops are encrypted and monitored via MDM. | N/A | IT Manager | BYOD Policy 2025 |
Auditors prefer clear, factual statements backed by references.
How the SoA Strengthens Your Business
A strong SoA does more than pass audits. It drives business results:
Faster enterprise sales
Security questionnaires and vendor assessments become simple because your SoA already answers them.
Smarter resource allocation
Knowing which controls mitigate which risks helps leadership invest in what matters most.
The SoA as a Living Strategy Document
Mature organizations treat the SoA as an operational tool, not just an audit artifact.
Use it to:
- Drive quarterly security objectives and KPIs.
- Track control maturity and automation levels.
- Link budget requests to specific risk reductions.
- Onboard new team members and clarify accountability.
Your SoA becomes a daily reference for how your company protects information and upholds trust.
Final Thoughts
The Statement of Applicability is the heartbeat of ISO 27001. It connects vision to action, risk to control, and intent to evidence.
When built properly, it saves time, reduces confusion, and ensures your ISMS runs on facts instead of assumptions. When ignored, it exposes gaps and stalls certification.
In 2025, with investors, customers, and regulators demanding continuous proof of security, your SoA is more than paperwork. It is your security reputation on record.
How Smartly Helps You Build and Maintain a Strong SoA
Creating an audit-ready Statement of Applicability does not need to consume months. Smartly makes it fast, accurate, and automated.
Generate your SoA instantly after onboarding. Smartly automatically maps applicable and non-applicable controls based on your company profile.
Reuse evidence from existing SOC 2 or security processes, cutting your preparation time by up to 80 percent.
Auto-update control status through integrations with AWS, Azure, Google Workspace, GitHub, and HR tools.
Assign owners and due dates for each control and track completion in real time.
Version and review easily, keeping full history for auditors.
Get certified faster. Smartly users often reach ISO 27001 readiness in under 90 days.
Your SoA should not live in a spreadsheet jungle. With Smartly, it becomes a live dashboard that reflects the true strength of your security program.
Build your ISO 27001 Statement of Applicability the smart way. Build it with Smartly.