Choosing AI Risk Treatment Options Under ISO/IEC 23894

Where treatment sits in the ISO/IEC 23894 process

ISO/IEC 23894:2023 gives guidance on managing AI-specific risk for organizations that develop, produce, deploy or use AI products, systems and services. Its process follows the structure of ISO 31000:2018, which describes identifying, analyzing, evaluating, treating, monitoring and communicating risk. Treatment is the step that follows evaluation and turns a risk finding into action.

The relevant clause headings are 6.3.4 (defining risk criteria), 6.4.2.5 (identification of controls), 6.5.2 (selection of risk treatment options) and 6.5.3 (preparing and implementing risk treatment plans). The order matters. Risk criteria must exist before any option can be chosen, and a treatment decision is incomplete until it becomes a plan with controls that someone implements.

The NIST AI RMF uses slightly different vocabulary. It lists mitigating, transferring, avoiding or accepting risk. This guide treats those as corresponding to modify, share, avoid and retain. The correspondence is a practical working assumption, so check wording against the standard text your organization has adopted.

Mapping each option to control types

Each option implies different controls and a different burden of proof. The runtime actions in the right-hand column are a design approach, not a requirement of the standard. They apply only to risks that arise in individual interactions or tool calls. Risks tied to training, design or organizational conduct need controls outside the execution path.

• Avoid: Remove the use case, withhold deployment or retire the system. Mostly directive and recovery controls. Runtime: block a prohibited use or tool call while a retirement plan is executed.
• Modify: Reduce likelihood or impact through recalibration, impact mitigation, or compensating and detective controls. Runtime: redact sensitive content, block disallowed actions, rate limit, or escalate for human approval.
• Share: Transfer part of the exposure through contracts, insurance or third-party arrangements. Monitoring and documented controls on third-party AI remain your responsibility.
• Retain: Accept the risk within tolerance. Needs a recorded tolerance comparison, an accountable approver, ongoing monitoring and re-evaluation triggers. Runtime: allow, with enforcement records retained.

What can be enforced at runtime and what cannot

Separate controls by where they operate. Interaction-level and tool-call-level risks, such as exposure of sensitive data in a prompt or an agent invoking a tool it should not, can be addressed by a control that evaluates each request and decides among allow, redact, block, rate limit or escalate for human approval. A modify decision for such a risk should name the specific action, the condition that triggers it and the owner of the policy.

Severity can set the strength of enforcement. Oversight and resources should scale with risk, so a high-impact tool call may require human approval while a low-impact one is allowed and recorded. Escalation only counts as a control if an approver is defined and the decision is captured.

Other treatments sit outside the execution path. Governance roles, supplier agreements, staged release, plans to halt a system and tolerance recalibration are organizational or lifecycle controls. Documents alone do not enforce them, so the plan should still say who performs each one, when, and what record results.

A frequent failure is a treatment plan that names a control with no enforcement point, so the documented plan and actual AI behavior diverge. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, covering individual interactions and tool calls. Enforcement happens at runtime, not review after the fact, and each decision produces audit-ready evidence. It does not replace the organizational controls described above.

Criteria for accepting residual risk

Residual risk is the risk remaining after treatment. It affects end users and affected individuals and communities, so acceptance is a governance decision rather than a technical sign-off. A defensible acceptance meets four conditions.

First, the residual level does not exceed the documented tolerance. Second, the decision comes from a role with defined authority, and the record shows who decided, when, and on what information. Third, residual negative risks are documented for downstream acquirers and end users where relevant. Fourth, the acceptance has a review trigger, such as a change in model, use case, regulation or incident pattern, or a scheduled recalibration of tolerance.

Some conditions rule out acceptance. The AI RMF states that when significant negative impacts are imminent, severe harms are occurring or catastrophic risks are present, development and deployment should stop safely until risks are sufficiently managed. Define in advance what halting means for each system, so the avoid option is executable rather than theoretical.