How to Conduct an ISO/IEC 42005 Impact Assessment for AI Lending and Credit Decisions

Where the assessment sits next to model risk management

ISO/IEC 42005:2025 is a voluntary standard for AI system impact assessment. ISO describes it as a framework for identifying, evaluating and documenting the impacts of AI systems, and as a detailed methodology for assessing the effects of individual systems. It is designed to work with ISO/IEC 42001. In ISO's framing, 42001 makes impact assessment a consistent and required part of AI governance, while 42005 makes those assessments thorough, systematic and actionable.

For a lender, that division is useful. Your model risk management function already asks whether a model is conceptually sound, validated and monitored. An impact assessment asks a different question: what does this system do to the people it affects, and who decided that was acceptable? The two should share a model inventory and an issue-tracking process, but neither replaces the other. The steps below are a practitioner structure consistent with the standard's method. Adapt them to your own policy and let your model risk and compliance teams own the final template.

Step 1: Scope the assessment and set review triggers

The unit of assessment should be a single AI system in a single credit use, such as underwriting recommendations, line assignment, collections prioritization or an applicant-facing assistant. Assessing "AI in lending" as a whole produces a document nobody can act on.

For each system, write down the intended use, the populations and products it is meant for, and the uses that are out of scope. Then record foreseeable misuse. Examples include applying a model to a product or population it was not built for, staff feeding in data that was not approved, or an AI agent calling tools beyond its remit.

The NIST AI RMF Playbook describes impact assessments run at key lifecycle stages and tied to the frequency of system updates. Translate that into explicit triggers, each with a named approver for closure:

• Before design approval, to shape requirements
• Before production release
• A new model version, prompt or tool permission
• A change in data inputs or data sources
• A new use, product or applicant population
• A reported negative impact from an applicant, operator or reviewer

Step 2: Identify stakeholders and credit-specific impacts

Affected parties extend beyond the applicant. Include applicants, borrowers and co-applicants, the underwriters and loan officers who use outputs, customer service staff who explain decisions, compliance and model owners, and the communities a lending program serves. The NIST Playbook notes that impact assessments may draw on operators, users and potentially impacted individuals, and recommends a way for impacted people to give feedback about negative impacts. Build that feedback path into the process rather than treating it as optional.

For credit, four impact categories cover most of the ground. Adverse action: how the system's output contributes to a denial or less favorable terms, and whether reasons can be traced to it. Disparate impact: whether outcomes differ across groups in ways the institution must examine. Explainability: whether the explanations given to applicants and reviewers are accurate and useful. Data use: which inputs the system sees, whether they are approved for this purpose, and whether personal data is exposed beyond need. Map each category to the requirements that apply to you, such as ECOA and Regulation B and your model risk policy, with compliance and counsel.

For each stakeholder group and category, record severity and likelihood. The NIST Playbook describes risk as approximately impact multiplied by likelihood, or a qualitative combination of the two, which is enough to rank mitigations. Reuse the findings when you design applicant-facing explanations. A NIST-hosted explainability document notes that documented impact and risk assessments help with explaining a system's impact on individuals.

Step 3: Document outputs in a form examiners can review

A usable assessment record contains the system description, intended use and misuse, stakeholder list, rated impacts, mitigations with owners, residual risk, the approval decision with date and approver, and the triggers that reopen it. Store it where model risk management already works: the model inventory entry, linked to validation findings and to the issue tracker that follows mitigations to closure.

The common weakness is that the record is point-in-time. It states what the system was designed to do. An examiner will also ask what the system was permitted to do and what it did over the period since approval. If the only answer is the original document, the assessment is hard to defend. Plan from the start which production evidence will feed each review, so that a trigger review compares assumptions against recorded behavior.

What runtime records can and cannot evidence

Runtime controls operate on individual interactions and tool calls in the execution path. They can show what was allowed, changed or stopped at the moment of use. They do not establish how a model was built or where its training data came from. Keep that boundary explicit in the assessment so each claim cites the right kind of evidence.

• Data use: Runtime: records of which data was redacted or blocked in individual interactions. Outside the path: approval of data sources and dataset provenance.
• Misuse and scope limits: Runtime: blocked or escalated requests and tool calls outside the permitted scope. Outside the path: the definition of intended use itself.
• Human oversight: Runtime: records of escalations for human approval and the outcome. Outside the path: reviewer training and staffing.
• Disparate impact: Runtime: limited to the interactions the system handled. Outside the path: outcome testing, validation and fairness analysis.
• Model lineage: Runtime: none. Outside the path: development, versioning and validation records.

Where runtime policy enforcement fits

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Each request or tool call can be allowed, redacted, blocked, rate limited or escalated for human approval. Because the policy is enforced at runtime, not reviewed after the fact, the enforcement decisions themselves become continuous, audit-ready evidence of what the AI was permitted to do and what happened. That evidence is mapped to frameworks including NAIC, NYDFS, EU AI Act and NIST.

For a credit impact assessment, this gives review triggers something concrete to test: whether the redaction, block and escalation rules assumed in the assessment were in force, and how often they acted. Trussed does not provide model provenance, model lineage or dataset provenance, and it does not trace agentic workflows end to end. Those remain in your development and validation records.

Trussed has no financial-services customers to cite. Insurance, a regulated financial sector, is where it is deepest. It has run continuously in a regulated enterprise production environment for more than 18 months, with 99.95% uptime on live traffic and more than 100 models under one policy plane. Deployment is self-managed in the customer cloud, with configurable retention and data residency.