ISO 27001: How to Write a Statement of Applicability

You need a Statement of Applicability for an ISO 27001 certification. This guide will help you identify key requirements and outline steps to create and maintain your SoA effectively.

Key Takeaways

• A Statement of Applicability (SoA) is a mandatory ISO 27001 document that lists all 93 Annex A controls, indicating which are implemented, excluded, and why.
• Your SoA bridges your risk assessment to your security controls, showing auditors and stakeholders exactly how you manage information security risks.
• Creating an effective SoA requires conducting a risk assessment, defining a risk treatment plan, mapping controls to risks, and maintaining the document as your business evolves.
• Drata automates evidence collection and control monitoring, making it faster to build, maintain, and audit your Statement of Applicability alongside your broader ISMS.

What Is an ISO 27001 Statement of Applicability?

An ISO 27001 Statement of Applicability (SoA) is a mandatory document that lists all 93 Annex A controls and justifies why each is included or excluded based on your risk assessment. It is a core requirement for certification and serves as the bridge between your risk assessment and your implemented security controls. The SoA demonstrates to auditors and stakeholders that your security program is based on a thoughtful, risk-based approach.

The 2022 update to ISO 27001 restructured Annex A, consolidating controls from 114 to 93 and reorganizing them into four categories:

• A.5 Organizational (37 controls): Covers company-wide processes like access control and incident response.
• A.6 People (8 controls): Addresses how employees interact with information, including security training and remote work.
• A.7 Physical (14 controls): Protects your physical environment, such as offices and data centers.
• A.8 Technological (34 controls): Focuses on systems and infrastructure, covering topics like vulnerability management and backups.

What Does a Statement of Applicability Look Like?

An SoA typically takes the form of a structured table or spreadsheet. This format provides a clear, scannable overview for auditors and internal teams.

Key Components of an SoA Document

For each of the 93 Annex A controls, your SoA should include:

• Control ID and Name: The specific reference number (e.g., A.5.1) and official title.
• Implementation Status: Whether the control is Implemented, Planned, or Not Applicable.
• Inclusion/Exclusion Decision: A clear statement on whether you are applying the control.
• Justification: Risk-based reasoning for your decision, referencing specific threats or business context.
• Supporting Evidence: Links to policies, procedures, or system configurations that prove the control is working.

SoA Format and Template Structure

Most organizations use a spreadsheet with one row per control. The document should be detailed enough that an auditor can quickly understand your security posture without needing additional explanation.

Why the Statement of Applicability Matters

It Builds Confidence in Your Security Framework

Your Statement of Applicability tells the story of how your organization approaches security, and whether that approach is intentional, risk-based, and aligned with customer expectations. It builds trust with everyone who depends on your systems:

• Customers can see that you're applying controls that match the sensitivity of their data.
• Partners understand how you protect shared infrastructure or integrations.
• Regulators or auditors get a justification for every inclusion or exclusion.

A vague or incomplete SoA raises red flags, while a detailed, well-reasoned SoA gives external parties the confidence that you know your risks and you've selected controls to address them.

In competitive sales cycles, especially in SaaS or B2B tech, being able to share or reference your SoA (in full or in part) can help unblock deals by answering security questions proactively.

It Simplifies the Audit Process

Audits are time-consuming, even more so when auditors have to piece together control decisions from scattered documents, emails, or tribal knowledge. The Statement of Applicability acts as a control roadmap that shows auditors:

• Which controls you've implemented.
• Why those controls were selected or excluded.
• How they tie back to specific risks or compliance requirements.

This makes both internal audits and certification audits more efficient, cutting down the time and effort necessary to verify your security practices and maintain (or get) your certification.

It Enables Risk-Based Decision-Making

Each control in your SoA traces back to a specific risk identified in your risk assessment. That traceability allows leadership and security teams to make smarter, faster decisions based in context.

For example:

• If a new service provider or product introduces sensitive data flows, the SoA helps identify which specific controls need to be added or updated.
• If budget constraints arise, decision-makers can prioritize controls that mitigate the most impactful risks instead of spreading resources thin.
• During mergers, expansions, or regulatory changes, the SoA can be a reference point for evaluating how risk posture changes and where control coverage might fall short.

