The Statement of Applicability (SoA) is one of the key documents in an Information Security Management System (ISMS) that complies with ISO 27001. However, its nature and role are often misunderstood, sometimes reducing this strategic document to a simple checklist.
In an ISMS compliant with ISO 27001, risk analysis plays a central role, particularly in supporting the Statement of Applicability, by justifying the inclusion or exclusion of controls from Annex A.
The DdA embodies the link between risk analysis, processing decisions, and the security controls actually implemented. It is the operational translation of the organization's strategic choices in terms of information security.
Without robust risk analysis, the SMSI becomes a collection of generic measures disconnected from the actual context of the organization. Conversely, a well-constructed DdA, informed by consistent risk analysis, allows efforts to be focused where they are truly necessary and proportionate.
Role of the DdA in an ISO 27001 ISMS
A key document of the WSIS
The Declaration of Applicability plays a central role in the WSIS documentary architecture. It lies at the intersection of several essential components:
- The scope of the SMSI : The DdA can only be established once the scope has been clearly defined and validated by management. This scope determines the field of application of the controls.
- Risk analysis: each control in Appendix A included in the DdA must be linked to one or more identified risks. This traceability ensures the consistency and relevance of security choices.
- The risk treatment plan: the DdA translates treatment decisions (reduction, acceptance, sharing, avoidance) into concrete operational controls.
- The WSIS Action Plan: the controls declared in the AoA directly feed into the annual action plan, with responsible parties, deadlines, and budgets.
Justify the inclusion and exclusion of controls
Annex A of ISO 27001 includes 93 security controls organized into four themes (organizational, people, physical, technological). The DdA must rule on each of them.
For each control, the organization must indicate:
- Whether or not it is applicable to the context and scope of the WSIS
- The rationale for this choice, based on risk analysis
- Implementation status (planned, in progress, deployed)
- The specific implementation procedures (person responsible, deadline, indicator)
Key point: The ISO 27001 auditor does not evaluate the "beauty" or sophistication of the method, but rather the overall consistency between the context, risk analysis, Statement of Applicability (SoA), and risk treatment plan.
An exclusion from control must be justified: why is this control not relevant in our context? What risk justifies this decision? This argument must be defensible in an audit.
A living document, not a static table
Too often, the DdA is seen as a document to be produced once, during the initial certification, and then filed away until the next audit. This approach leads to DdAs that are static, quickly become obsolete, and are disconnected from reality.
An effective DdA is a living document that evolves with the organization:
- When adding or removing systems within the scope
- Following security incidents revealing new risks
- Depending on regulatory or contractual developments
- During the minimum annual review of the SMSI
Any change to the risk analysis must result in a review of the DdA to ensure consistency.
From risk analysis to the DdA
Logical chaining
The construction of a coherent DdA is based on a rigorous logical chain:
- Risk identification: based on the established context (scope, essential assets, processes), risks are identified using scenarios that combine threats and vulnerabilities.
- Risk assessment: each risk is assessed in terms of impact and likelihood, allowing a risk level to be calculated (Risk = Impact × Likelihood).
- Risk classification: risks are classified (low, medium, high, major) according to defined acceptance thresholds, and their acceptability is determined.
- Treatment decisions: for each unacceptable risk, a treatment option is chosen (reduction, formal acceptance, sharing, avoidance).
- Selection of controls: Controls from Annex A that are relevant for reducing risks are identified and reported in the DdA.
This chaining ensures that each control declared meets a real, identified, and assessed need.
How risk scenarios guide the selection of controls
Let's take a concrete example to illustrate this chaining:
- Risk scenario: "Exploitation of a remote access misconfiguration by an external attacker leading to customer data compromise."
- Assessment: High impact (customer data = critical essential asset), Medium likelihood (numerous remote access points, partial measures). Risk = High.
- Treatment decision: Risk reduction through implementation of additional controls.
Selected controls from Appendix A:
- A.5.15: Access control
- A.5.18: Access rights
- A.8.5: Secure Authentication
- A.8.20: Network supervision
These controls are declared applicable in the DdA, with explicit justification: "To reduce the risk of compromising customer data via remote access."
Traceability and consistency
This traceability is essential for several reasons:
- Defending audit choices: the auditor will verify consistency between identified risks and selected controls. An audit plan that is disconnected from the risk analysis will be challenged.
- Prioritize actions: not all controls are equal. Those that address high risks should be deployed as a priority.
- Updating the SMSI: when a new risk emerges, new controls can be added to the DdA. Conversely, if a risk disappears, certain controls may no longer be applicable.
- Communicating with stakeholders: the DdA translates risk analysis into operational language that can be understood by business units and management.
DdA, risk treatment plan, and SMSI action plan
Three levels of articulation
The DdA does not exist in isolation. It is part of a coherent documentary trilogy:
Level 1: Risk analysis (the "why")
- Risk identification and assessment
- Qualification according to acceptance thresholds
- Risk-based treatment decisions
Level 2: DdA (the "what")
- Selection of controls from Appendix A
- Justification based on the risks to be addressed
- Declaration applicable/not applicable
Level 3: WSIS Action Plan (the "how")
- Concrete actions for implementing controls
- Responsible parties, deadlines, budgets, indicators
- Monitoring progress and obstacles
From treatment decision to concrete action
Let's return to the previous example to illustrate this passage:
- Risk treatment plan (strategic level): "Reduce the risk of customer data compromise by strengthening remote access controls."
- DdA (tactical level): "Control A.8.5 (Secure Authentication) declared applicable, status: currently being deployed, justification: risk R-042 Compromise of customer data."
- WSIS Action Plan (operational level): "Action #12: Deploy MFA on all remote access points. Responsible: CIO. Deadline: Q2 2026. Budget: €15k. Indicator: % of users with active MFA."
This direct link ensures that every action is justified by a risk, and that every unacceptable risk is addressed with concrete action.
Full traceability of the SMSI
This articulation allows for complete traceability:
- Each DdA control can be linked to one or more risks.
- Each unacceptable risk is subject to a treatment plan.
- Each treatment decision is translated into monitored and measured actions.
The tool thus becomes a governance support, rather than a simple document production tool. It provides management and the CISO with a consolidated and up-to-date view of risks, enabling them to make objective security decisions and manage the ISMS with a view to continuous improvement.
What the auditor actually looks at on the DdA
Consistency above all else
The ISO 27001 auditor does not seek to validate the completeness of your controls or the sophistication of your methodology. Their main objective is to verify the overall consistency of the ISMS.
Alignment of context ↔ risk analysis ↔ DdA ↔ treatment plan. The auditor will verify:
- Does the scope of the DdA correspond to the declared scope of the WSIS?
- Do the selected controls address the identified risks?
- Are control exclusions justified by risk analysis?
- Are the actions in the treatment plan underway or completed?
Justification for exclusions
One point that was particularly scrutinized was the ability to justify the controls excluded from Annex A.
Simply stating "this control is not applicable" without justification is not sufficient. The auditor expects an argument such as:
- "This audit concerns physical data centers, but our infrastructure is 100% cloud-based."
- "This control applies to mobile devices, excluding those within the scope of the WSIS."
- "This associated risk is assessed as low and formally accepted by management (see risk register)."
The traceability of these decisions in risk analysis is crucial.
Spot checking
The auditor will not check all controls exhaustively. He or she will proceed by sampling:
- Selection of critical controls (based on major risks)
- Verification of their effective implementation (evidence, demonstrations)
- Traceability testing through to risk analysis
If consistency is demonstrated in the sample, the auditor will consider the system to be robust.
Frequent non-compliance
Several pitfalls regularly lead to non-compliance:
- DdA disconnected from risk analysis: controls selected without reference to identified risks, or conversely, high risks without associated controls.
- Absent or superficial justifications: boxes checked without explanation, or generic justifications copied and pasted.
- Inconsistency with the treatment plan: controls declared as "deployed" in the DdA but absent from the action plan, or vice versa.
- Lack of updates: DdA frozen since initial certification, even though the scope or risks have changed.
Avoiding these pitfalls requires clear governance and continuous management of the WSIS.
Provision of dedicated tools to link DdA and risk analysis
The limitations of the artisanal approach
Many organizations manage their DdA and risk analysis in separate Excel spreadsheets. This approach has several limitations:
- Lack of automatic traceability: it is impossible to easily link a DdA control to a specific risk without cumbersome manual documentation.
- Fragile consistency: when risk analysis changes, the DdA must be updated manually, with a high risk of omissions or inconsistencies.
- Business/IT silos: teams work on separate documents, making it difficult to achieve a consolidated view and collaborate.
- Difficult to audit: the auditor must reconstruct consistency by cross-referencing several files, increasing the risk of discrepancies being detected.
Single repository and automated traceability
The use of specialized tools such as Oversecur makes it possible to overcome the limitations of traditional approaches (isolated spreadsheets, static documents) and embed risk analysis in a continuous governance process.
A dedicated tool offers several structural advantages:
- Centralization of assets, risk scenarios, existing measures, and treatment plans in a single repository. All stakeholders work from the same database, ensuring consistency.
- Direct link between risk analysis, Statement of Applicability, and ISO 27001 controls. Each SoA control is automatically linked to the risks it addresses, and vice versa.
- Traceability of responsibilities (CISO, risk owners, validators) and acceptance or treatment decisions. Each decision is time-stamped, documented, and assigned.
- Operational monitoring of treatment plans, with visibility on progress, responsible parties, and deadlines. The transition from the DdA to the action plan becomes smooth and traceable.
- Historical records of analyses and decisions, facilitating periodic reviews, audits, and management reviews. The evolution of the SMSI over time is documented and usable.
Governance support, not just documentation
The tool thus becomes a governance support, rather than a simple document production tool. It provides management and the CISO with a consolidated and up-to-date view of risks, enabling them to make objective security decisions and manage the ISMS with a view to continuous improvement.
This approach transforms the DdA from a static table into a dynamic security management tool.
Making DdA a management tool
Beyond compliance
- The DdA should not be viewed solely as a deliverable for the audit. It is a strategic tool for managing information security.
- In security steering committees: the DdA allows you to present the progress of controls, identify delays, and prioritize actions.
- In management review: the DdA summarizes the security decisions made and their justification, facilitating strategic trade-offs.
- In business relationships: the DdA is often requested by customers or partners to assess the level of security. A clear and consistent DdA builds trust.
Vivid representation of security choices
The DdA embodies the organization's choices in terms of security:
- Which risks have we chosen to address as a priority?
- What controls have we decided to implement?
- What risks have we formally accepted, and why?
It thus constitutes the organization's "security identity card," translating its risk management strategy into operational language.
Continuous improvement
The DdA also feeds into the continuous improvement cycle of the ISMS:
- During the Check phase of the PDCA cycle, DdA controls are subject to internal audits and effectiveness reviews.
- During the Act phase, lessons learned lead to adjustments to the DdA (addition, removal, or modification of controls).
- The DdA evolves with the WSIS, ensuring permanent alignment with reality.
Conclusion
The Statement of Applicability (SoA) is much more than just a checklist: it is the key link between risk analysis, strategic treatment decisions, and the ISMS operational action plan.
An effective DdA is based on three pillars: rigorous consistency with risk analysis, a reasoned justification for each inclusion or exclusion of a control, and complete traceability to the action plan.
Far from being a static document produced for auditing purposes, the DdA should be seen as a living security management tool, feeding into committees, management reviews, and investment decisions. It represents the operational translation of the organization's risk management strategy.
The use of dedicated tools transforms this regulatory requirement into a genuine governance support mechanism, ensuring consistency, traceability, and ongoing alignment between risks, controls, and actions.
Additional resources
