ISO 42001 Audits in 2026: The AI Management System Evidence Playbook

Why the AI audit conversation changed in 2026

Three things happened in thirteen months that quietly rewrote how an artificial intelligence management system gets assured, and most governance programmes have not caught up with any of them: ISO/IEC 42006 gave certification bodies their own rulebook, ISO 19011 was revised and took effect on publication with no transition window, and on 27 July 2026 the European Union deferred the bulk of its high-risk AI obligations by more than a year.

Taken together they move the centre of gravity, because the regulatory deadline everyone was building towards has shifted while the voluntary certification route has become both more rigorous and, for the first time, genuinely comparable from one certificate to the next. So if your 2026 plan was written around an August 2026 regulatory cliff, it is now aimed at something that is no longer there.

This guide is written for the people who have to answer the question in a board pack or a customer security review: what does an ISO/IEC 42001 audit actually demand, what evidence satisfies it, and what does a certificate buy you under the AI Act now that the timetable has changed. It is deliberately specific about evidence, because that is where readiness programmes fail. Organisations arrive at Stage 2 with a policy set and no record of the decisions the policy was supposed to govern.

People always ask me some version of "are we ready", which is the wrong question, because readiness is not a state you reach, it is a property of your records. If your evidence only exists because someone assembled it for the audit, you were never ready, you were prepared, and those are different things that the 2026 edition of ISO 19011 is specifically designed to tell apart.

The three assurance layers people keep conflating

Almost every confused conversation about AI assurance collapses three separate things into one. They are not the same, they are not issued by the same bodies, and one of them does not currently exist in usable form. Separating them is the single most useful thing a compliance function can do this quarter.

The first layer is management system certification: an accredited body audits your AI management system against ISO/IEC 42001 and issues a certificate covering a defined scope. The second is regulatory conformity assessment: for a high-risk AI system under the AI Act, the provider runs a conformity assessment procedure under Article 43, either through internal control (Annex VI) or through a notified body assessing the quality management system and technical documentation (Annex VII). The third is presumption of conformity under Article 40, which is granted only where a harmonised standard has been cited in the Official Journal.

That third layer is the one that trips people up. As of August 2026, no AI Act harmonised standard has been cited in the Official Journal. The CEN-CENELEC JTC 21 pipeline has started to deliver: EN 18286:2026 on quality management systems was approved on 12 July 2026 and is the first AI Act standard actually published. But publication is not citation, and only citation triggers the legal effect. The practical consequence is blunt: an ISO/IEC 42001 certificate confers no legal presumption of conformity with the AI Act today, and anyone telling you otherwise is selling something.

What the Digital Omnibus on AI actually changed

Regulation (EU) 2026/1744 amends the AI Act rather than replacing it. The headline is the deferral: full obligations for Annex III high-risk systems move from 2 August 2026 to 2 December 2027, and Annex I embedded high-risk systems move from 2 August 2027 to 2 August 2028. The consolidated text is on EUR-Lex, and the underlying Regulation (EU) 2024/1689 remains the base instrument.

The reasoning stated by the Commission is worth reading carefully, because it is an admission with operational consequences. The deferral was proposed in response to implementation difficulty: delays in designating national competent authorities and conformity assessment bodies, and the absence of harmonised standards, guidance and other compliance tooling for high-risk AI. In other words, the machinery to assess conformity was not ready, so the obligation to be assessed moved.

Two things did not move. Transparency obligations applied from 2 August 2026 as planned, with marking obligations for AI-generated content on systems already placed on the market applying from 2 December 2026, and prohibited practices, which have applied since February 2025, are unaffected apart from some additions. A deferral of the high-risk regime is not a general amnesty.

For a Head of Compliance the read is straightforward: you have bought roughly sixteen months on the heaviest workstream and nothing at all on transparency, prohibited practices or the commercial expectations of your customers, because enterprise procurement teams did not defer anything. If anything, the absence of a regulatory floor makes an independently audited management system more of a differentiator rather than less.

ISO/IEC 42006:2025 and why certificates are no longer interchangeable

ISO/IEC 42006:2025 was published on 7 July 2025, setting the requirements for bodies providing audit and certification of AI management systems on top of ISO/IEC 17021-1. Before it existed, a certification body auditing an AIMS was working from a general management system accreditation and its own reading of what AI competence meant, which is no longer acceptable.

The practical effect is threefold: certification bodies must now demonstrate specific AI competence in their audit teams rather than general management system competence with an AI reading list, audit duration is calculated against defined criteria instead of negotiated down, and accreditation bodies have a transition programme, which means the population of bodies legitimately able to issue an ISO/IEC 42001 certificate is being actively filtered.