Over time, this helps you build a proactive compliance program and grounds your business strategy in security.

It Strengthens Alignment Across Teams

Controls touch nearly every function in your company, whether it's HR onboarding, vendor reviews, or infrastructure deployments.

The SoA helps unify these moving parts, documenting which teams own which controls, what each control is meant to address, and why it matters from a risk and business perspective.

The alignment is especially valuable when:

• Multiple teams are involved in control execution (e.g., engineering and compliance both play roles in access control).
• Something goes wrong (e.g. a missed patch, failed backup, or delayed access review) and teams need to understand how that maps back to the Information Security Management System (ISMS).
• New team members or function leads need to see how their role fits into the larger risk and compliance landscape.

It's a Tool for Continuous Improvement

Your SoA is a living document designed to evolve with your business, systems, and threat landscape.

As your organization scales or shifts (e.g., new products, new regions, new partners), so do your risks. The SoA helps you stay aligned by serving as a regular check-in on what's still working, what's outdated, and where gaps are forming:

• Regular reviews surface controls that are no longer effective, needed, or properly implemented.
• Control exclusions can be reevaluated if new risks emerge or technologies change.
• New risks (like those from a third-party breach or a regulatory update) can trigger targeted updates to your SoA without a full overhaul of your ISMS.

Auditors often look for signs that your program is evolving, and an up-to-date SoA shows that you're actively improving compliance over time.

Which Controls Should You Include in Your Statement of Applicability?

The controls you include should directly address the risks identified in your organization's risk assessment and meet your compliance needs. While the applicable controls will vary depending on your organization's unique context, the process for selecting and documenting them remains consistent.

ISO 27001:2022 provides more flexibility in choosing controls that best fit your organization's current context and business priorities. It encourages a more tailored approach to selecting controls that are proportional to the risks and potential impacts faced by the organization. Since there is more flexibility, the 2022 version requires a clearer justification of how controls address not only the identified risks but also the organization's business objectives and strategic context.

For example, controls in the Physical Security domain (A.7) apply to organizations with physical offices. Meanwhile, controls in the Access Control domain (A.5 and A.8) are critical for managing user permissions, especially in remote or hybrid workforces.

Commonly included controls:

• A.5.1 - Policies for information security: Establishes the foundation for governance.
• A.5.15 - Access control: Manages who can access systems and data.
• A.8.1 - User endpoint devices: Secures laptops, mobile devices, and workstations.
• A.8.9 - Configuration management: Ensures systems are securely configured.

Commonly excluded controls (with justification):

• A.7.4 - Physical security monitoring: For fully cloud-based organizations with no physical infrastructure.
• A.7.11 - Supporting utilities: When operating in cloud environments where providers manage power and HVAC.

"We haven't implemented it yet" or "it's too expensive" are not valid reasons for exclusion. Each justification must clearly explain the rationale behind your decision, referencing specific risks or business context. The explanation should be concise and directly traceable to your risk assessment.

How to Create Your Statement of Applicability: 6-Step Process

Here's a breakdown of the steps you'll need to take to put together an SoA for your organization.

Step 1: Understand the Requirements

Before you start writing your SoA, you need to understand what it actually needs to include and why it matters. At a minimum, your Statement of Applicability should document:

• All 93 controls from ISO 27001:2022 Annex A.
• Whether each control is included or excluded.
• A justification for each decision.
• The implementation status of the included controls.
• References to supporting documentation or systems (where applicable).

If you're still using the 2013 version of ISO 27001, you'll need to update your SoA to match the streamlined 2022 structure (which reorganized and merged many controls into four main categories).

Step 2: Conduct a Comprehensive Risk Assessment

Your SoA begins with a risk assessment to evaluate information security risks that could harm your organization. If you have already completed this, use the identified risks as your starting point. If not, you will need to select an appropriate methodology.

