If you are auditing an AI Management System under ISO 42001, the Statement of Applicability is one of the most important documents you will review. It sits at the intersection of risk assessment, risk treatment, and operational control. When you check the Statement of Applicability against the AI risk treatment plan, you are not just ticking a documentation box. You are verifying whether the organisation has genuinely thought through its AI risks, selected controls that address them, and followed through with implementation. This article walks through exactly how to do that, what to look for, and where organisations most commonly fall short.
On this page
What the Statement of Applicability Is in ISO 42001
The Statement of Applicability in ISO 42001 is a document required by Clause 6.1.3. It lists the controls from Annex A that the organisation has determined are applicable to its AI management system, along with justifications for why each control was included or excluded.
Unlike ISO 27001, where the SoA covers a large set of information security controls across four themes, the ISO 42001 Annex A is structured around the AI system life cycle and the specific risks that AI introduces. The controls span areas including AI policy, internal organisation, resources for AI systems, data governance, the AI system life cycle, third party relationships, and responsible use.
The SoA must show three things for each control:
- Whether the control is applicable or not applicable
- The justification for that decision
- Whether the control has been implemented
For an auditor, that third column is where the real work begins. A control listed as implemented needs to be substantiated with evidence. A control listed as not applicable needs a credible justification, not just the words not relevant.
If you want a solid foundation on what the SoA is meant to achieve before you start auditing it, the article The Statement of Applicability in ISO 42001: Your Most Examined Document covers the structure in detail.
Exemplar Global Certified Training ProviderRTP No. 310970
Understanding the Link Between Risk Treatment and the SoA
Before you can audit the SoA effectively, you need to understand how it connects to the risk treatment process under Clause 6.1.3.
The sequence in ISO 42001 works like this. The organisation identifies AI risks under Clause 6.1.2. It then selects a treatment option for each risk, which may include modifying the risk, accepting it, avoiding it, or transferring it. Where modification is chosen, the organisation selects controls from Annex A or identifies other controls that address the risk. Those selected controls then appear in the SoA as applicable, along with the justification that they address specific identified risks.
This means the SoA and the risk treatment plan should be consistent with each other. If the risk treatment plan says a particular risk will be addressed by implementing data quality controls, the SoA should show those controls as applicable and implemented. If the SoA shows a control as applicable but the risk treatment plan does not reference it, that is a gap worth exploring.
The article AI Risk Treatment and Annex A: How Clause 6.1.3 Works explains this linkage from the implementer side, which is useful background before you start asking audit questions.
Setting Up the Audit: What to Request Before the Day
Before you sit down with the auditee, request the following documents:
- The current Statement of Applicability, including version number and approval date
- The AI risk register, showing identified risks, risk owners, and treatment decisions
- The AI risk treatment plan, showing selected controls, responsible parties, and implementation status
- Any AI impact assessments completed under Clause 6.1.2 or Clause 8.4
- Evidence of implementation for controls listed as implemented in the SoA
Review these documents before the audit day. You are looking for alignment between what the risk register says, what the risk treatment plan says, and what the SoA says. Inconsistencies spotted in document review become targeted interview questions on the day.
Pay particular attention to the version history of the SoA. If the risk register has been updated recently but the SoA has not, that is a flag. The SoA should be a living document that reflects the current state of risk treatment, not a snapshot from the initial implementation.
Auditing the SoA Against the Risk Treatment Plan: A Step by Step Approach
Step 1: Verify the Completeness of the SoA
Start by checking that every control in Annex A of ISO 42001 appears in the SoA, either as applicable or not applicable. A common gap is that organisations include only the controls they have implemented and omit the rest entirely. The standard requires a determination for all controls, not just the ones that were selected.
Ask the auditee to walk you through how the SoA was constructed. Who was involved? Was it developed alongside the risk assessment, or was it built separately? The answer tells you a lot about whether the SoA reflects genuine risk thinking or was assembled after the fact to satisfy a certification requirement.
Step 2: Trace Controls from the Risk Treatment Plan to the SoA
Take the risk treatment plan and select a sample of risks that were treated by implementing controls from Annex A. For each sampled risk, check that the corresponding control appears in the SoA as applicable. If a control was selected in the risk treatment plan but does not appear as applicable in the SoA, that is a nonconformity against Clause 6.1.3.
Conversely, take a sample of controls marked as applicable in the SoA and trace them back to the risk treatment plan. Can you identify which risk or risks each control was selected to address? If a control is listed as applicable but there is no corresponding risk in the register that it addresses, ask the auditee to explain the basis for its inclusion. Sometimes organisations include controls because they seem sensible, which is acceptable, but the justification should still be documented.
Step 3: Test the Implementation Claims
For each control in your sample that is marked as implemented, ask for evidence. This is where many SoAs unravel. Implementation claims are often aspirational rather than actual. Common evidence types include:
- For AI policy controls: the documented AI policy, approval records, and evidence of communication to relevant staff
- For data governance controls: data quality procedures, data lineage records, and evidence that the procedures are being followed
- For AI system life cycle controls: design records, testing documentation, and deployment approvals
- For third party controls: contracts with AI providers, supplier assessments, and monitoring records
- For responsible use controls: training records, usage guidelines, and any incident reports related to AI misuse
Do not accept a procedure document as evidence of implementation on its own. The procedure tells you what the organisation intends to do. You need evidence that it is actually happening. Ask to see records, observe processes where possible, and interview the people responsible for operating the controls.
Step 4: Examine the Justifications for Exclusions
Controls marked as not applicable require justification. Review each exclusion and assess whether the justification is credible given the organisation's AI context.
For example, if an organisation has excluded controls related to third party AI providers but the organisation actually uses third party AI models or APIs, that exclusion needs scrutiny. Ask the auditee to explain their rationale. If the justification does not hold up against the organisation's actual AI activities, you have a finding.
Be especially careful with exclusions in areas that are directly relevant to the organisation's AI risks. An organisation that has identified bias risk in its AI systems but has excluded all controls from Annex A.5 relating to impact assessment is a red flag. The exclusion may be technically documented, but the risk treatment plan would need to show how that risk is being addressed through other means.
Step 5: Check That the SoA Is Current
Ask when the SoA was last reviewed. Under ISO 42001, the SoA should be updated whenever the risk assessment is updated or when significant changes occur to the AI systems in scope. Check whether there have been changes to AI systems, new AI deployments, or updated risk assessments since the SoA was last revised. If there have been, but the SoA has not been updated, that is a gap in the maintenance of the document.
Common Findings When Auditing the SoA Against the Risk Treatment Plan
The SoA Was Built in Isolation
One of the most common issues is that the SoA was built by a compliance team without meaningful input from the people who actually design, deploy, or operate AI systems. The result is a document that looks complete on paper but does not reflect operational reality. Controls are marked as implemented because a procedure exists, but the people running the AI systems have never seen the procedure and are not following it.
During interviews, ask the AI system owners which controls from the SoA they are responsible for. If they cannot answer, or if their answers do not match what the SoA says, you have a systemic issue with how the AI management system is being operated.
Risk Treatment Plan and SoA Are Out of Sync
The risk treatment plan gets updated when new risks are identified, but the SoA does not get updated to reflect the new controls that were selected. This is a documentation control problem, but it also reflects a deeper issue: the organisation is not treating the SoA as a living document that must stay aligned with risk treatment decisions.
Vague Justifications for Exclusions
Justifications like not applicable to our business or not relevant at this stage are not sufficient. The justification should explain why the control is not needed given the organisation's specific AI context, the nature of its AI systems, and the risks it has identified. Push back on vague justifications and ask the auditee to be specific.
Implementation Evidence Is Thin
Controls related to data governance and responsible AI use are often the weakest in terms of implementation evidence. Organisations can articulate what they intend to do, but records of what they are actually doing are sparse. If you find this pattern across multiple controls, consider whether it warrants a major nonconformity against Clause 6.1.3 for failure to implement the risk treatment plan as planned.
Connecting the SoA Audit to Operational Controls
The SoA audit does not exist in isolation. The controls listed as implemented in the SoA should be visible in the operational controls you review under Clause 8.1. When you audit operations, you are partly testing whether the implementation claims in the SoA are accurate.
For instance, if the SoA says data quality controls are implemented, your audit of operational processes should include a check on how data quality is actually managed. If the SoA says AI impact assessments are conducted at planned intervals, your audit of Clause 8.4 should verify that those assessments are happening and that the results are being used to update the risk register and, where necessary, the SoA.
This cross referencing between the SoA and operational evidence is what distinguishes a thorough audit from a document review exercise.
Exemplar Global Certified Training ProviderRTP No. 310970Writing Findings Related to the SoA
When you raise a finding related to the SoA, be specific about which element of Clause 6.1.3 is not being met. The clause requires the organisation to determine which controls are necessary, compare those controls with the Annex A controls, produce the SoA, and implement the controls. A finding should identify exactly which of these requirements has not been met, and the objective evidence that supports the finding.
Avoid vague findings like the SoA needs improvement. A well written finding might read: The risk treatment plan, version 2, dated March 2025, identifies data provenance controls as the selected treatment for the identified risk of biased training data. However, the Statement of Applicability, version 1, dated October 2024, does not include the corresponding Annex A.7 data controls as applicable. This represents a failure to meet the requirements of Clause 6.1.3(c), which requires the SoA to include the necessary controls.
If you want to sharpen your nonconformity writing skills more broadly, the article How to Write Nonconformities That Hold Up is worth reading alongside this one.
A Note on AI Auditing as an Emerging Skill
Auditing ISO 42001 requires a different kind of thinking compared to auditing ISO 9001 or ISO 14001. The risks are less tangible, the controls are newer, and the technology is evolving faster than most management systems can keep up with. That does not mean the audit approach changes fundamentally. You are still following evidence, testing implementation claims, and checking that the documented system reflects reality. But you need enough background in AI concepts to ask sensible questions and recognise a credible answer when you hear one.
Understanding what an AI impact assessment actually involves, what data quality means in an AI context, and how AI system life cycle controls work in practice will make your SoA audit significantly more effective. If you are building your ISO 42001 auditing skills, the How to Become an ISO 42001 AI Management System Auditor article covers the competence requirements and training pathways in detail.
Audit Workshop offers ISO 42001 lead auditor training that covers the SoA, risk treatment, and operational controls in depth, with practical exercises built around real AI management system scenarios. If you are preparing to audit AI management systems or want to add ISO 42001 to your auditor scope, the training is designed to give you the practical grounding that certification bodies and clients will expect.
