ISO/IEC 42005 vs Colorado AI Act Impact Assessment: Can One Document Serve Both?

Two different kinds of instrument

ISO/IEC 42005:2025 is an international standard that gives guidance to organisations conducting AI system impact assessments. The assessments focus on how an AI system and its foreseeable applications may affect individuals, groups or society. The standard recommends performing assessments throughout the lifecycle, from design and development to deployment and post-market monitoring, and updating them as needed. ISO presents it alongside ISO/IEC 42001 (AI management systems), describing 42005 as a methodology for assessing the impacts of individual AI systems.

Colorado SB 24-205 is enacted as session law as of November 2026. It requires a deployer of a high-risk AI system, or a third party the deployer contracts, to complete impact assessments. The standard is voluntary guidance. The statute is a legal obligation. That difference shapes every row of the comparison below, and it means an ISO-aligned document is not a substitute for the statute simply because it follows the standard.

Element-by-element comparison

The table covers the elements that can be compared directly. Where a Colorado element has no stated ISO/IEC 42005 counterpart, it is treated as an addition rather than assumed to be covered.

• Status: ISO/IEC 42005: voluntary international guidance. Colorado: statutory duty for deployers of high-risk AI systems.
• Who performs it: ISO/IEC 42005: the organisation conducting the assessment. Colorado: the deployer, or a third party contracted by the deployer.
• Focus: ISO/IEC 42005: impacts on individuals, groups and society. Colorado: high-risk AI systems, with algorithmic discrimination as the central concern.
• Timing and triggers: ISO/IEC 42005: throughout the lifecycle, updated as needed. Colorado: annually, and within 90 days after an intentional and substantial modification.
• Content: ISO/IEC 42005: guidance on assessment content. Colorado: a specified content list in Sec. 6-1-1703(3)(b), completed to the extent reasonably known by or available to the deployer.
• Retention: ISO/IEC 42005: no statutory retention period applies. Colorado: the most recent assessment, all records concerning each assessment and all prior assessments, kept for at least three years.

Where a single document works

The lifecycle structure carries over well. An ISO/IEC 42005-style assessment already describes the system, its intended use and its foreseeable effects, and it expects revision as the system changes. That is a sound spine for the Colorado deployer assessment.

The Colorado qualifier on content, 'the extent reasonably known by or available to the deployer', also fits a document that records its own information limits. Deployers often depend on a developer for system documentation. Under the bill summary, developers receive a rebuttable presumption of reasonable care if they comply with specified provisions, including making available the documentation a deployer needs to complete an impact assessment. A good assessment records what the developer supplied and what was unavailable, so the document shows the basis for each statement.

The ISO framing is also broader than Colorado's. Assessing effects on individuals, groups and society goes beyond an algorithmic discrimination focus, so the ISO material can add depth without conflicting with the statute.

Where it needs Colorado-specific supplements

Four areas need explicit additions. First, the statutory content list. Each item in Sec. 6-1-1703(3)(b) should be mapped to a named section of the assessment, rather than assuming an ISO-based template covers it. Items with no counterpart in the template need their own content.

Second, the triggers. Colorado sets a calendar cycle and a modification event. ISO recommends updating as needed, which is looser. The unified document should adopt the Colorado triggers as its minimum schedule. The statute's phrase 'intentional and substantial modification' needs an internal definition, written down and applied consistently, so the 90-day clock starts on a defensible basis.

Third, retention. The duty covers the current assessment, prior assessments and all records concerning each assessment, for at least three years. Governance should decide which supporting records fall within that scope.

Fourth, ownership. Because a contracted third party may perform the assessment, someone inside the deployer should own both the annual cycle and the event-driven reassessment.

An assessment is not runtime evidence

An impact assessment describes intended or assessed behavior at a point in time, and then again at each periodic update. It does not show what a system was permitted to do or did on a given day between assessments. Those are separate record types, and a regulator or auditor reading the assessment may reasonably ask for the second to support the first.

This matters more when the cycle is annual or modification-triggered. A statement such as 'sensitive fields are not exposed' or 'consequential actions require human approval' is a claim. Operational records covering the periods between assessments turn it into something that can be checked.

Trussed enforces policy in the execution path of AI interactions and tool calls: allow, redact, block, or escalate for human approval. Enforcement happens at runtime, not after the fact, and it produces audit-ready evidence of what was allowed and what happened. That evidence can substantiate claims in an assessment record. Trussed is not an assessment-authoring tool, and it does not replace the assessment itself.