ISO/IEC 42005 Impact Assessment for Insurance Underwriting AI

What ISO/IEC 42005 asks you to assess and document

ISO/IEC 42005:2025, titled AI system impact assessment, is a voluntary standard. It is listed in the ISO/IEC JTC 1/SC 42 catalogue alongside the other artificial intelligence standards. A carrier can use it to structure an assessment, but nothing in the standard makes it a safe harbor under any insurance regime.

An impact assessment of this kind is organized around a small set of questions. What is the system's scope? Who is affected by it? What is it intended to do, and how could it foreseeably be misused? What impacts follow for the people and groups identified, and where is all of this documented so that someone else can review it?

The standard describes how to structure that record. It does not turn findings into enforced controls, and it does not define the operational records that show those controls ran. That gap is where most underwriting programs stall: the assessment exists as a document, and production behavior is governed by something else. Treat the assessment as an input to operational control, not as the end product.

Defining the assessment scope for an underwriting AI system

Scope each underwriting AI system separately, with a named owner. A single assessment covering every model in the carrier or brokerage tends to be too general to produce enforceable findings. The following decisions set the boundary.

• Decision role: Record whether the AI makes the underwriting decision or supports a human underwriter. The NAIC bulletin refers to decisions made or supported by AI, so decision-support uses belong in scope.
• Stakeholders: List applicants and policyholders as primary stakeholders, then add other affected groups such as agents, brokers and underwriters who rely on the output.
• Data inputs: Inventory the data the system uses, including external consumer data and information sources (ECDIS) and any consumer information passed to models or tools.
• Intended use and misuse: State the approved underwriting purpose, then describe foreseeable misuse, such as a tool call to a data source the use case does not need.
• Third-party components: Keep vendor documentation for any third-party model or data source. Colorado SB 24-205 lists a developer duty to give deployers the information needed to complete an impact assessment.

One assessment, three regimes

A single assessment record can support all three regimes if it is built to be mapped. The table shows what each regime expects, as of November 2026, and where it asks for more than the assessment itself.

• NAIC AI Model Bulletin: Adopted in December 2023 as guidance, not a model law or regulation. Expects governance of AI use and compliance of AI-made or AI-supported decisions with existing insurance law, including unfair trade practices. It also describes information a Department may request in an examination. The assessment supplies the system record; you add governance documentation and examination-ready evidence.
• NYDFS AI and ECDIS guidance: Adopted July 11, 2024. Expects a governance and risk management framework. The circular text describes a comprehensive assessment of whether ECDIS or AI systems produce disproportionate adverse effects, names the Adverse Impact Ratio as one method, and calls for oversight and auditing. The assessment supplies context; outcome testing and audit are separate artifacts.
• Colorado SB 24-205: Lists impact assessment duties for deployers of high-risk systems, documentation duties for developers, and disclosure to the attorney general within 90 days of discovering algorithmic discrimination. The assessment supports the first duty; you also need an escalation path from monitoring to legal and compliance to meet the disclosure timeline.

Turning findings into runtime policy

Once findings are written down, sort them by the kind of control they need. Findings about what an underwriting AI may touch, send or call can usually be expressed as policy on individual interactions and tool calls. This sorting is a design practice rather than a requirement in any regime, but it makes findings testable.

Five actions cover most cases. Allow a request that matches the assessed intended use. Redact consumer information that a model or tool does not need, for example personal identifiers in a prompt sent to an external service. Block a call that falls outside the assessed purpose, such as a request to an ECDIS source not approved for the use case. Rate limit repeated or bulk queries that suggest misuse or probing. Escalate for human approval when an action touches a high-impact step, so a person decides before it proceeds. The point is that policy is enforced at runtime, not reviewed after the fact.

Some findings cannot be handled this way. Disproportionate adverse effects on similarly situated or protected-class insureds are statistical, population-level properties. A single-interaction control cannot establish them. They need periodic outcome testing, such as Adverse Impact Ratio analysis, with results fed back into the assessment. Adverse action explainability is similar: runtime policy can require that explanation inputs are present or route a case to a person, but the adequacy of the explanation is a separate review. Keep both streams in the same assessment record so each finding has a named control and an owner.

Where Trussed fits

Trussed addresses the runtime half of this problem. It enforces policy in the execution path across models, agents, tools and MCP servers, covering individual interactions and tool calls with allow, redact, block, rate limit and escalate for human approval. Enforcement produces audit-ready evidence on a continuous basis, mapped to NAIC and NYDFS expectations among others. Insurance is Trussed's deepest vertical, with carriers and brokerages in production.

The platform can be deployed self-managed in the customer's cloud, with configurable retention and data residency. It has run continuously in a regulated enterprise for more than 18 months. Trussed does not perform the impact assessment or the outcome testing described above, and it does not trace end-to-end agentic workflows. It gives risk leaders the enforcement and evidence layer that an ISO/IEC 42005 assessment needs but does not define.