Published on: Apr 27, 2021
ISO 27001: How to Establish Scope and Create a SoA
Implementing an ISO 27001 compliant information security management system (ISMS) following a checklist. Two foundational elements shape the strength and credibility of your ISMS: defining its scope and creating your Statement of Applicability (SoA).
The scope determines the boundaries of your ISMS, aligning it with your organization’s strategic goals, client expectations, and available resources. Get this step wrong, and you risk either overspending on unnecessary processes or leaving critical assets unprotected.
The SoA, on the other hand, is the operational blueprint of your ISMS. It not only lists the Annex A controls you’ve chosen to include or exclude but also provides justifications that tie directly to your risk assessment and business priorities. Together, these two elements set the stage for a system that is not only compliant, but also defensible, efficient, and tailored to your unique risk environment.
Conducting a Risk Assessment: The Foundation for an Effective SoA
Before you dive into drafting your Statement of Applicability, it’s essential to roll up your sleeves and carry out a comprehensive risk assessment. Think of this as mapping the terrain before you draw your battle lines: you need to understand what risks loom on the horizon before you can decide which security controls are necessary or relevant to your organization.
Why is this step so vital? Simply put, the SoA isn’t just a checklist you tick off for auditors. It’s a direct reflection of your environment, your data, and your business goals. By first identifying and evaluating the security risks unique to your operations (whether you’re in fintech, health tech, or good old-fashioned widgets), you’ll be in a much stronger position to:
Anchor every selected (or excluded) control to real-world needs, not guesswork.
Prioritize controls that actually address your highest threats, without wasting resources on irrelevancies.
Set the groundwork for communicating to stakeholders and auditors that every inclusion or exclusion was a reasoned decision, not a shot in the dark.
There’s no one-size-fits-all approach here. You can follow qualitative methods for a nuanced, judgment-based view of likelihood and impact; or go quantitative for hard numbers, estimated losses, and cost-benefit clarity. Whether you reference industry standards like ISO 27005 or NIST SP 800-37, the important thing is to choose a methodology that matches your organization’s complexity and risk appetite.
If you’re new to risk assessments or light on in-house expertise, this may be a good time to bring in a seasoned consultant for a second set of eyes. Tapping into the experience of others can help ensure you’re not missing threats (or opportunities to streamline) as you proceed.
Taking the time to get this step right translates to a Statement of Applicability that’s not only compliant, but credible and actionable, positioning your ISMS as a living, breathing shield tailored to your reality.
Establishing Scope: the Heart of Your ISO Program
Having a well-formulated plan can make or break a project and implementing an ISO 27001 compliant ISMS is no different. Establishing the Scope of your ISMS is undoubtedly the most important step when implementing an ISO 27001 certified system. Your ISMS scope must be aligned with your organization's strategic objectives, clients' expectations, and available resources to successfully support your security initiative.
Scopes with excess breadth:
Can be overly expensive and time-consuming
Create unnecessary bureaucracy due to numerous processes and policies
Are hard to control (especially if your ISMS team is small)
Do not keep up with the pace of the changes (features, technologies, etc.)
Narrow scopes:
Will be unable to protect your data
Cannot satisfy the requirements of your clients
Hinder your ability to implement consistent processes and monitoring activities
Ideally, when scoping your ISMS, you must:
Establish the boundaries of your Security Policy
Include the teams and activities that directly manage and support your clients' data
Exclude physical locations and departments that do not represent or minimally create risks to confidential information
Consider the time and budget available for your ISO implementation and maintenance
When designing your ISMS, you must always consider the strategic decision behind involving top management and different internal stakeholders when adopting policies and mitigating processes. Additional security controls will be needed for larger scopes, and that can evolve systematically, and grow in maturity throughout the years.
Statement of Applicability (SoA)
Once you have defined your scope, you should be able to move forward with the primary evaluation of the Statement of Applicability (SoA). The SoA is a mandatory report that must be produced as evidence of the implemented ISMS. It represents the landscape of your ISO 27001 compliant system, as it outlines the Annex A areas that are included in the scope of your organization, as follows:
A.5. Information security policies
A.6. Organization of information security
A.7. Human resource security
A.8. Asset management
A.9. Access control
A.10. Cryptography
A.11. Physical and environmental security
A.12. Operations security
A.13. Communications security
A.14. System acquisition, development, and maintenance
A.15. Supplier relationships
A.16. Information security incident management
A.17. Information security aspects of business continuity management
A.18. Compliance
The Statement of Applicability is specifically required under ISO 27001, outlined in clause 6.1.3(d). To comply, your organization must:
Create an SoA that lists all Annex A controls.
Specify clearly whether each control is included or excluded.
Justify each decision, providing a clear rationale for inclusion or exclusion.
Indicate the implementation status of included controls.
Organizations must justify, based on the defined scope, why certain controls can be excluded from their ISMS. Documenting your justification is essential in case of a security breach. If you are being investigated for a data breach, the SoA is legally accepted as evidence of compliance protecting you from regulatory consequences.
The SoA serves as a living document throughout your ISMS lifecycle. Auditors will scrutinize it closely, expect them to ask why specific controls are omitted or how implemented controls align with your risk assessment. A well-constructed SoA not only demonstrates compliance but also strengthens your organization's ability to defend its information security decisions under regulatory review.
Mapping Annex A Controls to Identified Risks
As you build out your Statement of Applicability, the next step is to directly map the Annex A controls to the specific risks outlined during your initial risk assessment. This process is not simply about checking off every control but about thoroughly evaluating how each relates to the actual threats your organization faces.
No two organizations are identical so you must consider your business's unique risk landscape. For example, if your operations include multiple warehouse facilities, you might find physical access controls (A.11) are critical to reducing exposure to theft or unauthorized entry. On the other hand, a fully remote SaaS company may discover that controls around access management (A.9) and communications security (A.13) provide a more significant risk reduction.
Here’s a practical approach to mapping your controls:
Review each control in Annex A and determine its relevance to your organization’s identified risks.
Document whether each control is included or excluded, providing a rationale that ties directly to your risk management strategy.
Tailor your selection, while some controls will be universally applicable, others may be unnecessary based on your business processes, technology stack, or physical footprint.
The goal is to ensure that your chosen set of controls is neither excessive nor insufficient but rather provides a targeted response to your true areas of vulnerability. This focused approach ensures that your ISMS is both effective and efficient, supporting your compliance journey and safeguarding your organization in a way that makes strategic sense.
Selecting and Justifying Controls
The controls you include in your SoA should directly address the risks identified in your organization’s risk assessment and should align with your compliance requirements. ISO 27001:2022 provides more flexibility than earlier versions, allowing you to tailor your selection of controls to best fit your organization’s unique context and business priorities. This means your SoA should not only list which Annex A controls are included or excluded, but also provide clear, concise justifications that reference your risk assessment, specific business context, and any regulatory or contractual obligations.
For example, if you operate physical offices with sensitive equipment, you might include controls from the Physical and Environmental Security domain (Annex A.11) to address risks related to unauthorized access or environmental hazards. Conversely, organizations with a remote or hybrid workforce will likely focus more on Access Control (A.9) to protect digital assets and manage user permissions.
Remember, “We haven't implemented it yet” or “it's too expensive” are not considered valid reasons for excluding a control. Each justification should be easy for auditors to understand and directly traceable back to your assessment and treatment decisions. The rationale must demonstrate how each selected or excluded control addresses your organization’s risks and supports your broader business objectives.
Why Documentation Matters
Organizations must justify, based on the defined scope, why certain controls can be excluded from their ISMS. Documenting your justification is essential in case of a security breach. If you are being investigated for a data breach, the SoA is legally accepted as evidence of compliance protecting you from regulatory consequences.
Structuring Your SoA for Maximum Clarity
To ensure your Statement of Applicability remains clear and straightforward to maintain, it's best to present it in a logical, tabular format. This allows you to map each Annex A control directly to your organization's activities and document crucial details in one place.
A well-organized table typically includes columns for:
The control reference (e.g., A.5, A.6, etc.)
A description of each control
Whether the control is applicable within your defined scope
The justification for its inclusion, partial application, or exclusion
Implementation status or supporting documentation references
This structure not only simplifies internal reviews and audits but also streamlines future updates as your ISMS evolves. By keeping your information well-organized and transparent, you'll facilitate ongoing alignment between your security priorities and ISO 27001's requirements.
When to Review Your Statement of Applicability
A static Statement of Applicability (SoA) can quickly become outdated as your organization evolves. To ensure your SoA remains a true reflection of your current practices and risk environment, it's important to regularly revisit and revise it whenever key changes occur. You should consider reviewing your SoA in the following circumstances:
Significant organizational shifts: Mergers, acquisitions, cloud migrations, or major expansions often introduce new assets, risks, or processes into your environment.
Emergence of new risks or changes to existing risks: If your latest risk assessment identifies different threats, or the likelihood or impact of known risks changes, your control set and justifications may need to be revised.
Notable security incidents: Any event that reveals weaknesses in your existing controls or creates exposure should prompt a fresh look at your SoA.
Audit findings: Outcomes from internal audits or external reviews, especially when auditors flag gaps or suggest improvements, are an opportunity to re-evaluate the applicability of certain controls.
At least annually: Even in the absence of major change, a yearly review helps ensure ongoing alignment with your operational reality and compliance obligations.
For maximum efficiency, try to synchronize your SoA review with your annual risk assessment. This proactive approach ensures your information security management stays up to date and audit-ready, rather than scrambling to catch up when gaps are discovered later.
Keeping Your Statement of Applicability (SoA) Current
Just as defining an accurate scope underpins the success of your ISMS, maintaining an up-to-date Statement of Applicability (SoA) is fundamental to ongoing compliance. The SoA should not be a "set it and forget it" document. Instead, organizations are expected to review and update their SoA at least annually to ensure continued relevance to their current operating environment.
However, a yearly review isn't always enough. Several events can prompt the need for an immediate update to your SoA, including:
Significant changes to business processes, technologies, or organizational structure
The introduction of new risks, or changes in regulatory and compliance requirements
Outcomes or findings from internal or external ISO 27001 audits
Security incidents or breaches that reveal new vulnerabilities
Results from risk assessments or risk treatment activities
By aligning your SoA updates with these key triggers you guarantee that your documented controls remain a true reflection of your current risk profile and compliance obligations. Regular updates not only satisfy ISO 27001 requirements but also demonstrate your organization’s commitment to proactive security management.
SoA: Driving Ongoing Improvement
The Statement of Applicability (SoA) is a core tool for driving ongoing improvement within your information security management system.
Because threats, technologies, and business operations never stand still, your SoA should remain a dynamic document. As your organization grows (or pivots to new markets, introduces new products, or engages additional third parties), both your risks and your required controls will inevitably shift. By formally revisiting your SoA on a regular basis, you enable your team to:
Identify controls that need adjustment, replacement, or removal as business or regulatory needs develop.
Reassess previously excluded controls if they become necessary due to emerging risks, such as third-party vulnerabilities or evolving compliance obligations.
Incorporate lessons learned from incidents and audits, ensuring your ISMS adapts proactively rather than reactively.
Maintaining an up-to-date SoA signals to auditors, and to your own leadership, that information security is not a set-and-forget exercise, but a process of continual refinement and alignment with your organization’s goals. This proactive approach not only bolsters compliance, but also puts you on a path of mature, responsive risk management.
Aligning SoA Reviews with Your Compliance Processes
To maximize efficiency and ensure your ISMS remains robust, synchronize your Statement of Applicability (SoA) review with your annual risk assessment. By coordinating these activities, you minimize overlap, streamline updates, and maintain a clear record of your organization’s evolving risk landscape. This approach also makes it easier to incorporate changes in your environment or operations while reinforcing your overall compliance strategy.
Document any modifications and ensure all stakeholders are informed. This not only supports seamless audits but also fortifies your compliance narrative if ever challenged by regulators.
How to Build an Effective Statement of Applicability
Writing an SoA is more than just listing controls. It's a structured process that demonstrates your organization's intent and rationale behind each security measure. Here’s a practical approach you can follow:
Conduct a risk assessment: Identify threats, vulnerabilities, and potential impacts specific to your organization.
Create a risk treatment plan: Decide how each risk will be addressed, whether you’ll mitigate, avoid, transfer, or accept it.
Review all relevant Annex A controls: For each control, determine if it’s applicable to your risks and operational context.
Decide on inclusion or exclusion: Explicitly state whether each control is included or excluded from your ISMS.
Justify each decision: Provide sound reasoning for every control you include or exclude, referencing your risk assessment, legal obligations, or business need.
Indicate implementation status: Note whether each included control is fully implemented, planned for future implementation, or not yet in place.
Document in a clear, consistent format: Organize your SoA in a structured, table-based format that makes it easy to review and maintain over time.
By following these steps, your SoA becomes a living document that not only fulfills ISO 27001 requirements but also provides clear evidence of your decision-making process and ongoing commitment to information security.
What Risk Assessment Methodologies Can Organizations Use for ISO 27001 Compliance?
Once you've set the foundations for your ISMS, the next pivotal step is deciding how to approach risk assessment, a core requirement for ISO 27001 compliance. The chosen methodology should make sense for your organization's unique environment, resources, and security posture.
Organizations typically select from the following risk assessment approaches:
Qualitative Assessments
Quantitative Assessments
Vulnerability-Based Assessments
Asses-Based Assessments
Threat-Based Assessments
Hybrid Approaches
Remember, there's no one-size-fits-all solution. Choose the approach that best fits your scale, objectives, and available resources. A thoughtful assessment not only helps with compliance but provides the clarity needed to manage current and emerging security challenges effectively.
Key Takeaways
Building an ISO 27001–compliant ISMS is as much about strategic decision-making as it is about technical controls. Your scope defines what areas of the business your ISMS will protect, ensuring your efforts remain aligned with organizational objectives and resources. Your SoA then becomes the evidence-based map that shows how you’ve addressed risks, why certain controls are included or excluded, and how your decisions support ongoing compliance.
Key takeaways:
Start with scope: Align your ISMS boundaries with your business objectives, client needs, and capacity to manage controls.
Treat the SoA as a living document: Regularly review and update it to reflect changes in risks, operations, and compliance requirements.
Justify every decision: Clear rationales for control inclusion or exclusion demonstrate maturity and build auditor trust.
Integrate with risk management: The strength of your SoA depends on a thorough, repeatable risk assessment process.
By treating scope definition and the Statement of Applicability as interconnected pillars, you ensure your ISMS isn’t just compliant on paper but provides real, lasting protection against evolving risks.
