ISO 42001 Audit Evidence Requirements: How 42001, 23894, 5338 and 42005 Differ

Requirements versus guidance in an audit context

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an AI management system (AIMS). It is a management system standard, and that requirement language is what an auditor assesses an organization against. It is the only one of the four that is a certifiable standard.

The other three play supporting roles. ISO/IEC 23894:2023 is guidance on AI risk management and describes processes for implementing and integrating it. ISO/IEC 5338:2023 defines processes and associated concepts for the life cycle of AI systems based on machine learning and heuristic systems. ISO/IEC 42005:2025 is guidance on the societal and human impacts of AI, and ISO describes it as complementing 42001 and 23894.

In practice, the audit criteria come from 42001, while the other standards give you a defensible method for producing the records. A risk register built on 23894 practice is evidence of 42001 risk work, not a separate audit target. ISO/IEC 42006:2025 is a different kind of document again: it sets requirements for the bodies that audit and certify AI management systems, so it governs the certification body rather than your evidence.

Evidence expected by type, with each standard's role

The table is organized by evidence type rather than by standard, because an auditor samples records, not standards. Descriptions are general categories. Map each one to the specific clauses and Annex A controls in your licensed copy of 42001 before you rely on it.

• Management system records (42001, requirement): AIMS scope, AI policy, objectives, assigned roles and accountability, internal audit results, management review minutes and corrective actions. Mostly documentary, but audit, review and corrective action records show the system running.
• Risk assessment outputs (23894, guidance; 42001, requirement): Risk assessment results, treatment decisions, acceptance rationale and monitoring or review records. The assessment is documentary. Evidence that treatments were applied and reviewed on schedule is operational.
• Lifecycle process records (5338, guidance): Records showing that defined life cycle processes were followed for each in-scope AI system, such as requirements, design, verification, validation, change and operation records. Operational where they show a process executed for a specific system.
• Impact assessment documentation (42005, guidance): Documented assessment of societal and human impacts for a system, with scope, findings and how results fed into risk treatment and release decisions. Documentary, with operational value when linked to decisions taken.
• Runtime operating evidence (cuts across all four): Records of what an AI system was permitted to do and what it did in individual interactions and tool calls. No single standard owns this category, but it shows that stated controls operated in production.

Documentary versus operating evidence

Documentary evidence states intent: policies, procedures, risk assessments, impact assessments and process definitions. It answers the question of whether the organization decided what should happen. Operating evidence shows that the decision was carried out: dated review records, approvals tied to specific systems, treatment actions closed out, and records of system behavior in use.

An audit is often described as an external review at a point in time, although assessments and audits may also be continuous and may be internal or external. Teams that prepare only documentary artifacts tend to pass a document review and then struggle when an auditor samples a specific system and asks for the trail. The gap is between documented intent and demonstrable operation.

Because 42001 embeds policies, procedures and accountability across operations, evidence should show accountability in practice. A named risk owner in a policy is documentary. A record of that owner approving a specific treatment for a specific system is operating evidence. Scope also matters. A narrowly scoped evidence plan can create a false sense of assurance, so define explicitly which systems, lifecycle stages and use cases the evidence covers.

Building one consolidated evidence matrix

The aim is to collect each artifact once and reference it wherever it supports a requirement or a guidance practice. Reuse an artifact across standards only after confirming the overlap against the standards' full text. The steps below keep the matrix auditable.

• 1. List evidence by type: Use the four categories plus runtime operating evidence as rows, and the AIMS clauses and controls in scope as columns.
• 2. Tag the role: Mark each item as a 42001 requirement or as supporting guidance from 23894, 5338 or 42005.
• 3. Classify documentary or operational: Record whether the item states intent or shows execution, and who produces it.
• 4. Assign one source of truth: Name a single system of record per artifact, such as the risk register, and reference it from other rows instead of copying it.
• 5. Set scope and sampling: Define which AI systems are covered and what an auditor could sample for each.
• 6. Record gaps: Flag rows with a document but no operating evidence, or the reverse.

Where runtime evidence fits

Runtime evidence is the least settled row in most matrices. Policies, risk assessments, lifecycle records and impact assessments describe what should happen. They do not by themselves show what a deployed system was allowed to do or did on a given day. That is operating evidence, and it supports the part of a 42001 program that demonstrates controls ran.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval. Because enforcement happens at runtime, not after the fact, it produces audit-ready evidence of individual interactions and tool calls. That evidence can populate the operating-evidence row of the matrix and can be retained under configurable retention settings in a self-managed deployment in the customer cloud.

The scope is limited. Trussed does not certify an organization against ISO/IEC 42001, does not cover model or dataset provenance, and does not provide end-to-end tracing of agentic workflows or transaction-level governance. It addresses one evidence category within a broader program.