What Does an ISO 42001 Certificate Actually Prove About a Specific AI System?

A vendor hands you a certificate. You need to conclude something about one model, inside one product, making one class of decision about your customers.

The certificate will not tell you that.

Not because it is a weak certificate. Because that is not what it is.

This is the most common misread in AI vendor due diligence right now. The audit happened. The certificate is genuine. And the conclusion the reader writes into the file is still wrong.

What does an ISO 42001 certificate certify - the management system, or the AI system in front of you?

The standard states its own subject in its opening clause. It specifies requirements for "establishing, implementing, maintaining and continually improving an AI management system within the context of an organization."

Management system. Not model. Not product. Not the box in your integration diagram.

An AI management system is a set of processes: how the organization decides what AI it will build or use, how it assesses risk, how it treats that risk, how it reviews itself. A certificate attests that those processes existed and were found conforming at audit. It is a statement about organizational capability.

Your diligence question is a different question. You are asking whether one named system was governed. Only one of those two questions has a certificate attached to it.

The useful move is not to discount the certificate. Treat it as an index. The standard obliges the organization to produce and retain a specific set of records. The certificate tells you those records should exist. Your job is to name them and ask.

Why does the scope statement decide everything the certificate can be read to cover?

Clause 4.3 requires the organization to "determine the boundaries and applicability of the AI management system to establish its scope." That scope "shall be available as documented information."

Read it twice. Boundaries and applicability. The organization draws the line. The line is a document you are entitled to ask for.

The standard is explicit that the line can be drawn narrowly. In the definitions clause, the term "organization" carries a note: where the organization is part of a larger entity, the term "refers only to the part of the larger entity that is within the scope of the AI management system."

So a group certificate can cover one subsidiary. One business unit. One product line. The certificate on the letterhead does not tell you which. The ISO 42001 scope statement does.

There is a second boundary that is easier to miss. Clause 4.1 requires the organization to determine its roles with respect to the AI systems it develops, provides or uses. Provider. Producer. Customer. Partner. The clause notes that "the organization's roles can determine the applicability and extent of applicability of the requirements and controls in this document."

A vendor certified as a user of AI has demonstrated something materially different from a vendor certified as the developer of the model you are buying. Same certificate. Different obligation surface.

Ask for the scope statement first. Everything downstream is read against it.

What can a Statement of Applicability lawfully leave out, and how would you know?

Clause 6.1.3(f) requires the organization to "produce a statement of applicability that contains the necessary controls" and to "provide justification for inclusion and exclusion of controls." The definitions clause is blunter still: a statement of applicability is "documentation of all necessary controls and justification for inclusion or exclusion of controls," with a note that organizations "may not require all controls listed in Annex A."

Exclusion is designed in. That is ordinary management-system practice and it is not a scandal.

Here is the line that matters for your file. A note under 6.1.3 records that the organization "can provide documented justifications for excluding any control objectives in general or for specific AI systems, whether those listed in Annex A or established by the organization itself."

For specific AI systems.

The standard contemplates a Statement of Applicability where a control is applied across the estate and justified out for one named system. A valid certificate is compatible with that. Reading a certificate as blanket per-system control coverage is reading something the document does not say.

The certificate will never surface this. You surface it by requesting the Statement of Applicability and reading the exclusion justifications against the system you actually care about. Clause 6.1.3 also requires the necessary controls to be "available to interested parties, as appropriate," which is the hook you use when a vendor tells you the SoA is confidential.

Does the certificate tell you a given AI system was impact-assessed, and when?

No. It tells you the process exists.

Clause 6.1.4 requires the organization to define a process for assessing "the potential consequences for individuals or groups of individuals, or both, and societies" that can result from the development, provision or use of AI systems. The AI system impact assessment must take into account "the specific technical and societal context where the AI system is deployed and applicable jurisdictions." The result "shall be documented."

That is a per-system artefact by construction. Deployment context and jurisdiction are not organization-level facts.

Clause 8.4 requires impact assessments to be performed "at planned intervals or when significant changes are proposed to occur," and requires the organization to "retain documented information of the results of all AI system impact assessments." Clause 8.2 uses near-identical wording for AI risk assessments.

Notice what the standard does not do. It does not name the interval. "Planned intervals" means the intervals the organization planned. Recency is therefore not something you can infer from a certificate. It is something you ask:

→ What interval did you plan for this system? → When was the last impact assessment performed on it? → Which changes since then did you classify as significant, and which did you not?

The third question is the one that finds things. "Significant change" is the organization's own judgment call, and that judgment is exactly where an unreassessed system hides.

Which per-system records does the standard require the organization to retain, and how do you ask for them by name?

This is where a certificate earns its keep. The standard names the artefacts. You can request them by clause.

