ISO/IEC 23894 vs HIPAA Security Rule Risk Analysis for Clinical AI Systems

Two instruments with different jobs

The HIPAA Security Rule applies to electronic PHI: individually identifiable health information transmitted by or maintained in electronic media. Under 45 CFR 164.308(a)(1)(ii)(A), a covered entity or business associate must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI it holds. This is a required implementation specification. As of November 2026, the current text of the rule still lists it as required.

The unit of analysis is the ePHI, wherever it sits. ONC states that a full risk analysis is required even with a certified EHR, and that the requirements cover all ePHI maintained, not only what is in the EHR. The regulatory text does not mention AI systems, prompts, outputs, or agent tool calls. Applying the analysis to them is an interpretation that most organizations will make, but it is not a stated requirement.

ISO/IEC 23894 approaches the problem from the other direction. It is an AI-specific risk management framework, so its unit of analysis is the AI system and the context in which it is used, not a category of data. That makes it broader than ePHI. It is also not a legal obligation, so it cannot substitute for the HIPAA analysis. It is a way to make sure the AI-specific part of the risk picture is examined at all.

Side-by-side comparison

The table contrasts the HIPAA text with the role an AI risk management process plays. The right-hand column describes how the framework is typically applied in a program, and each organization defines the specifics in its own methodology.

• Scope: HIPAA: ePHI created, received, maintained, or transmitted by the regulated entity. ISO/IEC 23894: risks arising from AI systems, including those that do not involve ePHI.
• Unit of analysis: HIPAA: ePHI and the systems that hold it. ISO/IEC 23894: the AI system, its use case, and its operating context.
• Risk process: HIPAA: assess potential risks and vulnerabilities to confidentiality, integrity, and availability. ISO/IEC 23894: a structured AI risk management process the organization applies to each AI system.
• Treatment: HIPAA: implement security measures sufficient to reduce risks to a reasonable and appropriate level. ISO/IEC 23894: treatments chosen for AI-specific risks, which may be technical or procedural.
• Documentation: HIPAA: documented analysis, measures, and security incidents with their outcomes. ISO/IEC 23894: records of the AI risk process, in a form the organization sets.
• Monitoring and review: HIPAA: regular review of activity records; ONC advises reviewing the analysis each year or when systems change. ISO/IEC 23894: ongoing monitoring and review of AI risk as the system and its use evolve.

Where each leaves gaps for clinical AI

A conventional HIPAA analysis is organized around systems that store or transmit ePHI. A clinical AI deployment adds interaction-level behavior that such an analysis rarely itemizes. Three examples are PHI entering prompts and returning in outputs, an agent reaching data or tools beyond what its task needs, and an unsafe output reaching a clinical workflow. The HIPAA text does not name these. They can be brought within the analysis as risks to the confidentiality, integrity, or availability of ePHI, but only if the team lists them deliberately.

An AI risk process has the opposite weakness. It prompts the team to identify AI-specific risks, but it does not make the ePHI analysis mandatory and does not define what the audit controls standard requires. A program built only on an AI framework can produce a thoughtful risk register that still fails to show the required HIPAA analysis, risk management measures, and activity review.

The practical gap in both cases is the same. Periodic, document-based assessments describe risk at a point in time. They do not by themselves limit what an AI system does during a given interaction.

Building one combined risk analysis

Avoid running two parallel assessments. Start from the HIPAA required baseline and extend it with the AI-specific process, so each AI risk lands in a single register tied to a single treatment record.

• List AI systems as assets in scope: Name each clinical AI system, its data flows, and the tools and data stores it can reach, within the ePHI analysis.
• Identify AI-specific risks per system: Cover PHI in prompts and outputs, unauthorized tool or data access, and unsafe outputs reaching clinical workflows.
• Map each risk to a documented measure: Record whether the measure is a runtime control or a procedure, and who owns it.
• Trigger updates on change: Update the analysis when an AI system is added or changed, and review it at least annually, as ONC guidance advises.
• Define evidence and review: State what records are retained, who reviews them, and how often, so activity review and incident documentation have a clear owner.
• Extend to business associates: Business associates carry the same risk analysis and audit controls obligations, so assess AI suppliers on that basis.

Which treatments need runtime enforcement, and what evidence follows

Not every risk treatment needs to run in the execution path. Training, procurement terms, and clinical review procedures remain procedural. Treatments that depend on what an AI does in a specific interaction are different. Examples include keeping PHI out of a prompt, preventing an agent from calling a tool outside its task, and holding a high-impact action for a clinician's decision. A policy document cannot enforce these. The regulatory text does not require runtime controls, but the risk management standard asks for measures that reduce risk to a reasonable and appropriate level, and enforcement at the point of action is one defensible way to meet it. The four outcomes are allow, redact, block, and escalate for human approval.

Enforcement also produces the evidence. The audit controls standard, cited as 164.312(b), calls for hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. It is technology-neutral. Whether AI interactions and tool calls fall within it is an interpretive question, and the conservative reading is that a system handling ePHI should have records at the level where the AI acts: the prompt, the output, the tool call, and the decision taken. Separately, 164.308 requires regular review of records such as audit logs and access reports, and requires that security incidents and their outcomes be documented. A blocked or escalated event should therefore link to the incident process, not sit in a log nobody reads.

HHS also notes that OCR must consider, in certain enforcement and audit activities, whether recognized security practices were in place for the prior 12 months. Continuous records of enforced decisions make that period easier to demonstrate than point-in-time assessments.

Where a runtime control layer fits

Trussed enforces policy in the execution path for individual interactions and tool calls across models, agents, tools, and MCP servers, with actions to allow, redact, block, rate limit, or escalate for human approval. Enforcement generates audit-ready evidence mapped to HIPAA, among other regimes, and Trussed runs in production with healthcare and pharma organizations. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

It is not a risk assessment or GRC tool, and it does not perform the risk analysis or establish conformance with ISO/IEC 23894. The analysis remains the organization's work. A runtime layer is where the treatments that analysis selects are enforced and evidenced.