ISO/IEC 42001 Annex A Controls Overview: Which Controls Need Runtime Evidence?

What an auditor is actually testing

ISO/IEC 42001:2023 specifies requirements for establishing, implementing, maintaining and continually improving an Artificial Intelligence Management System (AIMS). It is a management system standard. Annex A supplies the controls an organization draws on to manage AI risk, and an auditor will ask two questions of each control in scope: is it defined, and does it operate in practice.

Those questions need different evidence. A policy, an approval record or a role assignment shows that a control is defined. It does not show that an AI system behaved in line with the policy on a given day. NIST assessment guidance, which is a different framework and an analogy only, makes a similar point: control assessment is meant to verify that implemented controls meet their goals, not to generate paperwork to pass an audit.

The practical consequence is that teams need a method for deciding, control by control, what kind of evidence is proportionate. Without one, they either collect runtime data for controls that a document would satisfy, or they rely on documents for controls that describe live behavior.

Sorting control areas by evidence type

Organizing by evidence type is more useful than following clause order. The table below is a working method. Confirm the final classification for each control in your scope against the licensed standard and your certification body's expectations.

• Documented: Controls about intent and structure: policies, objectives, roles, responsibilities, resourcing. Evidence is current, approved, version-controlled documented information.
• Periodic review: Controls about judgment at points in time: risk and impact assessments, internal audit, management review. Evidence is dated records of the review, its inputs, decisions and follow-up actions.
• Runtime-generated: Controls about behavior while systems operate: use according to policy, human oversight, monitoring, data handling, third-party components in use. Evidence is records produced by the running system.
• Mixed: Many controls need two types. A documented oversight procedure needs records showing that oversight occurred. Treat the document and the runtime record as separate evidence items.

Controls that call for runtime evidence

Five areas describe behavior that only appears when AI systems run. For each, the audit question is the same: what was the system allowed to do, and what did it do?

Use of AI systems according to policy. A usage policy is a document. Evidence that it is followed is a record of individual interactions showing which policy applied and what happened as a result: permitted, modified, refused or escalated.

Human oversight. A procedure naming who approves what is documented information. Evidence of operation is a record that a specific action was held for approval, who approved or rejected it, and when.

Monitoring. A monitoring plan is a document. Auditors will expect to see monitoring outputs over time, including events that crossed a threshold and how they were handled.

Handling of data. A data handling rule states what may be sent where. Evidence of operation shows the rule being applied to actual traffic, such as sensitive fields removed before a request left the boundary.

Third-party components. A supplier assessment is a periodic review. Evidence that the components in use behaved within policy comes from records of calls to external models, tools and services.

Over-collection is the opposite risk. Controls that rest on documents and governance processes do not gain strength from large volumes of operational data. Spend runtime evidence effort where the control text describes behavior.

Where enforcement in the execution path can and cannot supply evidence

Policy enforcement in the execution path produces evidence as a by-product of doing its job. Trussed enforces policy across models, agents, tools, MCP servers, AI sites and coding assistants, and can allow, redact, block, rate limit or escalate for human approval. Because the decision is enforced at runtime, not reviewed after the fact, each decision yields audit-ready evidence at the level of individual interactions and tool calls. This directly serves the controls above that ask what a system was allowed to do and what it did. Trussed has run continuously in production in a regulated enterprise for more than 18 months, and its evidence is mapped to the EU AI Act and NIST, among other frameworks, which lets one record support more than one audit conversation.

The limits follow from the design. An enforcement point can only describe interactions that pass through it. Model provenance, dataset provenance, transaction-level governance and end-to-end tracing of agentic workflows need other evidence sources. Documented controls and periodic reviews also remain the organization's work.

So this evidence supports an ISO 42001 effort for the runtime-dependent controls. It does not make an organization certified, because certification concerns the whole management system.