ISO 42001 Certificate Scope Exclusions: What a Certificate Does Not Cover

What an ISO/IEC 42001 certificate attests

ISO/IEC 42001 is the international standard for AI management systems. It defines requirements for an AI management system, not for a particular model or product. Certification is voluntary. Organizations may pursue it for independent confirmation that their AI management system meets the requirements of ISO/IEC 42001:2023, and ISO notes that certification is performed by independent certification bodies and can provide additional confidence to stakeholders.

ISO defines certification as the provision by an independent body of written assurance, a certificate, that a product, service or system meets specific requirements. For ISO/IEC 42001, the object assessed is the management system. The practical reading, which is an inference rather than a statement in the standard, is that the certificate speaks to how an organization governs its AI activities, not to how any single AI interaction behaved.

Two further points matter for procurement. ISO/IEC 42006:2025 sets additional requirements for bodies that audit and certify AI management systems, and it is aimed at certification bodies and at the accreditation bodies that assess them. The issuer's identity and audit basis are therefore worth checking. Separately, ISO describes certification as additional confidence for stakeholders. It does not describe it as proof of legal compliance, so procurement and regulatory conversations should not equate the two.

Reading the scope statement

The scope statement is the most important line on the certificate. It defines the boundary of the management system that was audited. Anything outside that boundary was not assessed, regardless of how the vendor's marketing describes its AI program.

In practice, scope statements tend to draw boundaries along a handful of dimensions. Compare each against what you are buying:

• Legal entity: The certificate names a specific entity. A parent, subsidiary or acquired business may sit outside it.
• Products and AI systems: The scope may name particular services or AI systems rather than the whole portfolio.
• Models: Some scopes cover models the organization develops, but not third-party models it consumes, or the reverse.
• Business units: Only certain divisions or teams may operate inside the management system.
• Locations: Named sites or regions may be in scope while others are not.
• Lifecycle stages: Scope may cover development but not deployment or operation, or the other way around.

The Statement of Applicability and control exclusions

Scope defines where the management system applies. The Statement of Applicability addresses a different question: which controls the organization has chosen to apply within that scope, and why. In management system practice, it is the document where an organization records applicable controls and its justification for any it leaves out. Two vendors with identical scope wording can therefore have been assessed against different control sets.

This is why a certificate alone is a thin basis for assurance. A control that matters for your use case, such as one relating to the operation of AI systems or the oversight of third-party providers, may be excluded with a justification that made sense for the vendor's own context but not for yours. Ask for the Statement of Applicability, read the exclusions, and judge each justification against your intended deployment.

Certificate details also need to be current. Record the issue date and ask about the vendor's ongoing certification status, so that you are relying on a live certificate and not a historical one. ISO/IEC 42003, which is intended to provide guidance on implementing ISO/IEC 42001, is still under development as of November 2026, so there is no official implementation guidance to benchmark a vendor's interpretation against.

Management system assurance versus runtime assurance

A management system certificate and runtime assurance answer different questions, and both can be legitimate in the same vendor file. The NIST AI RMF 1.0 frames the decision to commission or deploy an AI system as a contextual assessment of trustworthiness characteristics and the relative risks, impacts, costs and benefits, informed by a broad set of interested parties. A general certificate does not replace that assessment for a specific deployment. That is this guide's analysis of the framework, not a statement in it.

Regulatory timelines also need an as-of date. As of November 2026, the Digital Omnibus on AI, which entered into force on 27 July 2026, extends EU AI Act high-risk application dates to 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products. Third-party risk files that still cite 2 August 2026 should be updated, and the Commission notes the Act can be changed through delegated and implementing acts, so mappings should carry a date.

• Object assessed: Certificate: the organization's AI management system within a stated scope. Runtime assurance: individual AI interactions and tool calls.
• Question answered: Certificate: does the organization run a defined management system that meets the standard? Runtime assurance: what was this system allowed to do, and what did it do?
• Basis: Certificate: independent audit by a certification body. Runtime assurance: evidence produced as interactions occur.
• Typical gap: Certificate: scope and control exclusions may omit your use case. Runtime assurance: does not by itself show organizational governance maturity.
• Use in due diligence: Certificate: evidence of management discipline. Runtime assurance: evidence for the specific deployment you are approving.

Where runtime enforcement and evidence complement a certificate

A management system certificate shows that an organization runs a defined process for governing AI. It does not enforce policy on any individual request. That work happens in the execution path, and it produces a different kind of evidence.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants, applying allow, redact, block, rate limit or escalate for human approval to individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. That enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST and the EU AI Act, which a regulated enterprise can present when asked what its AI was allowed to do and what it did.

This complements a vendor's ISO/IEC 42001 certificate and does not replace it. The certificate addresses the management system, and runtime enforcement with its evidence addresses behavior in your deployment. Trussed makes no claim of ISO/IEC 42001 certification here, and a regulated enterprise should keep both forms of assurance in its third-party risk file.