Testing HIPAA Controls on LLM Applications Before Go-Live

Why documents are not test evidence

Many pre-launch reviews of LLM applications rest on policy statements and architecture diagrams. Those show intent. They do not show that PHI redaction, access restrictions, tool-call limits and human escalation operate on live interactions and tool calls.

The Security Rule frames safeguards as things an entity implements. Under 164.308, the security management process requires policies and procedures to prevent, detect, contain and correct security violations. The HHS proposed rule published in January 2025 describes testing of technical controls as verifying that security measures work as designed. Its example methods include simulating security events and reviewing system logs and access records. It is a proposal, and as of November 2026 it should not be treated as a binding requirement. It is still a useful model for a test plan: each control needs an expected behavior, an observed result and a log record that connects them.

The practical consequence is that the test plan is built from behaviors. A statement such as 'PHI is not sent to external tools' becomes a set of scripted interactions with a defined expected outcome.

Mapping safeguards to testable behaviors

Start with the safeguards that translate most directly. Access control (164.312(a)) becomes tests of who can retrieve what and which tools a given identity may invoke. Audit controls (164.312(b)) are designated Required and call for mechanisms that record and examine activity in systems that contain or use ePHI. For an LLM application, that means prompts, retrieval, tool calls and outputs, and it means the records can be pulled and read, not merely written.

Transmission security (164.312(e)(1)) includes an integrity control for electronically transmitted ePHI, which is addressable. A test plan should record how integrity of data moving between application components was assessed, or why a measure was judged not reasonable and appropriate. NIST SP 800-66r2 has sections for access control and transmission security and works as a crosswalk between safeguards and the controls you select.

Keep the mapping as a table the test team owns: safeguard, control behavior, test case IDs, evidence produced. Gaps in that table are gaps in the plan.

Evidence artifacts and where runtime enforcement fits

A pre-go-live cycle should leave an auditor able to see what each control was configured to allow and what it actually did. Retain the test plan and safeguard mapping, the policy configuration as it stood during testing, the scripted inputs, the expected results, the raw audit records for each run, the reviewer's log-review notes, the decisions on addressable specifications, and sign-off from the control owner. Tie each artifact to a version of the model, prompts, tools and data sources under test. Set the retention period with your compliance owners under your HIPAA documentation requirements.

This is easier when controls are enforced in the execution path, because the enforcement point itself produces the record. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions that include allow, redact, block, rate limit and escalate for human approval, applied to individual interactions and tool calls. That enforcement generates audit-ready evidence mapped to HIPAA, including 164.312(b). The same mechanism you exercise in test is then the one that keeps producing evidence in production. Trussed runs in production with healthcare organizations and can be deployed self-managed in the customer cloud, with configurable retention. It is not a pre-deployment testing or red-teaming product, so the test design remains your team's work.

Retesting and governance after go-live

A passing result describes one configuration. Define what triggers a retest: changes to the model, prompts, tools or data sources, and changes to the environment. The January 2025 proposal uses a similar trigger, along with a review at least every 12 months, and HealthIT.gov says organizations must continue to review, correct or modify, and update protections. Adopting that cadence now is sound practice whether or not the proposal is finalized.

Governance should cover people as well as systems. The proposal treats testing as verifying that controls work as designed and that workforce members know how to implement them. For an LLM application, that includes whoever handles escalations. Assign an owner for the evidence, keep a record of which addressable specifications were implemented and how, and rerun the log-review test periodically against production records, not only against test runs. If a reviewer cannot retrieve and examine live records, the audit control is not working, regardless of how it performed before launch.