ISO/IEC 42001:2023 is the AI management system standard. It was published in December 2023 and has been the structural reference point for AI governance ever since. Most organisations approaching it for the first time treat it the way they approached ISO 27001 a decade ago: as a paper exercise that produces a certificate, signed off by a Notified Body, refreshed every three years. That read of 42001 will not survive a 2026 audit. The standard is structured to interrogate the AI management system on operational evidence, and the certification bodies have refined their audit programmes accordingly. This briefing walks through what an actual 2026 ISO 42001 audit looks like, control by control, and what a buyer should expect their AI platform to produce as evidence.
The 42001 standard contains 38 controls in Annex A, organised across 9 categories: AI policies (4 controls), internal organisation (2), resources for AI systems (5), assessing impacts (4), AI system lifecycle (10), data for AI systems (4), information for interested parties (4), use of AI systems (3), and third-party and customer relationships (2). The 9 management-system clauses in the body of the standard (Clauses 4-10) wrap around the controls and define the management system itself: context, leadership, planning, support, operation, performance evaluation, improvement. An audit examines both the management system clauses and the Annex A controls, with cross-referencing between the two.
Of the 38 Annex A controls, in our reading roughly 12 are largely policy-and-procedure controls (the auditor reads documents, interviews people, and confirms the documents are coherent). The other 26 are operational controls where the auditor expects evidence — events the AI system produced during the audit window — that demonstrate the control was operating. The split is approximate; some controls have both policy and operational components. But the rough proportion is what matters for buyers: most of the 42001 audit is about evidence, not about documents.
The four most operationally evidence-heavy control categories are AI system lifecycle (A.6.2), assessing impacts (A.5), data for AI systems (A.7), and use of AI systems (A.9). Walking through each.
AI system lifecycle (A.6.2) — ten controls covering the design, development, validation, deployment, monitoring, and decommissioning of an AI system. These are operational controls in their entirety. The auditor will ask: for each AI system in scope, show me the design records, the validation results, the deployment records, the monitoring outputs, and the decommissioning records (where applicable) for the audit window. "Audit window" for a 42001 audit is typically the last 12 months for a recertification audit, the last 6 months for a surveillance audit, and the period since installation for an initial audit. The records have to be contemporaneous with the events they describe — a deployment record reconstructed two weeks later from memory is not contemporaneous evidence, even if the reconstruction is correct.
Assessing impacts (A.5) — four controls covering the AI impact assessment process. These are partly policy (the impact assessment methodology is documented) and partly operational (the impact assessments themselves were performed and reviewed for in-scope AI systems). The auditor will ask: show me the impact assessments for each in-scope system, with the review records, and explain how the impact assessment outputs fed into the system's design controls. The interesting question is what "in-scope" means; the standard requires the organisation to define which AI systems are in the scope of the management system, and an audit will probe whether systems were appropriately included or improperly excluded.
Data for AI systems (A.7) — four controls covering data quality, data provenance, and data privacy. These overlap heavily with the privacy regime an organisation already operates (GDPR, PIPEDA, etc.) but the 42001 audit reads the controls specifically as they apply to AI training and operation. The auditor will ask: show me the data lineage for each in-scope system — what data was used for training, what data is used in operation, what data quality checks were performed, what provenance records exist, what privacy controls apply. Data lineage produced by the AI platform itself (rather than reconstructed from disconnected logs) makes this evidence trivial to produce. Data lineage that requires assembling from multiple separate logs is where most organisations spend the majority of their audit preparation time.
Use of AI systems (A.9) — three controls covering how the AI system is used in operation. The auditor will ask: show me the audit log for the audit window with user attribution, action attribution, and policy attribution. This is where the structural difference between platforms becomes most visible. A platform that produces a single attributed audit log per action passes this control with a single export. A platform that produces multiple separate logs (application log + access log + AI inference log + tool-call log, none of which are joined at source) requires the customer to do the joining themselves — and the auditor will ask how the joining was done and whether the joined record is verifiable.
The other operational categories — AI policies (A.2) supports the management system policy itself; internal organisation (A.3) covers roles and responsibilities; resources for AI systems (A.4) covers the people, infrastructure, and tooling supporting the system; information for interested parties (A.8) covers what is communicated to users, customers, and regulators; third-party relationships (A.10) covers the supplier and customer interface — each has a smaller operational evidence load but still requires records the auditor will examine. The total volume of evidence requested in a typical 42001 audit, for an organisation with five in-scope AI systems, runs to several thousand events across the audit window, organised into the control structure.
What buyers should expect from their AI platform. First: the platform should produce a 42001 control-mapping export. For each in-scope system, for each Annex A control, the platform should produce the events that satisfy the control across the audit window, with timestamps and signatures. The mapping is not the customer's responsibility to build. Second: the export should be structured. The auditor reads it in the structure of the standard, not in the structure of the platform's internal logging schema. A flat JSON dump of every event, however complete, is not what the auditor wants. Third: the export should be verifiable. The auditor's question is not only "do these events exist?" but "can we verify them against an independent source?" The standard does not require third-party verification, but auditors increasingly ask for it as a discriminator between mature and immature management systems.
What the customer still owns under 42001. The management system itself is the customer's responsibility. The platform produces the evidence; the customer maintains the policy, the leadership commitment, the resource allocation, the performance evaluation, the management review. The 42001 certificate is issued to the organisation, not to the platform. A platform that produces strong evidence reduces the audit's burden by perhaps 40-60% in the operational categories; the management system clauses (4-10) and the policy-heavy controls remain entirely the customer's work. This is the appropriate division of labour. A platform that claimed to deliver 42001 certification without customer effort would be either lying or building the management system on the customer's behalf, which is a different (and more expensive) engagement.
Three questions to ask any AI vendor before booking the 42001 audit. First: "Show me the platform's Annex A control mapping for the last 90 days of operation in your reference deployment." The vendor should produce the 38 controls with example evidence for each operational control, mapped to specific event types in their log. Second: "For each control in A.6.2 (lifecycle), what specific events does the platform produce, and how would an auditor verify them?" The right answer names design events, validation events, deployment events, monitoring events, and (for retired systems) decommissioning events as discrete record types. Third: "What is the format of the audit export, and does it match the structure of Annex A?" The export should not require the customer's compliance team to re-organise it before the auditor sees it.
ISO/IEC 42001 is going to be the dominant AI compliance reference for the next decade, the way ISO 27001 has been for information security. The platforms that produce evidence in the standard's structure will be evaluated quickly by buyers and survive surveillance audits without rework. The platforms that produce evidence in their own structure, leaving the mapping work to the customer, will lose deals to those that don't. The audit programme matures every cycle; buyers who want their first audit to go well will choose accordingly.