Conducting an ISO/IEC 42005 AI System Impact Assessment for Insurance Underwriting and Claims AI

What the assessment is, and what it is not

ISO/IEC 42005:2025 is the ISO/IEC standard titled AI system impact assessment. It addresses a specific question: what does this AI system do to people and to the organization that deploys it? The unit of analysis is a single system in a defined context of use, not the organization's AI program.

That makes it a different instrument from a management system standard such as ISO/IEC 42001, which concerns how an organization runs its AI activities, and from a risk framework such as NIST AI RMF, which structures how risk is identified, measured and managed across a program. A practical arrangement is for the program-level framework to require an impact assessment, and for the assessment to produce system-specific findings that feed back into the program's risk register and controls.

The standard does not prescribe an insurance workflow. It is also voluntary, and it is not a substitute for what regulators expect. The NAIC Model Bulletin expects a written AIS Program commensurate with an assessment of risk. NYDFS Circular Letter No. 7 expects a comprehensive assessment of discrimination before AI systems are used in underwriting or pricing. Treat ISO/IEC 42005 as a disciplined way to produce the evidence those regimes look for, and do not assume formal equivalence.

Step 1 and 2: Scope the system and identify affected parties

Start with the decision, not the model. For each system, record the decision it makes or supports, the lines of business and states where it operates, who acts on its output, and what happens when the output is wrong. An underwriting triage model that routes submissions, a pricing model that uses external consumer data, a claims model that flags suspected fraud and an LLM assistant that drafts claim determinations are four different scopes, even if they share infrastructure.

Draw the boundary to include third-party components. The NAIC bulletin applies to AI used by or on behalf of the insurer, so vendor models, external data sources and embedded scoring services belong inside the assessment. Record what developer documentation you hold for each, and where it is missing.

Then list affected parties. For underwriting these include applicants, policyholders, and groups defined by protected classes. NYDFS says the assessment should cover any protected class whose membership can be determined from data available to the insurer or reasonably inferred using accepted statistical methods, so document for each system whether that is the case. For claims, add claimants and third-party claimants, claims adjusters who rely on the output, and the business itself through financial, legal and reputational exposure. Brokerages should include producers and customers whose submissions pass through the system.

Step 3 and 4: Assess, rate and assign mitigations

For each affected party, list the plausible impacts and the failure modes behind them. For underwriting, the central items are unfair discrimination, including through proxies in external consumer data, along with inaccurate eligibility or pricing outcomes and an inability to explain a decision to an applicant. For claims, consider adverse outcomes such as wrongful denial, delay, underpayment or an unwarranted fraud flag, plus gaps in explainability and the limits of human oversight, such as reviewers who approve model outputs without independent judgment. Regulator text covers discrimination and accuracy most directly, so the claims-specific items are your own analysis and should be reasoned and recorded as such.

Use a consistent rating method. A workable one scores severity, likelihood, number of people affected and reversibility, then records the controls already in place and the residual rating. Reversibility matters in insurance: a mispriced renewal can be corrected, while a denied claim that a claimant abandons may not be.

Each rated impact then needs a mitigation with a named owner and a test of whether it works. Separate mitigations by where they operate: design and data choices, statistical testing across protected classes, vendor requirements, human review procedures, and controls that act on individual interactions as the system runs. Record the residual risk and who accepted it. A finding with no owner and no verifiable control is an open item, not a mitigated one.

Step 5: Map assessment outputs to insurance regulatory expectations

Keep one assessment and map its outputs to each regime, rather than writing separate documents. The mapping below states what each regime expects and which assessment output answers it. Applicability to a given carrier depends on role, lines and jurisdictions, so legal review should confirm which outputs are mapped to which regime.

• NAIC AI Model Bulletin: Expects a written AIS Program commensurate with an assessment of risk, aimed at accurate decisions that do not violate unfair trade practice laws. Map the system inventory, risk ratings, mitigations, owners and third-party coverage.
• NYDFS Circular Letter No. 7 (July 11, 2024): An insurer should not use AIS or external consumer data in underwriting or pricing unless it can establish through a comprehensive assessment that the guidelines are not unfairly or unlawfully discriminatory. Map protected-class determination, proxy and inference analysis, and results for similarly situated individuals.
• Colorado SB 24-205: The bill addresses deployer impact assessments, making assessment documentation available, and disclosure of algorithmic discrimination to the attorney general within 90 days. Map the completed assessment, vendor documentation and an escalation path for discovered discrimination. Confirm current status as of November 2026.

Step 6: Keep the assessment current

An assessment completed once and filed will drift from the system it describes. Complete it before a system is used in underwriting or pricing, then define reassessment triggers in the assessment itself. Useful triggers include a retrained or replaced model, a new vendor or data source, a new line of business or state, a change in how human reviewers use the output, a material change in monitored outcomes, and a complaint pattern or discovered discrimination.

Assign three owners: someone who documents the assessment, someone independent of the build team who approves it, and someone who owns the refresh schedule. Also set a calendar-based review for systems with no triggering event, so quiet systems are not skipped. Version every assessment and keep prior versions, because a regulator may ask what you knew when a decision was made.

Connecting findings to runtime behavior

The most common weakness in these assessments is that the findings describe intended behavior while nothing confirms what the system does for a given decision. The assessment defines what an AI system should and should not do. Runtime enforcement is one way to make part of that definition operational.

Trussed enforces policy in the execution path of models, agents, tools and MCP servers. For individual interactions and tool calls, it can allow, redact, block, rate limit or escalate for human approval. In an underwriting or claims setting, that could mean redacting a protected attribute before a prompt reaches a model, blocking a tool call that retrieves data the assessment excluded, or escalating a proposed claim denial to a human approver. Enforcement generates audit-ready evidence, mapped to NAIC, NYDFS and NIST, that shows what was permitted and what happened for each interaction.

Be clear about the limits. Runtime enforcement does not replace population-level testing for disparate impact, design and data choices, vendor diligence or the assessment itself. Those findings need their own controls and evidence. The aim is to ensure that each mitigation the assessment can express as a rule on an interaction is enforced and evidenced, and that the remaining ones are tracked by other means.