What Is Annex A.3 and Why Does It Matter?
If you are auditing or implementing an AI Management System under ISO 42001, the normative body of the standard tells you what your organisation must do. Annex A tells you how to do it. Specifically, Annex A provides a reference set of controls that organisations can select and apply when treating AI risks. These controls are not optional decoration. They feed directly into the Statement of Applicability and the risk treatment plan.
On this page
Annex A.3 sits within a broader control structure. Annex A.2 covers policies related to AI, which we have addressed in a separate article on AI policies under Annex A.2. Annex A.3 moves past policy and into the internal organisational mechanics: the structures, roles, processes, and accountabilities that make AI governance real rather than aspirational.
This article walks through each control in Annex A.3, explains what it requires in plain language, and gives you the audit angles that matter when you are testing whether these controls are genuinely implemented or just documented on paper.
The Structure of Annex A.3: Internal Organisation Controls
Annex A.3 contains six controls. They address how an organisation assigns responsibility for AI governance, how it manages conflicts of interest, how it handles external parties and the supply chain, and how it ensures AI considerations are embedded in project and procurement decisions.
The six controls are:
- A.3.1: Roles and responsibilities for AI
- A.3.2: Reporting structures for AI concerns
- A.3.3: Management of AI risks in projects
- A.3.4: Supplier relationships
- A.3.5: Responsibilities for AI system impact assessment
- A.3.6: Internal communication on AI
Not every organisation will select all six. The applicability of each control depends on the risk assessment and the nature of the AI systems in scope. That said, most organisations implementing ISO 42001 will find that the majority of these controls are relevant. An auditor reviewing the Statement of Applicability who sees A.3 controls excluded without a clear justification should probe that decision carefully.
Exemplar Global Certified Training ProviderRTP No. 310970
A.3.1: Roles and Responsibilities for AI
This control requires the organisation to define and allocate responsibilities for AI governance. That sounds straightforward, but in practice it is where many organisations stumble. Responsibility for AI is often scattered across IT, legal, risk, product teams, and operations, with no single point of accountability and no clear picture of who owns what.
ISO 42001 does not mandate a specific job title or organisational structure. What it does require is that someone is accountable for AI governance at an appropriate level, and that responsibilities across the AI lifecycle are clearly assigned. This includes responsibilities for risk assessment, impact assessment, monitoring, and escalation.
What Auditors Should Look For
When auditing A.3.1, start by asking who is responsible for AI governance in the organisation. Then verify that the answer matches the documented evidence. You are looking for:
- Job descriptions or role profiles that include specific AI governance responsibilities
- An organisational chart or RACI matrix that maps AI roles across the business
- Evidence that the people holding these roles understand what they are responsible for, confirmed through interviews
- Linkage between the roles defined here and the roles referenced elsewhere in the AIMS, particularly in Clause 5.3
A common gap is that responsibility is assigned in a document but the person named in that document has no meaningful involvement in AI governance decisions. Ask to speak with the person listed as accountable. If they cannot describe their responsibilities or point to recent decisions they have made, that is a finding worth recording.
A.3.2: Reporting Structures for AI Concerns
This control addresses how concerns about AI systems are escalated within the organisation. It is not just about having a complaints inbox. It is about creating a functioning channel through which staff, customers, or other parties can raise concerns about AI behaviour, bias, errors, or ethical issues, and having those concerns reach someone with the authority to act on them.
The control also covers internal reporting. People working with AI systems need a way to flag concerns without fear of reprisal. This is particularly important in organisations where AI is embedded in high stakes decisions such as credit assessment, hiring, or medical triage.
Common Weaknesses in Practice
In many organisations, the reporting structure exists on paper but has never been tested. Auditors should ask:
- Has anyone ever raised a concern through this channel?
- What happened when they did?
- Can you show me the log of concerns received and how they were resolved?
If the answer to the first question is no, that is not automatically a nonconformity, but it warrants investigation. Either the channel is not well known, staff do not feel safe using it, or there genuinely have been no concerns to date. Each of those explanations has different implications for the effectiveness of the control.
You should also verify that the reporting structure connects to someone with decision making authority. A channel that routes to a junior IT analyst who has no power to pause an AI system is not an effective control.
A.3.3: Management of AI Risks in Projects
This is one of the most practically important controls in A.3. It requires the organisation to integrate AI risk management into its project management processes. The intent is that AI risks are not assessed in isolation after a system is deployed, but are considered throughout the project lifecycle from initial scoping through design, development, testing, and release.
This control is relevant whether the organisation is developing AI systems internally or configuring and deploying AI systems procured from third parties. In either case, the project process should include defined checkpoints where AI risks are identified, assessed, and treated.
Auditing AI Risk in Projects
To audit this control effectively, select a live or recently completed project that involved an AI system. Then trace the AI risk management activity through the project record. You want to see:
- Evidence that AI risks were identified at the start of the project, not retrofitted at the end
- Risk assessment records that are specific to the AI system, not generic project risk registers
- Decisions made during the project that were influenced by the AI risk assessment
- Sign off by someone with appropriate authority before the AI system was deployed or changed
A project that has a comprehensive risk register covering schedule and budget but no specific consideration of AI risks is a gap. The control requires that AI risk management is embedded in the project process, not bolted on as a compliance exercise after the fact.
A.3.4: Supplier Relationships
Very few organisations develop their AI systems entirely in house. Most use cloud platforms, third party models, data providers, or AI enabled software products. A.3.4 requires the organisation to manage AI risks that arise from its supplier relationships.
This control connects to the broader supply chain risk management requirements in ISO 42001 and mirrors the approach taken in other management system standards. The key question is: what AI risks does your supplier introduce, and how do you manage them?
This is a more demanding question than it first appears. If you are using a large language model from a major provider, you may have limited visibility into how that model was trained, what biases it carries, or how it will behave in edge cases. Your risk treatment needs to account for that uncertainty.
What Good Supplier Management Looks Like
Organisations with mature AI governance will typically have:
- A supplier register that identifies which suppliers provide AI systems or AI enabled services
- Contractual requirements that address AI transparency, data handling, and incident notification
- A process for evaluating supplier AI practices before onboarding and at defined intervals
- Records of supplier assessments and any issues identified
When auditing this control, ask to see the supplier register and pick two or three AI related suppliers. Review the contracts and check whether AI specific requirements are included. Then ask how the organisation monitors those suppliers on an ongoing basis. Many organisations have good onboarding processes but no ongoing monitoring, which leaves the control incomplete.
A.3.5: Responsibilities for AI System Impact Assessment
ISO 42001 introduces the concept of an AI system impact assessment, which is one of the distinguishing features of this standard compared to other management system standards. An impact assessment evaluates the potential effects of an AI system on individuals, groups, and society, including effects on rights, safety, fairness, and privacy.
A.3.5 requires the organisation to assign clear responsibility for conducting these assessments. It is not enough to have an impact assessment procedure. Someone needs to own the process, have the competence to carry it out, and have the authority to act on the findings.
We have covered the AI system impact assessment concept in depth in a dedicated article on AI system impact assessments. For the purposes of A.3.5, the audit focus is specifically on accountability: who is responsible, are they competent, and is there evidence they are actually performing this role?
Audit Questions for A.3.5
When auditing this control, ask the following:
- Who is responsible for AI system impact assessments in your organisation?
- What qualifications or training does that person have?
- Can you show me a completed impact assessment and walk me through who was involved?
- How are the findings of impact assessments escalated and acted upon?
A common finding is that impact assessments are assigned to a risk or compliance function that has no technical understanding of the AI system being assessed. The assessment then becomes a tick box exercise. The control requires genuine competence, not just a name on a form.
A.3.6: Internal Communication on AI
The final control in A.3 addresses internal communication. The organisation must ensure that relevant information about AI governance, AI risks, and AI policies reaches the people who need it. This is not the same as awareness under Clause 7.3, although the two are related. A.3.6 is specifically about the communication of AI governance information within the organisation's internal structures.
In practice, this means that decisions made about AI risks, changes to AI systems, new AI policies, and significant AI incidents need to be communicated to the right people at the right time. A decision made by an AI governance committee that never reaches the teams operating the AI systems is a communication failure.
Testing Internal Communication
To audit A.3.6 effectively, look for evidence of actual communication rather than the existence of a communication plan. Ask to see:
- Records of AI governance meetings and the distribution of minutes or decisions
- Examples of AI related communications sent to operational teams
- Evidence that staff in AI related roles have received relevant updates about AI policy or risk decisions
Then interview a few people in operational roles who work with AI systems. Ask them what they know about recent AI governance decisions. If they are unaware of decisions that directly affect their work, the communication control is not functioning as intended.
How Annex A.3 Connects to the Rest of the AIMS
Annex A.3 does not sit in isolation. These controls connect directly to several clauses in the normative body of ISO 42001. Understanding these connections helps auditors and implementers see the full picture.
Clause 5.3 on roles, responsibilities, and authorities sets the foundation that A.3.1 builds on. If Clause 5.3 is vague, A.3.1 will be vague too. The controls reinforce each other, and a weakness in one often signals a weakness in the other.
Clause 6.1 on AI risk assessment connects directly to A.3.3 and A.3.4. The risk assessment process should capture risks from both internal AI projects and external suppliers. If the risk register only addresses internally developed AI and ignores supplier risks, A.3.4 is not being applied.
Clause 8.4 on AI system impact assessment connects to A.3.5. The impact assessment procedure needs an owner, and A.3.5 is where that ownership is established. Auditors reviewing Clause 8.4 findings should cross reference with A.3.5 to see whether accountability gaps are part of the root cause.
For a broader view of how the AIMS operational controls fit together, our article on auditing operational controls under ISO 42001 Clause 8 provides useful context.
Exemplar Global Certified Training ProviderRTP No. 310970Common Nonconformities Against Annex A.3
Based on how similar controls play out in other management system standards, and drawing on the structure of A.3 itself, the most common nonconformities auditors are likely to encounter include:
- Roles defined but not communicated: Job descriptions include AI governance responsibilities, but the people in those roles have not been told what is expected of them and cannot describe their responsibilities.
- Supplier controls limited to onboarding: The organisation evaluates AI suppliers before engaging them but has no ongoing monitoring process. The control is incomplete.
- Impact assessment ownership unclear: Multiple teams believe they share responsibility for impact assessments, resulting in assessments that are incomplete or not conducted at all for some AI systems.
- Project risk management bypassed for small projects: The AI risk management process applies to major projects but not to smaller deployments or configuration changes, creating a gap in coverage.
- Internal communication one directional: AI governance decisions are communicated downward but there is no mechanism for operational teams to provide feedback or raise concerns upward.
Practical Advice for Implementers
If you are implementing these controls rather than auditing them, the most important thing you can do is resist the temptation to treat A.3 as a documentation exercise. The controls in this section are about organisational behaviour, not paperwork. A RACI matrix that no one uses is not a control. A reporting channel that no one knows about is not a control.
Start with A.3.1 and get the roles genuinely assigned and understood. Then build the other controls around those roles. The person responsible for AI governance should be involved in supplier assessments (A.3.4), should own or oversee impact assessments (A.3.5), and should drive internal communication (A.3.6). The controls in A.3 are most effective when they connect to a real person with real authority, not a committee that meets quarterly and produces minutes that no one reads.
If you are preparing for an external certification audit, the auditor will almost certainly interview the person named as responsible for AI governance. Make sure that person can speak to each of the A.3 controls with confidence and can point to evidence of their implementation. Vague answers about what the organisation intends to do will not satisfy a competent auditor.
Understanding how Annex A controls are selected and applied is also important context. Our article on checking the Statement of Applicability against the AI risk treatment plan explains how the selection of Annex A controls should be justified and documented.
