ISO/IEC 23894 for Generative AI: How to Assess Prompt, Output, and Sensitive Data Risks in LLMs

Context: what ISO/IEC 23894 provides and where it stops

ISO/IEC 23894:2023 gives guidance on how organizations that develop, produce, deploy or use AI can manage risk specific to AI. It describes processes for integrating risk management into AI-related activities and functions. It is guidance rather than a certifiable requirements standard, and it is technology-agnostic. It does not tell you what a prompt risk looks like or how to rate one.

The context stage is where you close that gap. For each LLM use case, record who can submit prompts, which data classes can reach the model through prompts, retrieval or tools, which tools and agents the model can invoke, where outputs go, and which regulatory obligations apply. This record drives everything after it.

Be explicit about the state of generative AI-specific ISO work. As of November 2026, ISO/IEC DTS 25568 (risks in generative AI systems), ISO/IEC CD 25590 (output data quality) and ISO/IEC AWI TS 42119-8 (testing prompt-based text-to-text systems) are listed as under development. They are not published standards and should not be cited as requirements. Say in your risk documentation that 23894 is being applied to generative AI without finalized generative AI-specific ISO guidance, and track those projects.

For risk categories, anchor the register to a named edition of the OWASP Top 10 for LLM Applications and record which edition you used. Editions differ, and the 2026 edition is the latest. OWASP material is community guidance, so cite it as a technical reference, not a compliance obligation.

Identification and analysis: three categories, plus tool permissions

Identification works best at the interaction level. Each prompt, response and tool call is a place where a risk can occur, so structure the register around three categories.

Prompt risk covers what enters the model: sensitive data submitted by users and prompt injection, where instructions in user input or retrieved content try to override intended behavior. Output risk covers what comes back: unsafe, inaccurate or data-leaking responses, and responses that trigger downstream actions. Sensitive data risk follows information across the whole path, through prompts, retrieval, tools, assistants and outputs. OWASP documents sensitive information disclosure as LLM02:2025, and notes that LLMs embedded in applications risk exposing sensitive information.

Add a fourth line item for tool and agent permissions. OWASP identifies agent privilege escalation as a risk class, and it behaves differently from a bad prompt or a bad answer. A model with broad tool permissions turns an output error into an action.

Analysis then rates likelihood and impact for each path. Likelihood depends on factors such as whether users are internal or external, whether untrusted content reaches the model, and how much data the model can reach. Impact depends on the data class involved and on what the output feeds, such as a draft for human review versus an automated decision or tool call.

Evaluation: risk criteria by category

Evaluation compares analysed risk with criteria you set in advance. Criteria should be written so that a reviewer can tell whether a given interaction met them. The table shows example criteria and where treatment usually sits. These are illustrative starting points, not values from the standard.

• Prompt risk: Criterion: regulated data classes must not reach the model unredacted; untrusted content must not alter system instructions. Treatment: runtime policy plus pre-deployment testing.
• Output risk: Criterion: responses feeding consequential decisions need review or approval. Treatment: mostly testing and human review, with runtime checks and escalation for defined conditions.
• Sensitive data risk: Criterion: no disclosure of data beyond the requester's entitlement. Treatment: data pipeline and access design before deployment, plus runtime redact or block.
• Tool and agent permission risk: Criterion: high-impact or irreversible tool calls require approval; permissions follow least privilege. Treatment: permission design before deployment, runtime allow, block, rate limit or escalate.

Treatment: organizational controls versus runtime policy

Treatment is where many registers lose contact with production. A useful discipline is to sort each treatment into one of two groups.

Some treatments sit outside the execution path. OWASP's guidance on data sanitization to keep user data from entering the training model is a data pipeline control. Model and vendor selection, use case approval, retrieval permission design, user training and red teaming before and during deployment also belong here. Output accuracy is largely in this group too, because no runtime rule makes a model factually correct. It is managed through testing, scope limits and human review.

Other treatments can be enforced as policy while an interaction happens. Sensitive fields in a prompt can be redacted before they reach the model. Disallowed content or instruction patterns can be blocked. Abnormal request volume can be rate limited. A high-impact tool call can be escalated for human approval, and low-risk interactions can be allowed and recorded. This mapping is analysis, not a prescribed list in the standard, and each action has a tradeoff: redaction can reduce answer quality, blocking produces false positives, and escalation adds latency.

Trussed is one way to enforce policy in the execution path. It applies allow, redact, block, rate limit and escalate-for-approval decisions across models, agents, tools, MCP servers, AI sites and coding assistants, at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact. Residual risk after treatment should still be recorded and accepted by a named owner.

Monitoring and evidence: what supports the register

Monitoring answers a narrow question: did the treatment operate as the register says it does? Policy documents cannot answer that. Interaction-level records can.

Useful evidence for each enforced treatment includes the policy version in force, the interaction or tool call it applied to, the action taken (allow, redact, block, rate limit or escalate), the rule that triggered it, any human approval decision, and a timestamp and identity. Aggregated, these records show whether a risk criterion is holding and whether thresholds need revisiting. Retention and data residency settings matter because evidence must exist when it is requested.

Trussed generates audit-ready evidence from enforcement itself, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency. In production it has run continuously for 18+ months in a regulated enterprise, with 100+ models under one policy plane. Its scope is individual interactions and tool calls. It does not provide model or dataset provenance or end-to-end tracing of agentic workflows, so those questions need other controls.

For framework alignment, treat the register as the hub. Each entry carries its 23894 stage references and cross-references to the NIST AI RMF and EU AI Act obligations that apply to the use case, with the mappings validated by legal and compliance teams against the primary texts.