This matters when you buy assurance and when you receive it. If you are selecting a certification body, ask directly whether they are accredited against ISO/IEC 42006 and what the accreditation scope covers. If you are evaluating a supplier who presents an ISO/IEC 42001 certificate, check the accreditation mark and the scope statement on the certificate itself. A certificate issued before the ISO/IEC 42006 transition, by a body without AI-specific accreditation, does not carry the same weight as one issued after.

ISO 19011:2026: how the audit itself changed

ISO 19011:2026, the fourth edition of the guidelines for auditing management systems, was published on 27 May 2026 and cancels and replaces the 2018 edition. It is a guidance standard, so it carries no separate force date and no transition period: it applies from publication. If your internal audit programme is still written to the 2018 edition, it is out of date now, not next year.

The revision is technical rather than structural. Read alongside the commentary published by certification and auditing bodies since May, three changes stand out for an AIMS. The first is a shift in emphasis from confirming that a process formally exists to evaluating whether it achieves its intended results, which for AI governance is a meaningful tightening. An AI impact assessment procedure that exists, is signed off and has never been applied to a live model will read differently under the 2026 guidance than it did under the 2018 one.

The second is expanded guidance on remote auditing methods and virtual locations, drawing on ISO/IEC TS 17012. This is well suited to AI systems, where the meaningful evidence lives in repositories, model registries, ticketing systems and monitoring dashboards rather than in a filing cabinet at a physical site. Expect audit teams to ask for read access, screen shares of live systems, and traceability from a model version to the approval that authorised it.

The third is improved guidance on documenting findings, reporting outcomes and recording nonconformities so they support corrective action. In practice this means vaguer findings are less likely to survive. "Insufficient documentation of model performance" becomes a finding that names the model, the control, the expected evidence and the gap.

For organisations running an internal audit programme against ISO/IEC 42001, the sequencing is simple. Update the audit programme to the 2026 guidance, re-baseline auditor competence against both the guidance and AI-specific knowledge, then run the internal audit before the certification body arrives rather than as a formality after readiness has been declared.

The evidence file: what an ISO/IEC 42001 audit actually asks for

ISO/IEC 42001:2023 pairs mandatory clauses with Annex A, which carries 38 controls across nine control objectives (A.2 to A.10). Controls are applied selectively and justified in a Statement of Applicability. What follows is organised by the evidence an audit team will actually request, control area by control area, based on what tends to be missing rather than what tends to be written down.

AI system inventory and scope

The inventory is the first document requested and the most frequently inadequate. An audit team is looking for a maintained register that identifies each AI system in scope, its purpose, its lifecycle stage, its owner, its risk classification, whether it is developed in-house or procured, and where the model and data sit. The failure mode is a spreadsheet that was accurate on the day the scope was written.

Evidence that satisfies: a register with a change history, a documented process for adding systems, and demonstrable linkage to procurement and change management so a new AI capability cannot enter the estate unregistered. Evidence that does not: a static list with no owner column and no last-reviewed date.

AI impact assessment

Impact assessment is where the AI-specific character of the standard bites hardest, and where teams with a mature ISO/IEC 27001 programme most often assume they are covered when they are not. An information security risk assessment addresses confidentiality, integrity and availability. An AI impact assessment must also address effects on individuals and groups, including foreseeable misuse, and it must be revisited when the system materially changes.

Evidence that satisfies: completed assessments for each in-scope system, with named participants, a method that is consistently applied, identified impacts on affected persons, and a documented trigger for reassessment tied to model retraining or purpose change. Evidence that does not: a single organisation-level assessment covering "our use of AI".

Data governance and provenance

Audit teams will follow the data backwards. For training, validation and test data they will ask where it came from, what rights you hold to use it, how it was assessed for relevance and representativeness, and how quality issues were handled. For systems using third-party foundation models, the same questions apply to the fine-tuning data and to whatever the supplier will disclose about the base model.

Evidence that satisfies: documented data sourcing decisions, licence and rights records, a data quality assessment tied to the intended use, and a record of what was excluded and why. Evidence that does not: a data catalogue with no provenance field.

Transparency and explainability documentation

Search demand data shows a clear cluster of enterprise interest in what explainability evidence an audit actually requires, and the honest answer is that it depends on the audience the transparency serves. The standard expects you to have determined who needs to understand what about the system, and to have produced information appropriate to each group: users, affected persons, internal oversight functions, and where relevant regulators.

