Runtime logs as ISO 42001 audit evidence: how policy documents differ from execution-path records

Two kinds of evidence answer two different questions

Policy documents, procedures and risk assessments answer the question of what the organization intended and how it designed its AI management system. Execution-path records answer a different question: did a specific control operate on a specific event in production?

ISO describes certification against ISO/IEC 42001:2023 as voluntary, a way to obtain independent confirmation that an AI management system meets the standard's requirements (as of November 2026). Independent confirmation of that kind rests on objective evidence. Clause 8 concerns operation, so operational controls need evidence that they ran, not only that they were specified. Clause 9 covers performance evaluation and internal audit, which means someone must be able to examine how controls performed.

General security assurance guidance draws the same line. NIST treats the review of policies, procedures, rulesets and configurations as a separate artifact type from the review of system logs, and describes assessments as determining whether controls are operating as intended. NIST also defines an audit log as a record providing documentary evidence of specific events. The terms intent and operation are our framing, but the distinction is consistent with that guidance.

What each type of evidence can and cannot support

Most organizations preparing for audit hold strong evidence of design and weaker evidence of operation. The table separates the artifacts by what they can establish. Mapping to individual Annex A controls is a per-control decision: for each applicable control, record which artifact evidences the design and which evidences operation.

• Policies and procedures: Show documented intent, scope and responsibilities. Cannot show that a control ran on any event.
• Risk assessments: Show that risks were analyzed and treatments chosen. Cannot show that a treatment was applied to a given interaction.
• Rulesets and configuration: Show what was configured at a point in time. Cannot show which rule governed a particular event.
• Application and API logs: Show that activity occurred. Usually omit the policy applied and the enforcement decision.
• Execution-path records: Show, per event, which policy applied and what the decision was. Support claims that controls operated, within the scope they cover.
• Internal audit and review records: Show that review took place. Their weight depends on the underlying records being examined.

Why ordinary application logs leave a gap

Application and API logs are built for debugging and security monitoring. They typically capture that a request occurred, its source and its status. They rarely capture the rule invoked or the decision the policy produced, which is the information that links documented intent to demonstrated operation.

Event selection is a design decision. Logging scope should follow the controls being evidenced rather than default application behavior. Guidance from OWASP also notes that audit and transaction records are usually collected for different purposes than security event logs and often should be kept separate. Records of AI policy decisions would reasonably sit with the former, an independently verifiable trail that supports reconstruction and review.

There is a tradeoff. Logging prompts or tool-call payloads in detail makes the logs themselves sensitive. They then need encryption, retention rules and privacy review, and they may be disclosed during an audit. Decide what content a record must hold to evidence the control, and no more, before enabling detailed capture.

Testing whether your evidence would hold up

Evidence for current and future control assessments should be planned when controls are selected, not gathered shortly before an audit. These steps give a practical readiness check.

• Inventory logged event types: List what is logged today and whether each entry includes the rule or control invoked and the outcome. Gaps against the attribute list show what is missing.
• Assign an evidence artifact to each control: For every applicable control, name the document that evidences design and the record that evidences operation, and who owns each.
• Run a single-event trace: Pick one interaction or tool call and follow it from the record to the policy and version that governed it. If you cannot, an auditor will not be able to either.
• Define retention and access: Set retention periods, encryption and access rules for decision records before enabling detailed capture.
• Document how integrity is shown: Record the mechanism, such as access controls and audit of the logging process, and review it as part of internal audit.

Where enforcement in the execution path fits

Evidence reconstructed after the fact depends on inference. Evidence generated at the point where the control operates is a by-product of the decision itself. That is the reason to capture audit fields where policy is applied, in the execution path, rather than assembling them from separate systems later.

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. Decisions such as allow, redact, block, rate limit and escalate for human approval apply to individual interactions and tool calls, and the enforcement produces audit-ready evidence continuously. Deployment is self-managed in the customer cloud, with configurable retention and data residency.

This addresses operational evidence only. It does not replace the policies, risk assessments and management system documentation an auditor will also review, and it does not determine a certification outcome. Evaluate any approach, including this one, against the attributes above.