
What's Inside
You need a Statement of Applicability for an ISO 27001 certification. Here's a quick guide to make the process as stress-free as possible.
ISO 27001: How to Write a Statement of Applicability
You need a Statement of Applicability for an ISO 27001 certification. Here's a quick guide to make the process as stress-free as possible.
Get Started With Drata
Cyber incidents are the leading risk to businesses globally for 2025, according to a survey among risk management experts. This includes things such as cybercrime, IT failure or outages, data breaches, and fines and penalties.
All of this isn’t great news for your data or for your business.
For these and many reasons, companies are choosing to pursue ISO 27001 certification. ISO 27001 can help you mitigate risks, establish a strong security posture, and build trust with customers who have growing concerns about their information.
A major component in pursuing ISO 27001 certification is your Statement of Applicability (SoA). If you’re not sure where to begin, consider this article your quick start guide to make the process as stress-free as possible.
A Statement of Applicability is a document required for ISO 27001 certification. It states the ISO 27001 Annex A controls that your organization determined to be necessary for mitigating information security risk and the controls that were excluded (and why).
With the 2022 update to ISO 27001, Annex A was restructured, consolidating information security controls from 114 to 93 and reorganizing them into four categories:
A.5 Organizational (37 controls): Cover company-wide processes like asset management, vendor risk, access control, data protection, and incident response.
A.6 People (8 controls): Address how employees and contractors interact with information, covering things like background checks, security training, remote work, and reporting incidents.
A.7 Physical (14 controls): Protect your physical environment, including offices, data centers, hardware, storage devices, and cabling.
A.8 Technological (34 controls): Focus on systems, software, and infrastructure, covering topics like vulnerability management, backups, secure development, and data loss prevention.
No controls were removed, but some have been merged and revised, and new ones introduced to address emerging security challenges.
The SoA is a blueprint for your organization’s approach to information security, tying risks to the controls you’ve selected or excluded. A Statement of Applicability simplifies audits, demonstrates your commitment to managing risks, and builds trust with stakeholders who care about data security.
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.
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.
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.
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.
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.
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 under the Physical and Environmental Security domain (Annex A11) might apply to organizations with physical offices that need to secure server rooms or prevent unauthorized access to facilities. Meanwhile, controls under the Access Control domain (Annex A9) are more relevant for managing user permissions and safeguarding sensitive digital information assets, especially in businesses with remote or hybrid workforces.
"We haven't implemented it yet" or "it's too expensive" aren't valid reasons for exclusion. Each justification should clearly explain the rationale behind the selection or exclusion of a control, referencing specific risks, business context, and regulatory requirements. The explanation should be concise, easy to understand, and directly traceable back to the risk assessment and treatment decisions, allowing auditors to easily follow the reasoning behind each decision.
Here’s a breakdown of the steps you’ll need to take to put together an SoA for your organization.
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).
To begin the process of writing an ISO 27001 Statement of Applicability, you will need to conduct a risk assessment. The purpose of this step is to evaluate the information security risks that could pose harm or loss to your organization.
If you have already completed the assessment, use the identified risks as a starting point. If not, start by:
Your risk assessment should be tailored to your organization’s environment and circumstances. In other words, you should choose a risk assessment methodology that gathers the information you need about the particular vulnerabilities and risks affecting your company.
Most risk assessments can follow a qualitative approach which uses judgment to categorize risks on a low to high scale of probability, or quantitative, which uses mathematical formulas to calculate expected monetary losses of certain risks. These methodologies can also be combined with other methods like asset-based or threat-based.
Both ISO 27005 and NIST SP 800-30 standards can provide guidance for determining the most appropriate risk methodology.
If you don’t have a cybersecurity expert on your team, you could hire a consultant to help identify threats that could affect your organization’s ability or success in achieving its goals. They may suggest strategies or tools they’ve used when working with companies in your industry which can help form your own plan.
Again, this can be particularly useful if you’re a new organization or don’t have much experience with risk assessments. Getting input from others can help create a more complete risk profile.
This is the point where you decide how to respond to the risks you identified in the previous step. That’s your risk treatment plan, and it directly informs which controls appear in your SoA.
For each identified risk, choose one of four treatment options:
Mitigate: Apply controls to reduce the risk (e.g., implement MFA for unauthorized access).
Avoid: Change your processes to eliminate the risk altogether (e.g., stop collecting sensitive data).
Transfer: Shift the risk to a third party (e.g., through cyber insurance or outsourcing).
Accept: Acknowledge the risk if it’s low-impact or not cost-effective to mitigate.
This plan doesn’t need to be long, but it has to be specific. Each risk should have a treatment strategy, responsible parties, and a timeline for implementation.
Now your Statement of Applicability begins to take shape. You’ll go through each of the 93 Annex A controls and decide whether to include or exclude them based on the risks you've identified and how you plan to treat them.
Every company is different, and that means the necessary controls may be unique to your organization or industry. If you run a large manufacturing business with multiple warehouses where inventory is always being shipped out or returned to storage, then physical access control could be part of your ISO 27001 certification process.
However, other companies may find that they don’t face many physical security risks and that another set of controls are at the top of their priority list.
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.
Below is an example of what a SoA can look like on a spreadsheet:
Once you’ve completed your Statement of Applicability, you’ll need to keep a close eye on it. You should regularly review the document to ensure that you’re still meeting the requirements described in the standard.
Review and update your SoA:
Annually, at minimum.
After a major business change (e.g., expansion, M&A, cloud migration).
When new risks are identified or old ones change in impact.
Following incidents that expose control weaknesses.
After internal or external audits that surface gaps or recommendations.
Schedule your SoA review to align with your annual risk assessment. Keeping those processes in sync makes updates smoother and strengthens your compliance posture overall.
Manually tracking 93 controls, tying them to risks, and updating them over time is complex and thus, easy to get wrong.
Drata simplifies it. We automatically map your risks to ISO 27001 controls, track implementation status, and keep your Statement of Applicability up to date through continuous monitoring.
With Drata, you can:
Generate a defensible, audit-ready SoA in less time.
Automatically update control statuses as your environment changes.
Maintain clear documentation tied to evidence, policies, and owners.
Collaborate with auditors in-platform through our dedicated Audit Hub.
The Statement of Applicability (SoA) often raises practical questions, particularly for organizations navigating ISO 27001 for the first time. Below we answer some of the most common questions to help you demystify the process.
The ISO 27001 SoA is a core document required for ISO 27001 certification. It outlines which Annex A controls your organization has chosen to implement, which controls have been excluded, and the justification for each decision.
The SoA serves as a bridge between your risk assessment and the controls in place. It’s typically reviewed by auditors and, later, a certification body to ensure your ISMS is aligned with ISO 27001 requirements and reflects a thorough risk management process.
ISO 27001:2022 is the latest version of the international standard for information security management systems. The update introduces a simplified structure for Annex A, consolidating controls into four categories: Organizational, People, Physical, and Technological.
The revised standard emphasizes a risk-based approach to security, requiring organizations to tailor their ISMS to their specific needs.
It’s important to review and update the SoA yearly. Additional triggers for review would include:
Significant changes in business operations, technology, or personnel.
New or evolving risks. Regulatory changes or new compliance requirements.
Following the results of internal or external ISO 27001 audits.
After a security incident or breach.
After conducting a risk assessment or treatment process.
Many organizations align their SoA updates with annual risk assessments or other periodic compliance activities. Regular updates ensure that your SoA reflects your current risk landscape and continues to meet ISO 27001 requirements.
Justifications don’t need to be overly detailed, but they must be clear and focused. For included controls, state the specific risks they address and how they contribute to mitigating those risks. For exclusions, explain why the control isn’t applicable or how other measures achieve the same objective.
For instance, when including encryption as a control, specify that it mitigates the risk of data breaches. When excluding physical security measures, note that the organization operates entirely in the cloud, which eliminates physical access risks.
If an auditor disagrees with your inclusion or exclusion of a control, they will likely ask for additional context rather than outright reject your SoA. A clear and logical explanation of your risk-based decision-making process usually resolves such issues.
To minimize the likelihood of this scenario, clearly explain how the decision was based on the organization’s risk assessment and business context. You should justify why a control was included or excluded by linking it to specific risks, compliance requirements, and operational needs.
Yes, the Statement of Applicability (SoA) is a mandatory requirement under ISO 27001. Specifically, it’s outlined in clause 6.1.3(d) of the standard.
To comply, your organization has to:
Create an SoA that lists all Annex A controls.
Specify whether each control is included or excluded.
Provide a justification for each decision.
Indicate the implementation status of included controls.
Writing an SoA follows a general six-step process:
Conduct a risk assessment, during which you identify the threats, vulnerabilities, and potential impacts to your organization.
Create a risk treatment plan to decide how you'll address each risk (mitigate, avoid, transfer, or accept).
Review all 93 Annex A controls and, for each one, determine if it’s relevant to your risks and operating environment.
Decide whether each control is included or excluded.
Justify the decision for each inclusion or exclusion, tying it to specific risks, regulations, or business needs.
Note whether each included control is fully implemented, planned, or not yet in place.
Organize your SoA in a consistent table format so it’s easy to review and maintain.
Keep Reading
Take Your Learning Further
Discover research, playbooks, checklists, and other resources on ISO 27001 compliance.