Evidence that satisfies: documented determination of information needs by audience, the artefacts themselves (model cards, user-facing disclosures, internal technical documentation), and a version history that ties each artefact to a model version. Evidence that does not: a technical model card written by the data science team with no evidence anyone else was considered.

Fairness and bias testing

This is the control area with the widest gap between what organisations say and what they can show. The requirement is not that your system comes out perfectly fair, which is neither achievable nor what the standard asks, but that you defined what fairness means for this system in this context, tested against that definition, recorded the result and made a documented decision about whatever was left over.

Evidence that satisfies: a stated fairness objective per system, the metric chosen and why, test results across relevant cohorts, the threshold for acceptability, and the sign-off on residual disparity including who accepted it. Evidence that does not: a statement in the AI policy that the organisation is committed to fairness.

Human oversight

Human oversight is easy to assert and hard to evidence. The audit question is not whether a human is nominally in the loop but whether that human has the information, the authority and the practical ability to intervene, and whether interventions actually occur.

Evidence that satisfies: defined oversight roles with documented competence, the interface or process through which oversight is exercised, and logs showing genuine interventions including overrides and escalations. Evidence that does not: a process diagram with a box labelled "human review" and no record of a human ever having reviewed anything.

Incident handling and post-deployment monitoring

AI incidents do not look like security incidents. Model drift, degraded performance on a subgroup, an unexpected output pattern and a hallucination reaching a customer are all incidents in AI governance terms, and most organisations have no route for any of them because their incident process was built for outages and breaches.

Evidence that satisfies: an AI incident definition that covers performance and behaviour as well as availability, monitoring with defined thresholds per system, triage records, and at least one worked example of an incident travelling through the process to a documented resolution. Evidence that does not: the general IT incident procedure with the word "AI" added to the scope paragraph.

Third-party and supplier AI

Annex A.10 governs third-party relationships, and this is where the estate is usually largest and the governance thinnest. Every embedded AI feature in a procured SaaS product is third-party AI. So is every foundation model API call, every AI capability switched on by a vendor in a product update, and every model in a subprocessor chain.

Evidence that satisfies: supplier AI identified in the inventory, contractual provisions covering AI-specific obligations, evidence of due diligence proportionate to risk, and a process for detecting AI capability introduced by vendors after contract signature. Evidence that does not: a supplier register with a Yes or No column headed "uses AI".

Provenance is becoming the evidence

The most interesting shift in AI assurance right now is happening in provenance rather than in the management system clauses. Regulators, standards bodies and the frontier labs themselves have arrived at the same idea from three different directions: if a machine produced this artefact, that fact should travel with the artefact. For an audit programme that turns a philosophical debate about attribution into a control with a testable output.

The regulatory driver is Article 50 of the AI Act, which the Omnibus did not defer. Transparency obligations applied from 2 August 2026. Article 50 splits the requirement into two layers that people routinely collapse into one: a human-visible disclosure, and a machine-readable marking embedded in the content itself so that a system, not a person, can detect that the output was artificially generated. Generative systems already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement. Penalties in this tier reach 15 million euro or 3 percent of worldwide annual turnover, whichever is higher, with one caveat worth knowing: for SMEs and start-ups the cap is the lower of the two figures, not the higher.

The de facto answer to the machine-readable half is C2PA Content Credentials, backed by a membership in the thousands including Adobe, Microsoft, Google, Intel, the BBC and AP. Be precise about its status, because the specification is only being fast-tracked into an ISO standard, ISO 22144 on content credentials, which was still at draft stage as of August 2026. Treat C2PA as the market convention rather than a settled international standard, and be sceptical of vendors who describe it as already published. A Content Credential binds the creation timestamp, the model and version used, and any subsequent human edits into a cryptographic signature carried inside the file, which is what makes it auditable: an audit team can open an output and check whether the credential is present, intact and consistent with what your inventory says produced it.

Notice what that does to the transparency control area. Transparency evidence used to be documentary, meaning model cards, disclosures and policies, whereas provenance marking makes part of it forensic, so you can pull a sample of outputs and actually verify them, which is the kind of evidence ISO 19011:2026 pushes audit teams towards because it shows effectiveness rather than existence.

The case nobody scoped: AI-written code

Content provenance gets the attention because the regulation names it, but the larger unscoped exposure in most organisations is code. AI coding assistants are now writing production software inside companies whose AI inventory lists three customer-facing models and nothing else. Ask a governance function whether AI-generated code sits inside the AIMS scope and you will usually get a pause, then a no, then a much longer pause.

