ISO 42001 Annex A Controls: The 38 AI Management Controls and Where Each One Lands in the Deployment

ISO 42001 Annex A lists 38 controls across nine areas (A.2 through A.10) that an organization implementing an AI Management System (AIMS) has to consider. The Statement of Applicability records which controls the organization has implemented, which controls it has excluded (with justification), and which controls are partially implemented with a target date for completion. The auditor samples the applicable controls at the certification audit and the surveillance audits that follow.

I want to walk through each of the nine areas, the controls each area contains, the deployment layer where each control operates (policy, application, gateway, or model provider), and the evidence artifacts a certification body's auditor accepts as satisfaction of the control.

One thing to settle before the list, because it trips up every first-time reader of the standard: the control numbers never start at .1. A.2 begins at A.2.2, A.3 begins at A.3.2, and so on. The .1 position in each area holds the control objective, the statement of what the area is for, and it is not itself a control. There is no A.2.1 to implement. A.6 breaks the pattern further by splitting into two sub-areas, A.6.1 and A.6.2, so its controls carry four-level numbers.

The full control set

| Control | Title | Where it operates | |---|---|---| | A.2.2 | AI policy | Policy | | A.2.3 | Alignment with other organizational policies | Policy | | A.2.4 | Review of the AI policy | Policy | | A.3.2 | AI roles and responsibilities | Organization | | A.3.3 | Reporting of concerns | Organization | | A.4.2 | Resource documentation | Organization | | A.4.3 | Data resources | Data | | A.4.4 | Tooling resources | Application | | A.4.5 | System and computing resources | Infrastructure | | A.4.6 | Human resources | Organization | | A.5.2 | AI system impact assessment process | Policy | | A.5.3 | Documentation of AI system impact assessments | Policy | | A.5.4 | Assessing AI system impact on individuals or groups of individuals | Policy | | A.5.5 | Assessing societal impacts of AI systems | Policy | | A.6.1.2 | Objectives for responsible development of AI system | Policy | | A.6.1.3 | Processes for responsible design and development of AI systems | Application | | A.6.2.2 | AI system requirements and specification | Application | | A.6.2.3 | Documentation of AI system design and development | Application | | A.6.2.4 | AI system verification and validation | Application | | A.6.2.5 | AI system deployment | Application | | A.6.2.6 | AI system operation and monitoring | Gateway | | A.6.2.7 | AI system technical documentation | Application | | A.6.2.8 | AI system recording of event logs | Gateway | | A.7.2 | Data for development and enhancement of AI system | Data | | A.7.3 | Acquisition of data | Data | | A.7.4 | Quality of data for AI systems | Data | | A.7.5 | Data provenance | Data | | A.7.6 | Data preparation | Data | | A.8.2 | System documentation and information for users | Application | | A.8.3 | External reporting | Organization | | A.8.4 | Communication of incidents | Organization | | A.8.5 | Information for interested parties | Organization | | A.9.2 | Processes for responsible use of AI systems | Gateway | | A.9.3 | Objectives for responsible use of AI system | Policy | | A.9.4 | Intended use of the AI system | Gateway | | A.10.2 | Allocating responsibilities | Organization | | A.10.3 | Suppliers | Model provider | | A.10.4 | Customers | Organization |

Nine controls of the 38 sit in A.6, which makes the life cycle area larger than any other by a wide margin. Three of them (A.6.2.6, A.6.2.8, A.9.4) are satisfied by runtime records rather than documents, and those three are the ones an organization buying its models from an external provider usually has the least evidence for.

A.2: Policies related to AI

A.2 contains three controls covering the AI policy documentation.

A.2.2 (AI policy) requires the organization to maintain an AI policy that describes the objectives and principles for the responsible development, deployment, and use of AI systems. The evidence is the policy document, signed by the accountable executive, with a review date within the past 12 months.

A.2.3 (Alignment with other organizational policies) requires the AI policy to align with the organization's other policies (information security, privacy, ethics, compliance). The evidence is a cross-reference matrix showing the alignment.

A.2.4 (Review of the AI policy) requires the policy to be reviewed at planned intervals. The evidence is the review record with the date, the participants, and the outcomes.

