ISO/IEC 23894 Risk Register Fields for Large Language Model Applications

What the standard provides and what it leaves to you

ISO/IEC 23894:2023 provides guidance on how organizations that develop, produce, deploy or use AI-based products, systems and services can manage risk specifically related to AI. ISO describes it as helping organizations integrate risk management into AI-related activities and functions. As of November 2026, the 2023 edition is the current one. It is voluntary guidance and creates no legal obligation by itself.

Because it describes a process, the standard does not prescribe a register layout. A register described as consistent with ISO/IEC 23894 is therefore an organizational design choice. The test is whether the fields let a reviewer follow each risk through the process stages and see what was decided at each one.

A useful starting convention is to write each risk statement as an effect on objectives, which follows the ISO 31000 definition of risk used in the OWASP LLM governance checklist. A statement such as "an attacker-supplied instruction in retrieved content causes the assistant to disclose customer records" is more useful than "prompt injection" because it names the objective at stake and the path to harm.

Mapping process stages to register fields

The table below translates each stage into fields and an LLM-specific example. Analysis and evaluation are combined because they share the same criteria fields. Treat the field names as a starting set to adapt, not as terms taken from the standard.

• Context: Fields: application name, business objective, deployment boundary, framework and edition mapped. LLM example: a claims-summarization assistant with retrieval access to policy documents.
• Identification: Fields: risk statement, risk source category, affected asset or interaction, threat-model reference. LLM example: prompt injection through retrieved content reaching a tool call.
• Analysis and evaluation: Fields: impact rating, likelihood rating, scoring method and version, justification, acceptance threshold, evaluation outcome. LLM example: sensitive data disclosure rated high impact because outputs reach end users.
• Treatment: Fields: response option, existing controls, planned controls, control type, target date, residual risk. LLM example: redact personal data in outputs, block unapproved tool calls.
• Monitoring and review: Fields: owner, review cadence, last review date, trigger events, evidence reference. LLM example: review after a model change or new tool is added.
• Communication: Fields: accepted residual risk, audience informed, date communicated, linked model or risk card where one exists. LLM example: output reliability limits disclosed to downstream users.

Representing LLM-specific risk sources

Generic registers tend to carry a single "technology risk" category, which hides the differences that matter for treatment. A controlled vocabulary for risk source category makes entries comparable and searchable. NIST's Generative AI Profile is a reasonable basis: it defines risks novel to or exacerbated by generative AI, separates technical and model risks from information security and ecosystem or societal risks, and names prompt injection and data poisoning as attacks that generative AI is vulnerable to. The OWASP Top 10 for LLM Applications 2026 describes the most critical security risks for LLM-powered applications. Take its entry names directly from the OWASP publication rather than from memory of earlier versions.

At minimum, give distinct entries to prompt injection, sensitive data disclosure, unsafe tool calls and output reliability. They have different sources, different affected interactions and different treatments, so combining them produces a register entry no one can score or test.

The affected asset or interaction field should be specific. Name the data store, the tool, the user-facing channel or the agent action involved. Add a threat-model reference field as well. NIST SP 800-218A recommends including AI model-specific vulnerability and threat types in risk modeling, and a reference lets reviewers trace a register entry back to that analysis.

If you use an external scoring method such as OWASP AIVSS, record the scoring version and the qualitative justification beside the score. The agentic AIVSS document is numbered v0.5, so a score without a version is hard to reproduce later.

Design-time fields and runtime-dependent fields

NIST's Manage guidance calls for tracking negative risks throughout the AI system lifecycle and for documenting unmitigated risks for downstream acquirers and end users. That supports splitting the register into two groups of fields.

Design-time fields are completed during assessment and revisited on a schedule. These include risk statement, source category, affected interaction, impact and likelihood criteria, planned controls, owner and review cadence. A person can complete and approve them without production data, though test and evaluation results should inform them.

Runtime-dependent fields answer a different question: did the treatment operate? These include existing control status, residual risk after treatment, trigger events, and the evidence reference. If these are filled in by manual attestation, the register records what someone believes. If they point to records produced when the control acted, the register records what happened.

A practical rule is to avoid a control status of "implemented" without a reference to something checkable. The evidence reference field should hold an identifier or location for records such as policy decisions, enforcement actions, escalations and their outcomes, and the retention record for those artifacts. Which of these an auditor will accept depends on the audit scope and the auditor, so agree the evidence types with the audit function before the register is populated, not during the audit.

Where runtime enforcement fits

Some treatments recorded in a register are policy decisions that can be enforced at the level of an individual interaction or tool call: allow, redact, block, rate limit, or escalate for human approval. When a treatment is written that way, it can be enforced at runtime in the execution path rather than reviewed after the fact, and the enforcement can produce audit-ready evidence that the register entry references.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates audit-ready evidence from that enforcement. It is not a risk register or GRC tool. The register stays where your risk function maintains it, and the evidence reference field points to the records enforcement produces. Trussed does not cover model provenance or dataset lineage, so those fields need other sources.