The tooling has quietly solved the hard part. Anthropic's Claude Code writes a Co-Authored-By trailer carrying the model identifier into every commit it participates in, so a single git log query returns every AI-assisted commit in the repository history. Broader conventions are emerging that add gradation, with an Assisted-by trailer for light suggestion, Co-authored-by for substantial contribution and Generated-by for predominantly machine-written code, each paired with a Signed-off-by that keeps a named human accountable. None of it requires buying a platform, since this is metadata your version control system already carries.

For a regulated engineering organisation this is the cheapest AI governance control in existence, and the one most often switched off. Teams disable the trailer for cosmetic reasons, because it clutters the log or because a manager dislikes the optics, and that decision quietly deletes the audit trail. When an incident review, a customer security questionnaire or a regulator eventually asks which parts of a system were machine-written and who accepted them, you want the answer to be a query rather than an archaeology project. Worth knowing too that the trailer can be turned off, so a git log search is a positive signal and not proof of absence.

Stage 1, Stage 2 and surveillance: the cycle in practice

Certification follows the standard two-stage model inherited from ISO/IEC 17021-1, refined for AI by ISO/IEC 42006. Stage 1 is a readiness and documentation review, usually including the scope statement, the Statement of Applicability, the risk and impact assessment method, the internal audit report and the management review. It exists to determine whether Stage 2 is viable, and a Stage 1 that ends in a delay is a normal and often correct outcome.

Stage 2 tests implementation and effectiveness. Under ISO 19011:2026 the emphasis on effectiveness is sharper: the team is sampling real cases and asking whether the system achieved what it was designed to achieve. Findings are graded, with major nonconformities blocking certification until corrected and minors requiring a corrective action plan.

After certification the cycle runs surveillance audits, normally annually, with a full recertification in the third year. Surveillance is not a lighter version of the same audit but a look at what has changed since the last visit, and in an AI estate change is constant: new models, retrained models, new suppliers, new use cases. Organisations that treat it as a formality tend to accumulate findings precisely because their change control never kept the AIMS current.

What this costs in effort, honestly

Effort is dominated by evidence reconstruction, not by documentation. Organisations that already run a certified ISO/IEC 27001 management system typically find the clause structure familiar and the Annex A content unfamiliar: the governance skeleton transfers, the AI-specific controls do not. The heavy lifting is inventory completeness, impact assessments per system, and building the traceability chain from model version to approval.

Two cost lines are consistently underestimated. Surveillance audits recur annually and scale with the size and volatility of the AI estate, which for most organisations is growing. And internal audit competence now has an AI dimension that a general management systems background does not automatically supply, which means either training your existing team or buying the capability in.

Where ISO/IEC 42001 does not help

Certification is assurance over a management system, and there are three things people expect from it that it will not do. It does not assess whether a specific AI system is safe or accurate, because that is a product-level question belonging in the technical documentation rather than on the certificate. A certified organisation can deploy a poor model, and the audit will only catch it if the governance process that should have caught it failed too.

It does not substitute for AI Act conformity assessment. If you are a provider of a high-risk AI system, Article 43 applies to you on the deferred timetable and a management system certificate is not a conformity assessment. It is genuinely useful preparatory work, particularly for the Article 17 quality management system requirements, but the two are distinct legal objects.

And it does not, today, confer presumption of conformity. That remains true until a harmonised standard is cited in the Official Journal. Watch the JTC 21 pipeline, but read it precisely: EN 18286:2026 on quality management systems is now published, which is real progress, and it has still not been cited. Note also that the Article 17 quality management system requirements sit outside the Chapter III Section 2 provisions to which Article 40 presumption attaches, so even a citation there would not be a clean presumption for the whole high-risk regime. Do not build a compliance argument on a citation that has not happened.

Three certification patterns, and what each one teaches

Guidance about evidence only becomes useful once you can see the shape it takes in a real organisation. Three situations recur often enough to be worth naming. The first is public and verifiable. The other two are reasoned from what happens when the standard meets an ordinary corporate estate, so treat them as arithmetic rather than as anecdotes.

Pattern one: the frontier lab, where governance came first

Anthropic achieved accredited ISO/IEC 42001 certification for its AI management system, among the first frontier AI labs to do so, with the certificate issued by Schellman Compliance, LLC, a certification body accredited by the ANSI National Accreditation Board, taking effect in January 2025. Then read the scope line rather than the headline, because it covers AI research and development and AI services rather than the whole organisation, which is precisely the distinction this article keeps insisting on, visible here on one of the most scrutinised certificates in the industry.