The A.2 controls operate at the policy layer. The policy document is the primary artifact, and the enforcement layer (see A.8.3 and A.8.4) produces the operational evidence that connects the policy to the AI system's operation.

A.3: Internal organization

A.3 contains two controls covering roles and responsibilities.

A.3.2 (AI roles and responsibilities) requires the organization to define, allocate, and document responsibilities for AI-related activities. The RACI matrix that names the AI Policy Owner, the AI System Owner, the AI Risk Owner, and the Human Oversight Assignee is the primary evidence.

A.3.3 (Reporting of concerns) requires the organization to establish a mechanism for reporting concerns about the organization's AI systems. The evidence is the reporting channel (a defined process), the reports received in the period, and the responses provided.

A.4: Resources for AI systems

A.4 contains five controls covering the resources needed to operate AI systems responsibly.

A.4.2 (Resource documentation) requires the organization to document the resources allocated to AI-related activities. The evidence is the resource inventory covering people, technology, and data.

A.4.3 (Data resources) requires the organization to document the data resources used across the AI system lifecycle. The evidence is the data inventory with data source, purpose, and processing agreements.

A.4.4 (Tooling resources) requires the organization to document the tooling used to develop and operate AI systems. The evidence is the tool inventory.

A.4.5 (System and computing resources) requires the organization to document the compute infrastructure. The evidence is the infrastructure inventory.

A.4.6 (Human resources) requires the organization to document the human resources involved in the AI lifecycle. The evidence is the role catalog with competence requirements.

A.4 stops at A.4.6. Sufficiency of the resource commitment is a Clause 7.1 requirement in the body of the standard, so it is audited whether or not any Annex A control is marked applicable.

A.5: Assessing impacts of AI systems

A.5 contains four controls covering the AI impact assessment.

A.5.2 (AI system impact assessment process) requires the organization to establish a process for assessing the potential consequences for individuals, groups, and society of AI systems. The evidence is the process document plus the completed assessments for each AI system in scope.

A.5.3 (Documentation of AI system impact assessments) requires the organization to document the assessments produced. The evidence is the assessment records.

A.5.4 (Assessing AI system impact on individuals or groups of individuals) requires the assessment to include the impact on individuals. The evidence is the impact analysis on affected persons.

A.5.5 (Assessing societal impacts of AI systems) requires the assessment to include the societal impact where relevant.

A.6: AI system life cycle

A.6 contains nine controls covering the AI system lifecycle from planning through decommissioning. It splits into two sub-areas. A.6.1 covers management guidance for the lifecycle and holds two controls. A.6.2 covers the lifecycle stages themselves and holds seven.

A.6.1.2 (Objectives for responsible development of AI system) requires the objectives for responsible development to be defined and carried into every lifecycle stage. The evidence is the written objectives, dated before the build started.

A.6.1.3 (Processes for responsible design and development of AI systems) requires processes for responsible design and development. The evidence is the AI development lifecycle documentation.

A.6.2.2 (AI system requirements and specification) requires the AI system's requirements to be documented. The evidence is the requirements document.

A.6.2.3 (Documentation of AI system design and development) requires the design and development to be documented. The evidence is the design records.

A.6.2.4 (AI system verification and validation) requires the AI system to be verified and validated. The evidence is the verification and validation records including the test results.

A.6.2.5 (AI system deployment) requires the deployment to be planned and controlled. The evidence is the deployment plan and the deployment records.

A.6.2.6 (AI system operation and monitoring) requires the operation to be monitored. The evidence is the monitoring records: the audit log the gateway produces plus the review records showing a named person acted on what the monitoring surfaced.

A.6.2.7 (AI system technical documentation) requires the technical documentation to be maintained. The evidence is the technical documentation.

A.6.2.8 (AI system recording of event logs) requires the AI system to record events automatically across the lifecycle. The evidence is the event log itself: the per-decision audit records the gateway produces. This is the control most often over-claimed. Application-level logging that records "user submitted a prompt" satisfies nobody once the auditor asks which policy was in force and which identity the call carried. The record integrity properties matter as much as the coverage.

A.7: Data for AI systems

A.7 contains five controls covering the data lifecycle for AI systems.