→ The scope statement (4.3), available as documented information. → The Statement of Applicability, with inclusion and exclusion justifications (6.1.3(f)). → Results of all AI risk assessments and all AI risk treatments (8.2, 8.3), retained, not merely produced. → Results of all AI system impact assessments (8.4), documented and retained "for a defined period" under control A.5.3, covering impacts on individuals or groups (A.5.4) and societal impacts (A.5.5). → Documented requirements and specification for new systems or "material enhancements to existing systems" (A.6.2.2). → Documented verification and validation measures, and the criteria for their use (A.6.2.4). → Event log record keeping, which A.6.2.8 says should be enabled at minimum while the system is in use. → Technical documentation prepared for each relevant category of interested parties, "such as users, partners, supervisory authorities" (A.6.2.7). → Evidence of the internal audit programme and its results (9.2.2), plus management review inputs covering nonconformities, monitoring results and audit results (9.3.2).

Ask for those by name, scoped to one system, and the vendor's answer stops being a certificate and starts being a record.

Ask for "your AI governance documentation" and you will get a slide.

Does a certified vendor's certificate say anything about the AI in its own supply chain?

Only that the vendor was required to have thought about it.

Control A.10.2 requires responsibilities across the AI system life cycle to be "allocated between the organization, its partners, suppliers, customers and third parties." A.10.3 requires a process ensuring that the organization's usage of "services, products or materials provided by suppliers aligns with the organization's approach to the responsible development and use of AI systems." A.10.4 points the same duty at customer expectations and needs.

The implementation guidance is specific about what a supplier can be here: datasets, machine learning algorithms or models, software libraries, or an entire AI system used on its own or inside another product. It says the organization should ensure the supplier "delivers appropriate and adequate documentation related to the AI system."

So the fourth-party model inside your third-party product is covered by a control, if that control was not excluded, and if the system sits inside the certified boundary. Two conditionals. Both are answered by documents you now know how to request.

That is the honest reading. The certificate moves your supply-chain question from unknown to answerable. It does not answer it.

How do you turn a certificate into a per-system attested record you can put in a file?

The structural problem is not that vendors are evasive. It is that a certificate is a document and your file needs data.

What you want, per named system: which certified boundary it sits inside, which controls were excluded for it and why, when it was last impact-assessed, what changed since, and which supplier components it inherits. Six fields. No PDF gives you six fields, and no amount of reading gives them to you at portfolio scale.

This is the whole argument for treating compliance as structured data rather than managed documentation. An obligation is a row. It binds to a control, the control binds to a clause, the clause binds to verbatim source text. When a vendor answers, the answer lands against the obligation it satisfies, timestamped, with the citation attached. Not in a folder named Q3.

It is also why determinism has to come before automation. Every obligation in the Aigis engine traces to a verbatim quote from the standard, grounded in source law rather than generated from a model's memory. That is what makes it safe to hand the tedious part to agents: pulling the SoA, diffing exclusions against the system inventory, chasing the impact-assessment date across forty vendors. Your agents do the work. Our engine keeps it honest.

For an assessment team, that is the difference between an opinion and a position. A posture you can defend in front of a regulator, a board, or a plaintiff.

See how Aigis handles this for assessment and audit teams at agrc.ai/auditors, how per-system exposure is modelled at agrc.ai/risk-management, and how the engine is built at agrc.ai/platform.

Answer once. Assess everything. Inside 60 minutes you'll see your exposure mapped to the obligations that actually apply to you. No call required.

FAQ

Does ISO 42001 certification cover every AI system an organization runs?

Not necessarily. Clause 4.3 lets the organization determine the "boundaries and applicability" of its AI management system, and the definitions clause confirms that where an organization is part of a larger entity, "organization" means only the part inside that scope. Read the scope statement, not the certificate.

Can a certified organization exclude controls for one specific AI system?

Yes. A note under clause 6.1.3 states that the organization can provide documented justifications for excluding control objectives "in general or for specific AI systems." The Statement of Applicability is where those justifications live, along with the justification for every control included.

How often must an AI system impact assessment be repeated?

The standard does not name a frequency. Clause 8.4 requires impact assessments "at planned intervals or when significant changes are proposed to occur." Both the interval and the meaning of significant belong to the organization, so ask for both, in writing.

What should I request in AI vendor due diligence beyond the certificate?

The scope statement (4.3), the Statement of Applicability with exclusion justifications (6.1.3), retained AI risk assessment and AI system impact assessment results (8.2, 8.4, A.5.3), verification and validation measures (A.6.2.4), technical documentation prepared for interested parties (A.6.2.7), and the supplier process under A.10.3. Each one scoped to the single system you are buying.