The instructive detail is the sequence, because the certification was built on governance that already existed and was already public: a published responsible scaling framework, deliberate work on model behaviour and alignment, and ongoing safety research. Rather than creating the governance, the audit made existing governance legible to a third party, which is the right way round and the one most enterprise programmes reverse. They commission a policy set in order to get certified, then discover at Stage 2 that policies without operating records prove nothing.

There is a second lesson hiding in the certification body. Search demand shows people actively querying whether a specific firm is an ISO 42001 audit provider. Buyers are now doing exactly the diligence ISO/IEC 42006 was written to enable: not just checking that a certificate exists, but checking who issued it and under whose accreditation. If your procurement questionnaire asks suppliers for an ISO 42001 certificate but does not ask for the accreditation mark and the scope statement, you are collecting a logo.

Pattern two: the inventory shock

Take an organisation convinced it runs a handful of AI systems: a customer-facing assistant, a forecasting model, a document classifier. Now do the arithmetic that scoping forces on you. Count the AI features already switched on inside the service desk platform, the scoring inside the recruitment tool, the assistant embedded in the CRM, the coding assistants across engineering, the translation and drafting inside the productivity suite. Almost none of those were built by anyone in the room, and every one of them is an AI system under the standard's definition.

That gap is not a documentation failure, it is a scoping failure with a governance root cause, because nothing in procurement or change management ever required an AI capability to be declared. The correction is unglamorous: add an AI declaration gate to vendor onboarding and to product change acceptance, then sweep existing contracts and admin consoles once. Doing that before drafting policy is what saves the rework, because the inventory sets the scope, the scope sets the Statement of Applicability, and the Statement of Applicability sets everything you will have to evidence.

Pattern three: the ISO 27001 incumbent

An organisation with a mature, certified information security management system approaches ISO/IEC 42001 as a delta exercise. In one sense it is right: the clause structure, the management review rhythm, the internal audit machinery and the corrective action process all transfer intact. That is genuinely a head start, and it usually cuts the programme timeline meaningfully.

Where it goes wrong is the assumption that the risk work transfers too, when it does not. A security risk assessment reasons about threat, vulnerability and impact on the organisation, whereas an AI impact assessment reasons about effects on people and groups, including foreseeable misuse, which is a different analytical object requiring different participants. Teams that hand AI impact assessment to the information security function alone produce documents that are competent, well structured, and consistently miss the affected-person dimension the standard is actually asking about. Bringing legal, the data protection function and a business owner into the same assessment is the single correction that resolves it.

What to do now, by role

AI governance fails at the seams between functions more often than inside any one of them. The deferral of the high-risk regime has removed the artificial deadline that was forcing those functions into the same room, which makes explicit role allocation more important, not less. The table below is the allocation that works in practice.

One coordination point ties all six together. Somebody has to own the decision record, and it should not be whoever happens to be running the certification project. Decision recording is a permanent operating habit, and if it is owned by a temporary programme it dies the week the certificate arrives, which is precisely when the first surveillance audit starts accumulating its findings.

Readiness checklist

Use this as a pre-Stage 1 self-test. If you cannot answer yes with evidence attached, that is your gap list.

What to do in the next 90 days

First, re-baseline the plan against the amended timetable. If your programme was scoped to an August 2026 AI Act deadline, rescope it, because Annex III high-risk obligations now bite on 2 December 2027 and Annex I on 2 August 2028 while transparency obligations already apply. What you have is a reallocation of effort rather than a pause.

Second, close the evidence gap rather than the policy gap. Pick three AI systems at random from the inventory and attempt the traceability test: impact assessment, data decisions, test results, approval, monitoring, in under an hour each. Whatever breaks is your readiness programme.

Third, fix the audit function before fixing the documentation. Update the internal audit programme to ISO 19011:2026, verify that whoever runs it holds AI-specific competence and not just management system competence, and run a real internal audit. The findings will be more useful than any gap analysis a consultant produces, because they come from your own evidence.

Next step

If your role is to lead or commission AIMS audits, the ISO 42001 Lead Auditor certification training covers the audit process end to end against ISO 19011:2026 and the ISO/IEC 42006 context. If you are building the management system rather than auditing it, the ISO 42001 Lead Implementer programme is the right entry point, and teams focused on the risk layer beneath the management system usually start with Lead AI Risk Manager. All three sit in our AI governance training hub, alongside the implementation playbook and the EU AI Act compliance guide.