Documenting AI Risk Decisions for ISO/IEC 23894 and ISO/IEC 42001 Audits

What an auditor is actually testing

ISO describes ISO/IEC 23894:2023 as guidance on managing AI-specific risk for organizations that develop, produce, deploy or use AI products, systems and services. It is not a certifiable requirements standard. ISO/IEC 42001:2023 is different. It specifies requirements for establishing, implementing, maintaining and continually improving an AI management system, and it covers AI projects from risk assessment through treatment of those risks. In practice, 42001 sets what the management system must do, and 23894 is a reference for how the risk process can be run.

That split shapes how audit teams approach a risk decision. They are unlikely to ask whether you have a risk policy. They will pick a specific decision, such as accepting a risk for a particular use or granting a control exception, and ask you to walk from the identified risk to the decision, the owner, the control and the proof the control worked. A record that exists but cannot be walked this way is present but not verifiable.

Most failures here come from structure, not effort. Decisions are made, but they sit in tickets, slide decks and meeting notes with no shared reference, so the chain breaks at the first handoff.

Mapping the record to ISO/IEC 23894 and ISO/IEC 42001

The 23894 process activities cover context and criteria, risk identification, risk analysis, risk treatment (selecting options and preparing and implementing treatment plans), monitoring and review, communication, and recording and reporting. A single decision record touches most of them. Context and criteria feed the first two elements of the model, analysis feeds the assessment, treatment selection and plan implementation feed the treatment and control linkage fields, and monitoring and review feed the cadence and evidence fields. Published section numbering should be checked against your licensed copy of the standard before you cite it in procedures.

On the 42001 side, the management system expects documented information on AI risk assessment, AI risk treatment and the AI system impact assessment, which sit in the planning clause (6.1.2 to 6.1.4). The treatment record is where Annex A controls are tied to specific risks, and where residual risk acceptance should be documented. Confirm clause and Annex A references against the published text, and keep your Statement of Applicability entries pointing to the same decision records so the two documents do not diverge.

Two gaps recur in practitioner guidance. The first is treating the AI system impact assessment and the risk assessment as one document. Keep them as separate records that cross-reference each other. The second is identifying risk only at deployment. Risk identification should span the lifecycle, so the record should show when the risk was first raised and how it has been revisited.

Evidence an auditor can verify versus assertions they cannot

An auditor can sample and test a record. An assertion has to be taken on trust. The table separates the two for the most common elements of a decision.

• Treatment choice: Verifiable: a dated record naming the specific control implementation, such as its configuration and scope. Assertion: a plan that says only 'apply A.7.3'.
• Risk acceptance: Verifiable: a record stating the residual risk, the approver and the date. Assertion: a statement in meeting notes that leadership was comfortable.
• Ownership: Verifiable: a named role with documented responsibilities and a review date. Assertion: 'the AI team owns it'.
• Control operation: Verifiable: system-generated records from the deployed context that can be sampled by date or use. Assertion: a policy document stating the control exists.
• Ongoing review: Verifiable: dated review records showing tolerances were revisited from monitoring results. Assertion: a calendar entry or a stated intention to review.

Design evidence, operating evidence and runtime enforcement

Design evidence shows a control was appropriately specified: the policy, the approved treatment plan, the configuration standard. Operating evidence shows the control ran as designed over time. A decision record usually supplies the first and points to the second. Auditors tend to give more weight to operating evidence, because documented decisions and runtime behavior drift apart when nothing ties them together.

For controls that act on individual AI interactions and tool calls, operating evidence can be generated at the point of enforcement rather than reconstructed afterward. Trussed enforces policy in the execution path, with actions such as allow, redact, block and escalate for human approval, and it produces audit-ready evidence of what the AI was allowed to do and what it did. That evidence can be referenced from a decision record as proof that a policy-level treatment was enforced at runtime, not reviewed after the fact.

The scope is specific. This evidence covers individual interactions and tool calls. It does not replace the decision record, the risk assessment or the acceptance by an accountable owner, and it does not cover model lineage, dataset provenance or end-to-end workflow tracing. No tool delivers ISO/IEC 42001 certification. Certification depends on your management system and the auditor's assessment.