Why the Statement of Applicability Matters More Than You Think
If you are implementing ISO 42001 or preparing for certification, you will quickly discover that one document attracts more scrutiny than any other. The Statement of Applicability, commonly called the SoA, is the document that ties your entire AI management system together. It tells auditors which controls from Annex A you have selected, which you have excluded, and why. Get it right and your certification audit runs smoothly. Get it wrong and you will face a string of questions you are not prepared to answer.
On this page
This article walks through what the ISO 42001 Statement of Applicability actually requires, how it differs from the more familiar ISO 27001 version, and what auditors look for when they open it on day one of a certification audit. If you have already worked through AI risk treatment and Annex A under Clause 6.1.3, this article takes you a step further into what the finished SoA should look like and how it gets tested in practice.
What ISO 42001 Clause 6.1.3 Actually Requires
Clause 6.1.3 of ISO 42001 sets out the risk treatment requirements, and it is here that the Statement of Applicability is born. The clause requires your organisation to determine which Annex A controls are applicable, justify any exclusions, and document this in the SoA. Specifically, the standard requires the SoA to contain:
- The necessary controls from Annex A
- Justification for why each control has been included or excluded
- Whether each control has been implemented
- Justification for any controls that have been excluded from the AIMS
That last point catches people out. You cannot simply leave a control blank. If you exclude something, you need to explain why, and that explanation needs to hold up under audit scrutiny. Saying a control is not applicable without supporting reasoning is one of the most common nonconformities raised against this clause.
Exemplar Global Recognised Training ProviderRTP No. 310970
How the ISO 42001 SoA Differs From ISO 27001
Many quality and information security professionals approach the ISO 42001 SoA assuming it works exactly like the ISO 27001 version. There are similarities, but the differences matter. If you have worked through risk treatment and the Statement of Applicability in ISO 27001, you will recognise the structure, but the content is quite different.
ISO 27001 Annex A contains 93 controls grouped into four themes: organisational, people, physical, and technological. ISO 42001 Annex A is structured around AI specific concerns, covering topics like AI policies, internal organisation, data governance, AI system life cycle controls, impact assessment, responsible use, and third party relationships. The controls reflect the unique risks that AI systems introduce, including algorithmic bias, lack of transparency, unintended outputs, and societal harm.
The ISO 42001 SoA is therefore not just a security checklist. It is a declaration of how your organisation governs AI responsibly across its entire life cycle. Auditors approach it with that lens in mind.
The Structure of an Effective Statement of Applicability
There is no prescribed format in the standard, but effective SoAs share common characteristics. They are clear, traceable, and honest. Here is what a well constructed ISO 42001 SoA typically contains:
Column One: Control Reference and Title
List every control from Annex A by its reference number and title. Do not summarise or paraphrase. Use the exact language from the standard so that auditors can cross reference without ambiguity.
Column Two: Applicable or Not Applicable
For each control, state clearly whether it applies to your organisation. This is a binary decision, but it should not be made lightly. Walk through each control against your AI context, your AI roles as producer or provider or customer, and your risk assessment outcomes.
Column Three: Justification
This is where most organisations underinvest. A single word like applicable or not relevant is not sufficient. Write a sentence or two that explains the reasoning. For applicable controls, link back to the risk assessment or the AI impact assessment. For excluded controls, explain why the risk or context does not apply to your organisation.
For example, if your organisation uses a third party AI system but does not develop AI models internally, you might exclude certain Annex A.6 life cycle controls that relate to model training and validation. Your justification should explain that your role is that of a deployer, not a developer, and that the responsibility for those controls sits with your supplier.
Column Four: Implementation Status
State whether each applicable control has been implemented. Options typically include implemented, partially implemented, or planned. Be honest here. Auditors will verify implementation through interviews, records, and observation. Claiming full implementation when controls are only partially in place is worse than acknowledging a gap.
Column Five: Reference to Evidence
Link each implemented control to the documented information that supports it. This might be a policy, a procedure, a training record, a risk register entry, or an impact assessment report. This column transforms the SoA from a declaration into a navigable map of your AIMS.
Walking Through the ISO 42001 Annex A Controls
ISO 42001 Annex A is divided into ten sections. Understanding what each section covers helps you make informed applicability decisions and write credible justifications.
A.2: Policies Related to AI
These controls require your organisation to establish AI related policies that set direction for responsible AI use. If your organisation uses AI in any capacity, these controls are almost always applicable. Exclusions here are difficult to justify.
A.3: Internal Organisation
These controls address governance structures, roles, and responsibilities for AI oversight. Applicable to any organisation with an AIMS, regardless of AI role.
A.4: Resources for AI Systems
Covers data, tooling, and human resources needed to develop and operate AI systems. Organisations that are pure deployers of third party AI may exclude some controls here, but must justify this carefully against their actual activities.
A.5: Impact Assessment
These controls require organisations to assess the impacts of AI systems on individuals, groups, and society. This is one of the most distinctive sections of ISO 42001 and applies broadly. If you are deploying AI that affects people in any way, these controls apply.
A.6: AI System Life Cycle
Covers the technical controls across design, development, testing, deployment, and decommissioning of AI systems. Organisations that only deploy AI built by others may exclude development phase controls, but must clearly document their role and the boundaries of their responsibility.
A.7: Data for AI Systems
Addresses data quality, provenance, and governance. Even deployers need to consider data quality controls if they are feeding data into AI systems or using AI outputs to make decisions.
A.8: Information for Interested Parties
Requires transparency with stakeholders about AI system capabilities and limitations. Broadly applicable, particularly for organisations whose AI systems interact with customers or the public.
A.9: Use of AI Systems
Covers responsible use requirements including human oversight, monitoring of outputs, and mechanisms for intervention. Applicable to any organisation operating AI systems.
A.10: Third Party and Customer Relationships
Addresses due diligence and contractual requirements for AI suppliers and customers. Applicable wherever AI systems involve third parties, which is most organisations.
Common Mistakes That Auditors Find
Having reviewed many SoAs in practice, certain patterns of weakness appear repeatedly. Here are the ones most likely to generate a nonconformity or at least a pointed question during your certification audit.
Blanket Exclusions Without Justification
Excluding entire sections of Annex A with a generic statement like not applicable to our business will not satisfy an auditor. Each exclusion needs its own reasoning tied to your specific context, AI roles, and risk profile.
Implementation Status Mismatches
Marking a control as fully implemented when the referenced procedure does not yet exist, or when staff cannot describe how the control works in practice, is a significant problem. Auditors will interview people and review documents. Discrepancies between the SoA and reality are treated seriously.
No Link to the Risk Assessment
The SoA does not exist in isolation. It should flow directly from your AI risk assessment under Clause 6.1.2 and your risk treatment decisions under Clause 6.1.3. If an auditor cannot trace a control selection back to a risk, or a control exclusion back to a documented rationale, the SoA loses credibility.
Treating It as a One Time Document
The SoA must be maintained. When your AI systems change, when new AI tools are adopted, or when a risk assessment is updated, the SoA should be reviewed and updated accordingly. Auditors at surveillance audits will check whether the SoA reflects the current state of your AIMS.
Forgetting the AI Impact Assessment Connection
ISO 42001 introduces the concept of an AI system impact assessment, which is a structured evaluation of how an AI system affects people and society. The outcomes of impact assessments should inform your Annex A control selections, particularly those in sections A.5, A.8, and A.9. If your SoA does not reflect the findings of your impact assessments, auditors will question whether the assessments are being used at all.
How Auditors Actually Review the SoA
Understanding the audit process helps you prepare more effectively. Here is what typically happens when an auditor opens your Statement of Applicability.
At Stage 1, the auditor will review the SoA as a document. They are checking whether it exists, whether it covers all Annex A controls, and whether it appears to be connected to a risk assessment and risk treatment process. Stage 1 is not a deep verification, but a significant gap at this stage can delay progression to Stage 2.
At Stage 2, the scrutiny intensifies. The auditor will select a sample of controls and trace them through your system. For an applicable control, they will ask to see the implementing document, interview the person responsible, and observe evidence of the control in operation. For an excluded control, they will probe the justification to satisfy themselves that the exclusion is genuinely warranted.
The auditor may also work in reverse, starting with a risk in your risk register and asking which Annex A controls address it. If the SoA does not reflect the risks identified, that is a finding. This is why the connection between the SoA and the AI risk treatment plan is so important to get right before your audit.
At surveillance audits, the auditor will check whether the SoA has been reviewed since the last audit, whether any changes to AI systems or context have been reflected, and whether previously planned controls have been implemented as committed.
Practical Tips for Building a Defensible SoA
Here is direct, practical advice drawn from real audit experience.
- Start with your AI context document. Before you can make applicability decisions, you need clarity on what AI systems your organisation uses, develops, or provides, and in what role. The SoA should reflect that context precisely.
- Run your risk assessment first. The SoA is an output of risk treatment, not a starting point. Complete your AI risk assessment and treatment process before finalising applicability decisions.
- Involve the people who own the controls. If a control relates to data governance, the data team should be involved in the applicability decision. If it relates to human oversight of AI outputs, the operational teams should contribute. The SoA should not be a document produced in isolation by the quality manager.
- Write justifications in plain language. Auditors appreciate clarity. A justification that reads like a legal disclaimer is harder to verify than one that clearly explains the reasoning in a few direct sentences.
- Version control your SoA. Treat it like any other critical documented information. Date it, version it, and record who approved it. This makes it easy to demonstrate at surveillance audits that the document has been maintained.
- Test it before the audit. Run an internal audit against the SoA. For each applicable control, verify that the implementing evidence actually exists and that staff can describe how the control works. Fix gaps before your certification body arrives.
Exemplar Global Recognised Training ProviderRTP No. 310970The SoA as a Communication Tool
Beyond its role in certification, the SoA serves a practical purpose inside your organisation. It is the clearest single document that communicates what your AI governance framework covers and what it does not. When a new AI system is being considered, the SoA helps identify which controls need to be extended or reviewed. When a supplier asks about your AI governance practices, the SoA provides a structured answer.
Treat it as a living governance document, not a compliance artefact. Organisations that use the SoA actively tend to maintain better AIMS overall, because the document forces regular thinking about which controls are in place and whether they are working.
If you are new to ISO 42001 and building your auditing skills in this space, understanding how to audit the SoA is a core competency. The operational controls and impact assessments under Clause 8 connect directly to the SoA, and auditors will trace that connection in every certification audit.
Getting Your Team Ready
Whether you are the quality manager preparing for certification or an internal auditor reviewing your AIMS, the Statement of Applicability deserves dedicated preparation time. It is not a document you can complete in an afternoon. It requires input from AI system owners, risk management, legal or compliance teams, and operational staff who interact with AI systems daily.
If you want to build the skills to audit ISO 42001 effectively, including how to evaluate the SoA against the risk treatment plan and operational evidence, Audit Workshop offers training in AI management system auditing that is grounded in real audit practice, not just theory. The courses are designed for practitioners who need to understand how these requirements work in the field, not just on paper.
