Is ISO/IEC 42005 Mandatory? Scope, Publication Date, and Common Misunderstandings

Is ISO/IEC 42005 mandatory?

ISO describes ISO/IEC 42005 as providing guidance to organisations that conduct AI system impact assessments. It also says the standard supports compliance with emerging laws and best practices. That wording positions 42005 as a way to do the work well. It does not present the standard as a legal requirement.

The EU AI Act is a different kind of instrument. Regulation (EU) 2024/1689, dated 13 June 2024, is a binding regulation of the European Parliament and of the Council. Its obligations apply because the law says so. A voluntary standard has no equivalent force by default.

A standard can still become binding on a specific organisation in three ways. A customer or counterparty can write it into a contract, so that conformance is a term you have agreed to. A regulator can reference it in correspondence or supervisory expectations. Or your own leadership can adopt it in internal policy, which makes it binding on your teams. In each case the obligation comes from that mechanism, not from the standard itself. For compliance leaders, the practical task is to check whether any of these mechanisms applies to you, and to record the answer.

Scope, publication year and status

ISO/IEC 42005 was published in 2025 and is designated ISO/IEC 42005:2025. It sits in the ISO/IEC JTC 1/SC 42 artificial intelligence portfolio, which also includes other AI standards under development, such as guidance on human oversight of AI systems. ISO's catalogue lists 42005 as a published standard under that committee.

The scope is the impact assessment of individual AI systems. ISO describes it as a practical framework and methodology for identifying, analysing, evaluating and documenting the impacts of an AI system. The unit of analysis is the system, not the organisation. The standard is categorised as an AI system impact assessment standard rather than a management system standard.

That distinction affects how you plan the work. An assessment under 42005 is an analysis of one system: what it does, whom it affects and what the documented impacts and mitigations are. It is produced at a point in the system's life and revisited as the system changes. It does not, on its own, describe how an organisation governs AI as a whole.

How ISO/IEC 42005 relates to ISO/IEC 42001 and the EU AI Act

These three instruments are often cited in the same sentence but do different jobs. Keeping them as separate workstreams in planning avoids duplicated effort and wrong assumptions in audit and procurement conversations.

• ISO/IEC 42005:2025: Guidance and methodology for AI system impact assessment. Operates at the level of an individual AI system. Output is a documented assessment of impacts.
• ISO/IEC 42001: The governance layer. In ISO's framing, it makes impact assessments a consistent and required part of AI governance across the organisation.
• Regulation (EU) 2024/1689 (AI Act): A binding EU regulation. Obligations arise from the law itself. Conformity with 42005 should not be assumed to equal compliance with it.

Common misunderstandings

Three misreadings are worth correcting directly, because each one misdirects compliance effort.

The first is treating 42005 as a certifiable requirement. ISO presents it as guidance for conducting impact assessments. If a vendor or auditor claims "42005 certification", ask which scheme the claim rests on and what text supports it. Without a clear answer, treat it as a statement about methodology, not a certificate.

The second is confusing 42005 with 42001. ISO says the two are designed to work hand in hand: 42001 ensures impact assessments are a consistent and required part of AI governance, while 42005 ensures those assessments are thorough, systematic and actionable. An organisation can ask "do we have a management system?" and "is this assessment sound?" and get different answers. Audit conversations should separate a management system requirement from assessment methodology guidance.

The third is assuming an impact assessment alone demonstrates operational control. An assessment is a documented analysis. It records intent and expected mitigations. It does not show that those mitigations are operating when the system runs in production. Treating the document as proof of control leaves a gap that an auditor or regulator is likely to ask about.

From documented intent to runtime enforcement and evidence

An impact assessment typically records limits that the system should respect. Examples include which data may reach a model, which tools an agent may call, and which outputs need review. Those statements are design-time intent. Nothing in the assessment enforces them while the system is running.

Closing that gap requires a separate control layer. The documented limits have to be translated into policy decisions that are applied to live interactions, and the decisions have to leave a durable record. Trussed operates at this layer. It enforces policy in the execution path across models, agents, tools and MCP servers, with decisions such as allow, redact and block, applied to individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence that is mapped to frameworks including the EU AI Act and NIST.

The scope here is narrow and worth stating plainly. Trussed does not certify, implement or automate ISO/IEC 42005, and it does not perform the impact assessment. The assessment remains your process. What runtime enforcement adds is evidence that the limits documented in an assessment are operating on production traffic, which is the part a document cannot show by itself.

One timing point for EU AI Act planning: as of November 2026, the Commission's Digital Omnibus on AI, proposed on 19 November 2025, would set fixed high-risk deadlines of 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products. It is a proposal, so track it as a variable in your plan rather than a settled date.