A.7.2 (Data for development and enhancement of AI system) requires the data used for AI development to be documented and appropriate. The evidence is the training data documentation.

A.7.3 (Acquisition of data) requires the acquisition of data to be documented and lawful. The evidence is the data sourcing records and the legal basis analysis.

A.7.4 (Quality of data for AI systems) requires the data quality to be assessed. The evidence is the data quality assessment records.

A.7.5 (Data provenance) requires the provenance of the data to be documented. The evidence is the provenance records including the transformations applied.

A.7.6 (Data preparation) requires the data preparation to be documented. The evidence is the preparation records.

A.8: Information for interested parties of AI systems

A.8 contains four controls covering the information the organization provides to interested parties.

A.8.2 (System documentation and information for users) requires the organization to provide documentation and information to users. The evidence is the user documentation.

A.8.3 (External reporting) requires the organization to have a process for external reporting where required. The evidence is the reporting records for the applicable regulatory obligations (EU AI Act Article 26.4 incident reports, HIPAA breach notifications, SEC 8-K filings).

A.8.4 (Communication of incidents) requires the organization to communicate incidents. The evidence is the incident communication records.

A.8.5 (Information for interested parties) requires the organization to provide information for interested parties. It is the widest control in A.8 and the one auditors most often find under-evidenced, because the other three name a specific audience and this one does not.

Start by writing down who the interested parties actually are. Clause 4.2 of the standard already made you identify them, and A.8.5 is where that list has to produce artifacts. For most enterprise AI deployments the list resolves to six groups: the individuals whose data the system processes, the customers whose contracts reference AI processing, the regulators with jurisdiction, the workforce whose work the system affects, the investors or board receiving AI risk reporting, and the model providers sitting upstream.

Each group needs a named artifact and a named owner. Data subjects get the privacy notice section covering AI processing and the mechanism for exercising rights against it. Customers get the AI disclosure in the contract or trust centre. Regulators get whatever the applicable regime specifies. Employees get the internal AI usage policy and the disclosure of any AI involvement in decisions affecting them. The board gets the periodic AI risk report. Suppliers get the requirements you flow down to them under A.10.3.

The auditor's test is not whether the information exists but whether it is current, whether the organization can show who is responsible for keeping it current, and whether a person in each group could actually reach it. A privacy notice that mentions AI in a paragraph nobody has revised since 2023 fails this control even though the document exists. Bring the change log, not just the document.

A.8.5 also carries a trap worth naming. Where the information you owe an interested party is a statement about what the AI system did in a specific case, the artifact is a record extract rather than a policy document, and it has to be reproducible on demand months later. That is a retention and query problem, not a documentation problem, and organizations discover it at the first data subject request rather than at the audit.

A.9: Use of AI systems

A.9 contains three controls covering the use of AI systems.

A.9.2 (Processes for responsible use of AI systems) requires processes for responsible use to be defined. The AI Usage Policy plus the enforcement mechanism are the evidence.

A.9.3 (Objectives for responsible use of AI system) requires responsible use objectives to be defined.

A.9.4 (Intended use of the AI system) requires the intended use of each AI system to be defined and monitored. The evidence is the intended use statement plus the monitoring records showing the actual use aligns with the intended use.

A.10: Third-party and customer relationships

A.10 contains three controls covering third-party and customer relationships.

A.10.2 (Allocating responsibilities) requires responsibilities in third-party relationships to be allocated. The evidence is the third-party agreements including the AI-specific clauses.

A.10.3 (Suppliers) requires supplier relationships to include AI considerations. The evidence is the supplier evaluation records for AI providers (OpenAI, Anthropic, Google, cloud AI providers).

A.10.4 (Customers) requires customer relationships to address AI considerations. The evidence is the customer-facing terms and disclosures for AI-related processing.

The Statement of Applicability

The Statement of Applicability (SoA) is the primary Annex A artifact the certification body reviews. For each of the 38 controls, the SoA records:

The control identifier and title.

The applicability status (applicable / not applicable).

The justification for non-applicability (if not applicable).

The implementation status (implemented / partially implemented / planned).

The evidence reference (the document, record, or artifact that shows the control operates).

