The call I get most often about ISO 42001 is not from an organisation deciding whether to certify. It is from an organisation that has already certified, has just failed the AI section of an enterprise security questionnaire, and cannot work out how both of those things can be true at once.
The conversation follows a script. We hold the certificate. We sent them the certificate. They came back with fourteen follow-up questions. Some of them we cannot answer at all. What did the auditor miss?
The auditor missed nothing. The certificate and the questionnaire are asking about different things, and nobody explained that at the point of sale.
What ISO 42001 actually certifies
ISO 42001 specifies an artificial intelligence management system. A certificate against it says that an accredited certification body examined that management system, within a stated scope, and found it conforming to the standard.
What an auditor examines is the system, not the AI. They will look at whether AI policy exists and has been approved at the right level. Whether roles and responsibilities are defined and someone is accountable. Whether an AI system inventory exists and is maintained. Whether risk assessment and impact assessment processes are defined and have been applied. Whether objectives are set and measured. Whether internal audit has run, whether management review has happened, whether nonconformities are recorded and closed, whether competence is managed, whether documented information is controlled.
They will sample. An auditor examining an AI impact assessment process will pick one or two assessments and check that the process was followed, that the output is coherent, and that the conclusions connect to the risk treatment. They are auditing whether the process operates. They are not forming a technical opinion on your model.
This is exactly what a management system standard is designed to do, and it is not a defect. An ISO 42001 certificate is a credible statement that AI governance in your organisation is systematic rather than improvised. That is worth having and it is not what a buyer's security team is asking about.
What the questionnaire actually asks for
Open the AI domain of a current enterprise vendor assessment and the character of the questions is entirely different. They are requests for artefacts and positions, not for evidence of process.
They ask for model documentation. What model or models does the system use, what version, who produced it, what is it intended for, and what is it explicitly not suitable for.
They ask about training data. Where did it come from, on what lawful basis, does it include personal data, does it include the buyer's data or the buyer's customers' data, and can you demonstrate provenance rather than assert it.
They ask about lineage. What data flows into the system in operation, where does it go, is it retained, is it used for any secondary purpose, and does anything leave your environment.
They ask for testing results. Not whether you test, but what you tested for, on what population, what you found, and what you did about it. Bias and performance testing appear here most often.
They ask for the training position in plain terms. Is customer data used to train or fine-tune models, is it used to improve a shared model, and is there an opt-out.
They ask about incident handling specific to AI. What happens when the model degrades, produces a harmful output, or behaves outside expected parameters, and how would the buyer learn about it.
And they ask who is accountable. A name, a role, and an escalation path.
Why these are different things
The standard requires you to manage AI risk. It does not prescribe the artefacts a buyer wants to read.
That single sentence accounts for almost the entire gap. ISO 42001 tells you that impact assessment must occur; it does not tell you that the output must be a document you can hand to a customer. It requires that you manage data for AI systems; it does not require a published training data provenance statement. It requires human oversight to be determined and implemented; it does not require a one-page description of where the human sits and what authority they hold that a procurement analyst can read in ninety seconds.
There is a second asymmetry, and it is about audience. An audit is conducted by someone trained in the standard who understands what a management system looks like and can navigate your documentation. A questionnaire is answered to someone in a buyer's security function who has never seen your organisation, has forty vendors in the queue, and is looking for a reason to move on. They do not want to be convinced that a system exists. They want the outputs of it.
The certificate proves a system exists. The buyer wants what came out of it. Those are complementary claims, and a supplier that offers only the first will keep getting the second question.
The six artefacts most often missing
Across the assessments I have run for certified organisations, the same six gaps recur.
A model card, or equivalent system documentation. A structured, current description of each AI system in customer-facing use: purpose, model and version, inputs and outputs, intended use, known limitations, out-of-scope use, and performance characteristics. Certified organisations usually have the information scattered across an inventory, a risk assessment, and an engineer's head. They rarely have it in one readable artefact.
A training data provenance statement. For third-party models, what the provider has published and what it has not, stated honestly including the limits of what you can verify. For any fine-tuning or in-house training, the sources, the basis, and the controls. The honest version of this document is more persuasive than the confident one, because buyers already know that provenance for foundation models is imperfectly disclosed.
A data flow and retention description for the AI path specifically. Most organisations have a general data flow map. Few have one that traces what happens to a prompt, whether it is logged, for how long, who can see it, and whether it leaves the jurisdiction.
Bias and performance test evidence. What was tested, against what population or benchmark, with what result, and what remediation followed. This is the single most common outright gap, and in high-consequence domains it is the one that ends the conversation.
A stated training position. One paragraph, unambiguous, on whether customer data is used to train or improve models. Ambiguity here is read as a yes.
An AI-specific incident and escalation procedure. Distinct from the security incident process, because model degradation and harmful output are not security events and the existing runbook does not cover them.
None of the six is required in that form by ISO 42001. All six are derivable from a management system that is genuinely operating. That is the whole point: the underlying work has usually been done, and it has not been packaged.
What closes the gap, and the honest sequencing
The remedy is not another certificate and it is not a longer questionnaire response. It is a set of artefacts, written once, maintained, and reused.
The sequencing question people ask is which comes first. The honest answer is that it depends on what is in front of you.
If a deal is stalled in security review now, the artefacts come first. They are faster to produce, they answer the immediate question, and they will be needed regardless. A certification cycle will not close a deal this quarter.
If a contractual requirement names ISO 42001, certification comes first, because nothing else discharges it. Build the artefacts alongside the implementation rather than after it, because the implementation generates most of the source material and reconstructing it later is wasted effort.
If neither is urgent, do both in one programme. The management system gives you the discipline that keeps the artefacts current, and the artefacts give you the commercial return that justifies the management system to a board. Neither works as well alone.
What does not work is treating them as alternatives. I have watched organisations spend a year and a substantial budget on certification, present the certificate to a buyer, and receive a fourteen-question follow-up they could have anticipated on day one. I have also watched organisations assemble a beautiful evidence pack with no management system behind it, and watch it go stale within two quarters because nobody owned keeping it true.
The certificate says the system exists. The artefacts say what it produced. Buyers increasingly ask for both, and they are right to.
What a certification body will and will not tell you
This gap is uncomfortable for the certification market to articulate, which is part of why it goes unstated at the point of sale.
A certification body is constrained by its accreditation. It audits conformity to the standard within the declared scope, and it is not permitted to consult on how you should present evidence to your customers, because that would compromise the independence the certificate depends on. So the auditor who notices that your model documentation would not satisfy a buyer is professionally obliged not to say so.
That is correct behaviour and it produces a predictable blind spot. The organisation walks out of stage 2 with a certificate and a reasonable belief that its AI governance has been externally validated as sufficient, without anyone having assessed sufficiency against the thing that motivated the exercise in the first place, which was almost always a commercial requirement rather than an abstract desire to conform.
The implication is that somebody else has to close the loop. Either an internal function tests the evidence against a real buyer questionnaire before the buyer does, or an adviser who is not the certification body does. What does not work is assuming the audit covered it.
A test you can run this week
Take the AI domain of the last enterprise questionnaire you received, or a published one if you have not received a serious one yet. Sit down with your AI lead and answer it cold, without preparation, using only documents that exist today.
Time how long it takes and record where you had to write something new rather than reference something existing. Anything you had to write from scratch is a missing artefact. Anything that took more than ten minutes to locate is an artefact that exists but is not usable under commercial pressure.
Then read your own answers as a sceptical buyer would. Where have you asserted rather than evidenced. Where have you described a process rather than given a result. Where does an answer depend on a claim about a third-party model that you cannot substantiate.
Organisations that run this test typically find between four and seven genuine gaps, and they are usually the six listed above plus one specific to their sector. Finding them in an internal session costs an afternoon. Finding them in a buyer's follow-up list costs a quarter.
If you hold ISO 42001 and are still stalling in AI security review, an evidence pack turns the management system you already operate into the artefacts buyers ask for. See what it contains.
Last reviewed: August 2026.