ISO/IEC 5338 Audit Evidence: A Process-by-Process Guide
Compliance Guide

ISO/IEC 5338 Audit Evidence: What to Collect for Each Process

ISO/IEC 5338 organizes AI system life cycle work into distinct processes, and each one produces a different type of audit evidence: risk records, requirements traceability, design documentation, verification and validation results, deployment approvals, and ongoing operational logs. Auditors and customers increasingly expect evidence tied to the specific process it came from, not a single generic compliance folder.

Explore Runtime Governance Talk to an Expert

ISO/IEC 5338 is an international standard addressing AI system life cycle processes, developed under ISO/IEC JTC 1/SC 42, the joint technical committee responsible for AI standardization. It is structured to align with the life cycle process approach used in ISO/IEC/IEEE 12207 for software and ISO/IEC/IEEE 15288 for systems, adapted with AI-specific considerations. Standards in this family generally require documented outputs, such as plans, records, and approvals, as evidence that a process was actually performed, rather than prescribing a specific tool or format.

That distinction matters for audit preparation. A compliance program built around a single policy document will not satisfy an auditor looking for process-level proof. Each life cycle stage is expected to leave a distinct evidentiary trace, and internal reviews, customer due diligence, and external certification audits increasingly probe for that granularity rather than accepting a general governance narrative. Organizations preparing for ISO/IEC 5338-aligned audits should treat evidence collection as a per-process exercise and verify exact clause language against the published standard, since named process titles and specific evidence lists vary by edition and should be confirmed directly against the ISO/IEC 5338:2023 text before an audit.

Evidence Expectations by Life Cycle Process

  • Risk Management: Evidence typically includes documented risk identification, assessed severity and likelihood, chosen mitigations, and records of who approved acceptance of residual risk. This process connects closely to ISO/IEC 23894 risk guidance and should show a decision trail, not just a static risk list.
  • Requirements Analysis: Evidence includes recorded functional and non-functional requirements, including data and performance constraints specific to AI systems, along with sign-off from stakeholders responsible for the requirement set.
  • Design: Evidence includes architecture and design decision records that explain why a given approach was chosen, including how identified risks were addressed in the design rather than only in a policy document.
  • Verification and Validation: Evidence includes test plans, test results, performance metrics, and traceability records that link specific requirements to specific test outcomes. This is often the most scrutinized process during external audits.
  • Deployment: Evidence includes documented release approvals, readiness checks, and confirmation that verification results were reviewed before the system moved into production.
  • Operation and Monitoring: Evidence is largely continuous rather than a one-time artifact: logs of system behavior, performance drift, and incident handling that demonstrate the system is still operating within its validated boundaries.

Where Runtime Signals Can Serve as Ongoing Evidence

Operation and monitoring is different from the earlier life cycle processes because its evidence accumulates continuously rather than being produced once and filed away. For AI agents operating in production, this can include agent decision logs, tool-call records, and policy enforcement events such as blocked or approved actions. These signals can support audit evidence for operation-and-monitoring-type processes and, where access control decisions are involved, for risk management processes as well, but only if they are retained with sufficient context and integrity guarantees and mapped explicitly to the process output they are meant to demonstrate. Presenting raw logs to an auditor without that mapping is generally not sufficient.

Trussed AI provides runtime governance for enterprise AI agents, including runtime policy enforcement, runtime monitoring, and audit logging of agent and tool activity. Where an organization already uses this kind of runtime control layer, the resulting logs can be a useful input into operation and monitoring evidence, provided the organization confirms coverage is complete across all production agents and that log fields are tied back to the specific ISO/IEC 5338 process they are intended to support.

Common Evidence Gaps and How to Close Them

  • Inventory which life cycle processes are currently documented versus handled informally, before an audit request arrives rather than during one.
  • Assign a named owner for evidence collection at each process so gaps are not discovered only during external review.