HIPAA Contingency Plan Requirements for AI Systems: Failover Without PHI Exposure

What the contingency plan standard requires

The contingency plan standard at 164.308(a)(7)(i) requires policies and procedures for responding to an emergency or other occurrence, such as fire, vandalism, system failure, or natural disaster, that damages systems containing ePHI. Three implementation specifications are required: a data backup plan (retrievable exact copies of ePHI), a disaster recovery plan (procedures to restore any loss of data), and an emergency mode operation plan (procedures that let critical business processes continue while protecting the security of ePHI in emergency mode). Two are addressable: testing and revision procedures, and an applications and data criticality analysis. Addressable does not mean optional.

The emergency mode language matters most for AI. It ties continued operation to the protection of ePHI. A failover path that keeps an AI workflow running but drops the redaction, access, or audit controls of the primary path is hard to reconcile with that text. The reading is an interpretation, but it is the one a security reviewer is likely to apply.

As of November 2026, the current text above remains the operative standard. A proposed rule published in January 2025 would require a written contingency plan covering security incidents and procedures to restore critical systems and data within 72 hours. Treat it as a planning input and monitor its status.

Mapping the five specifications to AI components

Traditional contingency plans were written around servers, databases, and applications. AI adds components that handle ePHI in new ways: model endpoints, agents, tool and MCP server connections, and the routing logic that chooses between them. The mapping below is a working interpretation to document in the plan.

• Data backup plan: Prompts, retrieved context, conversation state, and any stored outputs containing ePHI, plus the policy and routing configuration needed to rebuild the system.
• Disaster recovery plan: Procedures to restore model endpoints, agent runtimes, tool connections, and policy configuration, with restore order based on criticality.
• Emergency mode operation plan: Defined behavior when the primary model or provider is unavailable: approved secondary routes, restricted capabilities, human escalation, or shutdown.
• Testing and revision: Periodic failover exercises that include secondary routes and tool dependencies, with results and plan changes recorded.
• Applications and data criticality analysis: Ranking AI workflows to decide which need failover, which run degraded, and which are disabled during an outage.

Where AI introduces new contingency failure modes

The core risk is that policy is attached to the primary route and not to the traffic. When a primary model becomes unavailable, a router may send the same request to a secondary model, region, or vendor. If that target lacks an equivalent business associate agreement, redaction behavior, data residency setting, retention terms, or audit evidence, PHI reaches a path the plan never assessed.

Tools and MCP servers create a parallel exposure. An agent that fails over to a different model may call different tools, or the same tools with different arguments. Each tool call can read or write ePHI, so each one is an access decision. Because 164.312(a)(1) limits access to persons or software programs granted access rights, it is reasonable to treat agents, model endpoints, and tools as access-controlled actors on every route, including failover routes.

Degraded behavior is the third gap. A fallback model with weaker instruction following may handle PHI differently from the primary, and an outage is when teams are least likely to notice.

Evidence for failover events under 164.312(b)

Section 164.312(b) requires hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. The rule is technology-neutral and does not prescribe log fields, so the content of failover evidence is a design decision. Make it answer the question a reviewer will ask: what did the system do with PHI while it was degraded?

Useful records include the trigger and time of the failover, the route before and after, the policy version applied, each allow, redact, block, or escalate decision, tool calls made, and the human approvals recorded. Also record when the system returned to the primary route. Assign an owner to approve failover targets and an owner to review this evidence, since the rule requires activity to be examined as well as recorded.

For operations, SAFER guidance recommends an in-depth review of unexpected downtime over 24 hours, and a regularly reviewed list of system-to-system interfaces, for example every six months or annually. Both extend naturally to AI: inventory model, provider, and tool dependencies, and review failover events as incidents. Include AI services and failover paths in the annual security risk analysis.

Enforcing policy in the execution path

Documentation alone does not keep PHI rules in force during an outage. Enforcement has to sit where requests and tool calls pass, so that a rerouted request meets the same checks as the original. Trussed enforces policy in the execution path across models, agents, tools, and MCP servers, with decisions to allow, redact, block, rate limit, or escalate for human approval at the level of individual interactions and tool calls. Policy is enforced at runtime, not reviewed after the fact, and the enforcement generates audit-ready evidence mapped to HIPAA, including 164.312(b).

Trussed deploys self-managed in the customer cloud, with configurable retention and data residency, and runs in production with healthcare organizations. It has operated continuously in a regulated enterprise for more than 18 months, with 99.95% uptime on live production traffic and more than 100 models under one policy plane. Whatever tooling you choose, the test is the same: the policy and the evidence must not depend on which route the request took.