HIPAA Contingency Planning

Why HIPAA contingency planning matters

HIPAA §164.308(a)(7) — the Contingency Plan standard — requires covered entities and business associates to "establish (and implement as needed) policies and procedures for responding to an emergency or other occurrence (for example, fire, vandalism, system failure, and natural disaster) that damages systems that contain electronic protected health information." Availability is one of the three security objectives of the Security Rule, alongside confidentiality and integrity, and contingency planning is the primary control for meeting it.

Cloud outages, ransomware, data center fires, hurricanes, and insider errors are all forecasted risks. A tested contingency plan is what turns each of these from a crisis into an incident — and a missing plan is one of the fastest ways to escalate an operational disruption into a HIPAA breach. The 2016 OCR ransomware guidance made this explicit: if a ransomware attack renders ePHI unavailable, that unavailability itself can constitute a breach absent a demonstration that the data was not compromised.

For the broader administrative safeguards context, see the HIPAA Security Rule guide and the HIPAA hub page. Contingency planning is tightly coupled with the HIPAA risk analysis that prioritizes which systems get the most investment.

The five implementation specifications

§164.308(a)(7)(ii) lists five implementation specifications. Three are required and two are addressable.

Data backup plan — required — §164.308(a)(7)(ii)(A)

The data backup plan establishes procedures to create and maintain retrievable exact copies of ePHI. At minimum it should define which systems are in scope, the frequency of backups, the retention period, the storage location, and the controls that protect backup data (encryption, access controls, immutability against ransomware).

A defensible backup plan answers three practical questions.

• Can we restore a single record, an entire table, and an entire system? Test each level.
• Are backups isolated from the systems they protect? Ransomware routinely deletes online backups.
• Does the backup itself meet the Security Rule? Encrypted backups stored with the same vendor as production often fail this test.

Disaster recovery plan — required — §164.308(a)(7)(ii)(B)

The disaster recovery plan establishes procedures to restore any loss of data. It is the operational companion to the backup plan: backups give you something to restore from, while the DR plan tells you who does what, in what order, on what timeline. Recovery Time Objective (RTO) and Recovery Point Objective (RPO) targets anchor the plan, and both should be derived from the criticality analysis described below.

Emergency mode operation plan — required — §164.308(a)(7)(ii)(C)

The emergency mode operation plan defines how critical business processes continue during an emergency that impairs the organization's normal operations — while continuing to protect ePHI. It answers: who has authority to declare emergency mode, which systems and staff are essential, what fallback procedures apply (paper records, manual processes, alternate facilities), and how the organization returns to normal operation.

This is the specification most programs underinvest in. Backup and DR are familiar engineering problems; emergency mode operation is an organizational problem that requires coordination across clinical, operational, security, and legal teams.

Testing and revision procedures — addressable — §164.308(a)(7)(ii)(D)

Testing validates that the other three specifications actually work. Tabletop exercises, restore drills, and full failover tests each surface different failure modes. The implementation specification is addressable, but in practice untested plans fail when they are needed most — and OCR audit protocol treats testing as the primary evidence that contingency planning is operational rather than paper.

Applications and data criticality analysis — addressable — §164.308(a)(7)(ii)(E)

Criticality analysis ranks applications and data by how important they are to the organization's operations. This is what tells you which systems need a 15-minute RTO and which can tolerate 72 hours. Without it, every system is treated as equally critical (which is unaffordable) or equally non-critical (which is catastrophic when the wrong system fails).

Building the plan

A workable HIPAA contingency plan has six components, regardless of organization size.

1. Scope statement. Which systems, data, facilities, and vendors are covered. Reference the same asset inventory that feeds your risk analysis.
2. Criticality analysis. RTO and RPO for each in-scope system, with written justification. Customer contractual commitments are part of this analysis.
3. Backup procedures. Frequency, retention, encryption, storage, restore testing cadence, and responsible owners.
4. Disaster recovery runbooks. Step-by-step procedures for failing over each critical system, including dependencies, communication templates, and roll-back criteria.
5. Emergency mode operations. Authority, triggers, fallback processes, coordination with clinical or operational leadership, and return-to-normal criteria.
6. Testing and revision calendar. A 12-month schedule that rotates through tabletop exercises, restore tests, and full failover drills.

Each component should have a named owner, a review cadence, and a last-reviewed date. Contingency plans decay fastest among Security Rule artifacts — systems change constantly, and a plan that described last quarter's architecture is no plan at all.

Testing: the only evidence that counts

There is no substitute for live testing. A reasonable 12-month rotation looks like this.

• Q1 — Tabletop exercise. Walk through a scenario (ransomware detonation, regional cloud outage, data center fire) with the full incident response team. Capture decisions, gaps, and open questions.
• Q2 — Restore drill. Restore a production system from backup into an isolated environment. Validate data integrity, time-to-restore, and the runbook accuracy.
• Q3 — Partial failover. Fail over one critical system to its DR target. Measure RTO, RPO, and any customer-facing impact.
• Q4 — Emergency mode exercise. Simulate an extended disruption that forces fallback processes. Exercise the human workflows that the technical runbooks assume will work.

Document every test: scenario, participants, timeline, findings, and corrective actions. Those findings feed the next iteration of both the contingency plan and the risk analysis.

How this fits into your HIPAA program

Contingency planning does not sit alone. It connects to the HIPAA risk analysis that sizes the risks to availability. It connects to facility access controls through the contingency operations implementation specification at §164.310(a)(2)(i), which requires procedures allowing facility access during recovery. It connects to workforce training because the plan only works if the people executing it have rehearsed their roles. It connects to BAAs, because most covered entities depend on business associates for critical systems, and the contingency plan must account for vendor failures as well as internal ones.

It also connects to breach notification. When ransomware or extended downtime exposes ePHI, the contingency response and the breach response run in parallel and share evidence. Design them to share templates, logs, and decision gates.

Common pitfalls

• Backup and DR without emergency mode. Engineers build strong recovery tooling, but there is no written answer for how clinical or operational staff continue their work during the hours before recovery completes.
• Untested plans. The plan is thorough on paper and has never been exercised. The first real incident exposes assumptions that do not match reality.
• Backups in the same failure domain as production. Backups stored on the same platform, region, or account as production systems are one ransomware event away from being useless.
• Criticality analysis is missing or generic. Every system is "critical," so investment scatters and the systems that actually matter are under-protected.
• Vendor gaps. The plan assumes a business associate will restore its own systems within an RTO that the BAA never committed to. Renegotiate or document the risk.
• No return-to-normal. Plans cover failover but not failback. Weeks later, the organization is still operating in the emergency mode environment with degraded controls.
• Stale documentation. The plan references systems, vendors, or personnel that no longer exist. During an incident, this wastes the hours that matter most.

How episki helps

episki brings contingency planning into the same workspace as the rest of your HIPAA program. Asset inventories feed the criticality analysis; backup, DR, and emergency mode runbooks live alongside the policies they implement; testing calendars and post-test findings stay linked to the systems they affect; and evidence rolls up automatically for OCR audits and customer reviews. When a real incident lands, the runbook, the contact list, and the decision log are in one place — not in a shared drive nobody has opened in nine months.

See the full HIPAA platform overview or start a free trial from the top of the hub page.