Choose Your Methodology: Your risk assessment should be tailored to your organization. Common approaches include qualitative (categorizing risk from low to high) or quantitative (calculating monetary loss). Frameworks like ISO 27005 and NIST SP 800-30 can provide guidance.

Get Expert Guidance: If you lack in-house expertise, consider hiring a consultant. They can help identify industry-specific threats and suggest strategies to form your plan.

Step 3: Define Your Risk Treatment Plan

Once risks are identified, you must create a risk treatment plan. This plan documents how you will respond to each risk and directly informs which controls you will implement in your SoA.

For each risk, choose one of four treatment options:

• Mitigate: Apply controls to reduce the risk.
• Avoid: Change processes to eliminate the risk.
• Transfer: Shift the risk to a third-party, like through insurance.
• Accept: Acknowledge the risk if it's low-impact or not cost-effective to mitigate.

Step 4: Map Annex A Controls to Your Identified Risks

Now, you will map the 93 Annex A controls to your identified risks. For each control, decide whether to include or exclude it based on your risk treatment plan. The necessary controls will be unique to your organization's industry and risk profile.

Step 5: Document Each Control Decision in Your SoA

At this point, you have everything you need to put your Statement of Applicability together. Your SoA should include the following for all 93 controls in ISO 27001 Annex A:

• Control ID: As listed in ISO 27001:2022.
• Control name: Use the official name from the standard.
• Implementation status: Note whether it's Implemented, Planned, or Not Implemented.
• Justification: A brief, risk-based explanation for inclusion or exclusion.
• Control owner: Role or person responsible.
• Implementation date: When the control was implemented.
• Reference (optional but helpful): Point to linked documentation, policies, or tools.

Step 6: Review and Maintain Your SoA Regularly

Your SoA is a living document that requires regular review. You should update it at least annually or whenever significant business or risk changes occur. Aligning your SoA review with your annual risk assessment makes updates smoother.

How Drata Simplifies Statement of Applicability Management

Creating and maintaining an SoA manually is time-consuming and error-prone. Drata transforms this process from a static documentation exercise into continuous, automated compliance.

Automated Control Monitoring: Drata continuously monitors your security controls, automatically collecting evidence and testing their effectiveness in real-time. This ensures you maintain audit-ready documentation year-round.

Risk-to-Control Traceability: Our platform connects your risk register directly to your SoA, creating clear traceability between risks and controls. This simplifies justifying control decisions to auditors.

Multi-Framework Efficiency: Drata maps overlapping controls across frameworks like SOC 2 and GDPR. This allows you to manage a unified set of controls that satisfies multiple requirements simultaneously.

Ready to automate your SoA and streamline ISO 27001 compliance? See how Drata can help.

Frequently Asked Questions

What does a statement of applicability look like?

An SoA is typically a spreadsheet listing all 93 Annex A controls, your inclusion or exclusion decision for each, and a risk-based justification, creating a scannable roadmap of your security posture.

How often should the SoA be updated?

You should review and update your SoA at least annually, or whenever significant business changes, new risks, or security incidents occur.

How detailed should control justifications be?

Justifications should be concise but clear, stating the specific risk a control mitigates or explaining why an excluded control is not applicable to your business.

What if an auditor questions a control decision?

If an auditor questions a decision, refer back to your risk assessment to provide a clear, logical explanation for why the control was included or excluded based on your specific risks.

Is a Statement of Applicability required under ISO 27001?

Yes, the Statement of Applicability is a mandatory requirement for ISO 27001 certification, as outlined in clause 6.1.3(d) of the standard.

What is the statement of applicability for ISO 27017?

ISO 27017 is a cloud-specific extension of ISO 27001, and it requires its own SoA to document the applicability of its additional cloud security controls.

What are common mistakes when creating a Statement of Applicability?

Common mistakes include using generic justifications, failing to update the document regularly, and not aligning control decisions with the risk assessment.

Can I use my Statement of Applicability for other compliance frameworks?

Yes, while the SoA is for ISO 27001, its controls often overlap with frameworks like SOC 2 and GDPR, and platforms like Drata can automate this mapping to save time.