Annex A is the reference catalog of 38 AI controls, while the Statement of Applicability is the document that states which of those controls apply, which do not, and why. Annex A describes the available control set. The SoA turns that catalog into an auditable claim tied to your actual risk and impact assessments.
How Annex A and the Statement of Applicability differ in ISO 42001
Annex A is the control reference set, so it defines the available AI controls you can evaluate. The statement of applicability, by contrast, is your organisation’s documented decision record that says which of those controls apply, which do not, and why. That difference matters because Annex A is normative content, while the SoA is evidence of governance and risk-based selection.
Why Annex A is the catalogue and not the decision document
Annex A functions as the baseline inventory of controls an AI management system can draw from. It gives you the control universe, but it does not decide relevance for your organisation, use case, or risk profile. In practice, Annex A helps teams compare their current posture against a recognised reference set without assuming every control must be adopted in the same way.
That is why Annex A is best read as a control catalogue rather than an implementation checklist. It gives auditors, risk owners, and control owners a common vocabulary for discussing governance, accountability, transparency, monitoring, and other AI management concerns, but the actual obligation to apply a control depends on your organisation’s context and assessed need.
What the Statement of Applicability does in an ISO 42001 system
The Statement of Applicability turns the Annex A catalogue into an auditable organisational decision. It records the selected controls, the exclusions, and the justification for each choice, usually tied back to risk assessment, impact assessment, and the scope of the AI management system. That makes the SoA a living control register, not a static appendix.
For practitioners, the SoA is where governance becomes testable. If a control is excluded, the SoA should show why that exclusion is defensible. If a control is included, the SoA should make it clear how it is implemented, owned, and reviewed. This is the document an auditor will use to trace intent, scope, and consistency between risk treatment and control selection. ISO’s ISO/IEC 42001:2023 AI Management System Standard is the core reference for that management-system approach.
Why the distinction matters in real implementation
If teams confuse the two, they often make one of two mistakes. They either treat Annex A as mandatory regardless of context, which leads to bloated and poorly justified controls, or they write a SoA that simply mirrors the annex without explaining the organisation’s actual decision logic. Both weaken auditability because neither shows a reasoned match between risk and control selection.
The stronger approach is to use Annex A as the reference point and the SoA as the decision record. That separation preserves flexibility across different AI use cases while still making the system auditable. It also helps when models, deployment patterns, or third-party dependencies change, because the SoA can be updated to reflect a new control decision without rewriting the entire control catalogue.
Risk and Threat Considerations
A weak SoA is often the first place governance gaps show up. If exclusions are vague, inherited from templates, or disconnected from actual AI use, the organisation may believe it has control coverage that it cannot prove. The risk is not just audit failure, it is also blind spots in accountability, especially where AI systems affect decisions, data handling, or operational dependencies.
Failure mechanism: Teams copy Annex A into policy language without documenting why each control is selected or excluded, so the SoA stops reflecting actual risk treatment and becomes a ceremonial artifact.
Impact: The organisation loses traceability between AI risk assessment and control coverage, which can lead to inconsistent implementation, weak assurance, and avoidable gaps during review or certification.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 42001:2023 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | Annex A and Statement of Applicability | The question directly compares core ISO 42001 governance documents. |
| Recommendation — Document control inclusion and exclusion decisions in the SoA against Annex A risk analysis. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The SoA concept mirrors ISMS control selection and justification practices. |
| A.8.24 — Use of cryptography | Illustrates how Annex-style controls are selected and justified in an SoA. | |
| Recommendation — Record why access controls are included or excluded for the scoped system. State when cryptographic controls apply and document the rationale for any exclusion. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | SoA decisions depend on organisational scope, mission, and AI risk context. |
| Recommendation — Tie control applicability to organisational context before documenting selections. | ||
| NIST SP 800-53 Rev 5 | PM-9 — Risk Management Strategy | SoA selection is grounded in documented risk treatment decisions. |
| Recommendation — Align control inclusion decisions with the organisation’s risk management strategy. | ||
Practitioner Guidance
What to verify: Check that every SoA entry has a clear inclusion or exclusion rationale tied to the scope and risk profile of the AI system. If the reason could apply to any organisation, it is probably too generic to withstand review.
Decision rule: Use Annex A to evaluate options, but use the SoA to prove why the chosen set is appropriate for this deployment, this context, and this level of impact. If the SoA cannot stand on its own, the control selection is not yet mature.
Practitioner takeaway: Annex A tells you what controls exist; the SoA proves you made conscious, risk-based decisions about which ones belong in your AI management system.
Related resources from NHI Mgmt Group
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between human IAM controls and NHI governance?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
