ISO 42001 Certification for Insurtech Vendors Facing Carrier Due Diligence

What ISO 42001 certification covers, and what it does not

ISO/IEC 42001 specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS). It is a management system standard written for organizations that develop, provide or use AI systems, and it applies across organization sizes and sectors. ISO describes it as a management framework that helps organizations meet compliance obligations more effectively. It is not a substitute for those obligations.

Certification is voluntary and is performed by independent certification bodies, not by ISO. ISO does not issue certificates, and an organization cannot be certified by ISO. Certification bodies may be accredited by national accreditation bodies, though accreditation is not compulsory. Requirements for bodies that audit and certify AI management systems are set out in ISO/IEC 42006:2025. Carriers may reasonably verify a certificate and the body's accreditation status through the IAF CertSearch database, so any certificate claim should be one you can support. Do not use the ISO logo to suggest ISO endorsement.

The practical boundary matters. Certification speaks to the organization's management system: how AI objectives are pursued, how risk is managed, and how the system is maintained and improved. It is not an evaluation of individual model outputs or interactions. A carrier assessor who asks what a specific system did on a specific day will not find the answer in the certificate. The answer has to come from operating records.

Why carriers are asking vendors for this

Carriers operate under insurance AI oversight frameworks, including the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, which NAIC members adopted at the 2023 Fall National Meeting. Carriers also track NYDFS Circular Letter 7 and Colorado SB 24-205. When a carrier relies on a vendor's AI-enabled capability, the carrier's oversight naturally extends to how the vendor manages that capability. Due diligence is the mechanism.

Colorado SB 24-205 illustrates the operational consequence. As of November 2026, the legislature's bill page lists developer-side disclosure duties with 90-day windows tied to discovered algorithmic discrimination involving a high-risk system. A vendor in that position needs an internal escalation and incident process able to meet a fixed window, whether or not a carrier asks about it. Applicability depends on the vendor's role and the use case, so legal review should confirm it.

An AIMS gives the vendor a structured answer to these requests. It does not by itself prove compliance with any regime, and it should be presented to carriers as a management framework that supports their obligations.

Mapping carrier due diligence questions to AIMS artifacts

Build this mapping from the published text of ISO/IEC 42001:2023, using its management system clauses and Annex A controls as the left-hand column. The rows below show the pattern: each carrier question resolves to a documented artifact and, where a control operates continuously, to operating evidence. Carrier questionnaires vary, so treat these as representative.

• Which AI functions are in scope?: Artifact: AIMS scope statement and system inventory for carrier-facing functions. Evidence type: documented, reviewed on a schedule.
• Who is accountable for AI risk?: Artifact: AI policy, role assignments, management review minutes. Evidence type: documented, with dated review records.
• How are AI risks and impacts assessed?: Artifact: risk and impact assessment records per system. Evidence type: documented, updated on change.
• What controls apply during operation?: Artifact: operational control procedures. Evidence type: operating records of what was allowed, changed, blocked or escalated.
• How is human oversight exercised?: Artifact: oversight procedure and approval criteria. Evidence type: records of individual escalations and decisions.
• How are incidents and disclosures handled?: Artifact: incident process with defined timelines. Evidence type: incident records and test exercises.

Documented policy versus policy enforced at runtime

Most AIMS documentation describes intent: what staff and systems should and should not do. An auditor can verify that a policy exists, was approved and was communicated. Whether the policy held across thousands of live interactions is a different question, and a point-in-time attestation answers it poorly. Evidence of a control operating should accumulate as the control runs.

That is the distinction between a control reviewed after the fact and one enforced at runtime. A reviewed control relies on sampling and reconstruction. An enforced control acts on each interaction as it happens and leaves a record of the decision. For operational controls, such as defining permitted behavior, protecting sensitive data in prompts and responses, and requiring human approval for sensitive actions, this difference changes what you can show an assessor.

Trussed is one way to produce this evidence. It enforces policy in the execution path across models, agents, tools, MCP servers and coding assistants, with actions that include allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. Enforcement generates continuous audit-ready evidence, mapped to frameworks including NAIC and NYDFS. This supports operational controls. It does not deliver or guarantee certification, and it does not address model or dataset provenance or end-to-end tracing of agentic workflows. Those need evidence from other processes.

Runtime records support controls concerned with permitted use, data handling, human oversight and event recording at the interaction level. They do not substitute for scope definition, risk and impact assessment, internal audit, management review, supplier management, or incident response. Be explicit with carriers about which category each control falls into.

Sequencing a certification readiness effort

A workable sequence moves from scope to evidence, and starts operating evidence collection early. Controls that only begin generating records in the weeks before the audit leave little operating history to show. Note that ISO/IEC 42003, intended as guidance on implementing 42001, is still under development, so the standard text itself remains the working reference.

• 1. Fix the AIMS scope: Define scope by the AI-enabled functions you supply to carriers, and state exclusions plainly.
• 2. Build the control mapping: Map each clause and Annex A control to the carrier requests it answers and the artifact that answers it.
• 3. Classify each control: Mark each as documented policy, process-based, or enforced at runtime with per-interaction records.
• 4. Start operating evidence early: Turn on enforcement and record retention for runtime controls so a history exists before audit.
• 5. Select the certification body: Compare several bodies, and check accreditation status and certificate verifiability.
• 6. Rehearse the audit and incident path: Run internal audit, management review and a disclosure-timeline exercise before the external audit.