The target date for completion (if not fully implemented).

The auditor uses the SoA to plan the audit sample. Controls the SoA lists as applicable and implemented get sampled. Controls listed as not applicable get reviewed for the justification. Controls listed as planned get reviewed for the completion target.

ISO 42006 and who is allowed to audit you

Annex A tells you what to implement. ISO/IEC 42006:2025, published on 7 July 2025, governs the body doing the auditing, and it changed the market more than most implementation teams noticed.

Before it existed, certification bodies audited AIMS against ISO 42001 under the generic management-system rules in ISO/IEC 17021-1, with no AI-specific competence floor and no AI-specific audit duration table. ISO 42006 adds both. It sets competence requirements for the personnel involved in each certification activity, rules on liability, requirements on what the certification document itself must say, and requirements on the certification body's access to the organization's documentation. Its own Annex A sets how audit time is calculated for an AIMS.

Two practical consequences. The audit is longer than an equivalent ISO 27001 audit at the same headcount, because the duration table accounts for the AI system count and complexity rather than employee count alone. And a certificate issued by a body not accredited to ISO 42006 carries less weight with a customer's procurement team than one that is, which is the question to ask a prospective certification body before signing: what is your accreditation status against ISO 42006, and which accreditation body granted it.

Worth knowing alongside this: the climate change amendment that ISO applied across the Annex SL management system standards in 2024 lands in Clauses 4.1 and 4.2 of ISO 42001, not in Annex A. The organization has to determine whether climate change is a relevant issue and whether interested parties have climate-related requirements. No control in the 38 changes, but the auditor will ask.

What Annex A does not buy you under the EU AI Act

The assumption I run into most often is that an ISO 42001 certificate discharges the EU AI Act's quality management system obligation under Article 17. It does not, and the gap is structural rather than temporary.

Presumption of conformity under Article 40 attaches only to harmonised standards whose references have been published in the Official Journal of the European Union, and only for the requirements those standards cover. CEN-CENELEC JTC 21 is the committee writing them. It reviewed ISO/IEC 42001 for the Article 17 role and concluded the standard's goals and definitions were not aligned with what the AI Act requires of a quality management system, so it wrote a bespoke European standard instead: EN 18286, "Quality management system for EU AI Act regulatory purposes." As of June 2026 EN 18286 has reached the formal vote stage, the furthest advanced of any JTC 21 deliverable, and no JTC 21 deliverable has been cited in the Official Journal. Zero presumption of conformity is available today from any of them.

So an ISO 42001 certificate is useful evidence of a functioning management system and it is not a legal shortcut. The structural work transfers. The document set does not map one to one. If you are building toward both, treat the Annex A control set as the operational base and expect a separate mapping exercise against the AI Act's own articles, starting with the high-risk classification question that determines whether Article 17 applies to you at all.

DeepInspect

The DeepInspect gateway produces the evidence artifacts for several Annex A controls in a single record series. A.6.2.6 (operation and monitoring) and A.6.2.8 (recording of event logs) map directly to the gateway's per-decision audit records. A.8.3 (external reporting) maps to the record excerpts the CISO produces for regulatory reporting. A.8.4 (incident communication) maps to the incident records the runbook produces. A.9.2 (responsible use) maps to the policy enforcement events. A.9.4 (intended use monitoring) maps to the classifier verdicts and the policy events.

The gateway's identity binding satisfies the identification evidence A.3.2 needs. Its tamper-evident storage satisfies the record integrity properties the auditor tests for.

The boundary is worth stating plainly, because an SoA that overstates coverage is worse than one that admits a gap. DeepInspect sits on HTTP traffic between authenticated users or agents and the LLM. It evidences what happened on that path: which principal called which model, under which policy version, with what classification on the payload, and what the gateway decided. It does not evidence the training data lineage A.7 asks for, the impact assessments A.5 asks for, or the design records A.6.2.3 asks for. Those stay with the teams that produce them. Marking A.7.5 satisfied by a runtime log is the kind of claim that turns a surveillance audit into a nonconformity.

If your team is building out the Annex A control set for an ISO 42001 certification or a Statement of Applicability, let's talk today.