Contingency Plan

A “contingency plan” under the HIPAA Security Rule is not a generic business continuity deck. It is a set of policies and procedures you can execute when an emergency or other occurrence damages systems that contain electronic protected health information (ePHI) (45 CFR Parts 160, 162, 164). Examiners and auditors tend to look for two things: (1) whether the plan is specific to your ePHI environment (applications, infrastructure, dependencies, third parties), and (2) whether it works in practice, meaning the plan drives actions during real outages and gets updated after you learn from failures.

This page translates the requirement into operator-level steps: how to scope “systems that contain ePHI,” how to define emergency triggers, how to assign decision authority, how to build recovery runbooks that teams actually follow, and what evidence to retain so you can prove implementation. If you oversee HIPAA security compliance as a Compliance Officer, CCO, or GRC lead, your job is to make the contingency plan a living operating capability rather than a binder artifact that only appears during an audit.

Regulatory text

Requirement (operator read): You must 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 ePHI (45 CFR Parts 160, 162, 164).

What the operator must do:

1. Establish: Produce written, approved policies and procedures that describe how your organization responds when ePHI systems are damaged.
2. Implement as needed: Make the procedures actionable and used during actual events, not just written. “As needed” is a trigger concept: when an event meets your defined criteria, you execute the plan.
3. Scope matters: The plan must cover “systems that contain ePHI,” which includes applications, databases, endpoints, file stores, backups, cloud services, and supporting infrastructure where ePHI resides or is processed (45 CFR Parts 160, 162, 164).

Plain-English interpretation (what this requirement is really asking)

If a disruptive event damages technology that stores or processes ePHI, you need a pre-planned, documented way to respond that protects patients and operations. That means you can answer, quickly and consistently:

• Who declares an emergency and who leads the response?
• What systems get restored first, and why?
• How do you operate safely while systems are degraded?
• How do you coordinate with IT, clinical operations, privacy, legal, and third parties?

Who it applies to

Entity types: Covered Entities and Business Associates (45 CFR Parts 160, 162, 164).

Operational contexts where this becomes urgent:

• EHR/EMR downtime scenarios (planned or unplanned).
• Ransomware or destructive malware that corrupts systems containing ePHI.
• Cloud service outages affecting ePHI workloads.
• Physical incidents (fire, flood, theft) impacting servers, laptops, or network equipment containing ePHI.
• Third party incidents where a hosted system containing your ePHI is damaged or unavailable.

What you actually need to do (step-by-step)

1) Define contingency-plan scope based on ePHI system inventory

• Identify “systems that contain ePHI” in a way operations can act on: system name, owner, platform, hosting location, critical dependencies, and the business process supported.
• Include third parties that store/process ePHI on your behalf. Your plan should specify how you contact them, how you get status, and what your fallback process is when they are down.

Deliverable: ePHI system inventory excerpt (or mapped list) that clearly marks in-scope systems for contingency response.

2) Set emergency triggers and severity levels

Write down what qualifies as “emergency or other occurrence” for your organization (45 CFR Parts 160, 162, 164). Use plain triggers tied to observable conditions, for example:

• Loss of availability of a named ePHI system.
• Integrity compromise suspected (data corruption, unauthorized encryption).
• Physical damage to infrastructure hosting ePHI workloads.

Operator tip: Avoid vague triggers (“major outage”). Define who decides, what information they need, and how the declaration is recorded.

Deliverable: incident severity matrix or contingency activation criteria.

3) Assign roles, authority, and decision paths

Contingency plans fail because nobody is authorized to make tradeoffs quickly. Document:

• Incident Commander / Response Lead (primary and backup).
• IT recovery lead(s) per platform (network, identity, cloud, endpoints, backups).
• Privacy/Security point of contact for ePHI handling decisions.
• Business owners for clinical/operational downtime procedures.
• Communications owner (internal updates; third party coordination).

Deliverable: RACI chart plus call tree/on-call list.

4) Document recovery priorities and minimum operating requirements

Define what “recovery” means for each critical ePHI system:

• Which workflows must resume first (patient care, claims processing, scheduling, imaging, lab orders).
• Minimum safe operating mode (paper workflows, read-only access, offline capture with later reconciliation).
• Dependencies that can block recovery (identity provider, DNS, network segmentation, cloud tenancy).

Deliverable: prioritized system recovery list with business justification and dependencies.

5) Build executable runbooks (not just policy)

Create step-by-step procedures that responders can follow under pressure:

• Outage containment steps (isolation, shutdown criteria, access restrictions).
• Restoration steps (from backups, snapshots, rebuild, failover).
• Data integrity validation checks before bringing systems back.
• Manual workaround steps and how to handle ePHI during downtime.
• Third party escalation steps and required information to provide.

Operator tip: Write procedures with exact system names and tool references. “Restore from backup” is not a procedure.

Deliverable: runbooks per critical system and scenario (system failure, natural disaster, vandalism/physical damage, destructive cyber event) aligned to “damages systems that contain ePHI” (45 CFR Parts 160, 162, 164).

6) Make “implement as needed” real: exercises + post-incident updates

You need a mechanism to prove the plan is actually used when events happen:

• Tabletop exercises for scenario rehearsal (focus on decision-making and communication).
• Technical recovery tests for at least the highest-impact systems (prove steps work).
• After-action reviews when you have a real outage; track corrective actions to closure.

Deliverable: exercise records, test results, and after-action reports tied to plan updates.

7) Integrate third parties into contingency execution

If a third party hosts a system containing your ePHI, your contingency plan should include:

• How to obtain incident status and ETA.
• What evidence you require post-event (service tickets, RCA summaries, restore confirmation).
• Your internal fallback workflows while the third party is degraded.

Practical tool note: Daydream is useful here to centralize third party contacts, outage obligations, and evidence collection so contingency execution does not depend on someone’s personal inbox.

Required evidence and artifacts to retain

Keep evidence in a form you can produce quickly during an audit:

• Approved contingency plan policy and procedures addressing emergencies damaging ePHI systems (45 CFR Parts 160, 162, 164).
• ePHI system inventory mapping to contingency scope.
• Activation criteria and severity definitions.
• Role assignments, on-call schedules, and contact lists (including third parties).
• Recovery runbooks per critical system and platform.
• Downtime procedures for impacted business operations (how ePHI is handled during manual workflows).
• Exercise/test documentation, lessons learned, and remediation tracking.
• Incident records showing when the plan was activated and what actions were taken.

Common exam/audit questions and hangups

Where audits get stuck:

• “Show me the systems that contain ePHI and where the contingency plan addresses each one.”
• “How do you decide to activate the contingency plan, and who has authority?”
• “Prove you tested recovery steps for a critical ePHI system.”
• “During downtime, how do you prevent improper access or loss of ePHI?”
• “How do your third parties fit into your contingency response?”

What auditors dislike: A single high-level policy with no system-specific procedures, no named owners, and no evidence of execution “as needed” (45 CFR Parts 160, 162, 164).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating the contingency plan as generic BCP language.
   Fix: Anchor every section to specific ePHI systems and real recovery steps.

2. Mistake: No dependency mapping.
   Fix: Document “you can’t restore X until Y is up” (identity, network, key management, cloud control plane).

3. Mistake: Third parties left out.
   Fix: Add third party escalation paths, downtime workflows, and post-incident evidence requirements.

4. Mistake: Plans that can’t be executed under stress.
   Fix: Build runbooks written for the on-call engineer and the operations lead, not for a policy reader.

5. Mistake: No feedback loop after incidents.
   Fix: Require after-action reviews and track corrective actions to closure.

Enforcement context and risk implications

The regulatory expectation is straightforward: you must be prepared to respond to events that damage systems containing ePHI (45 CFR Parts 160, 162, 164). Operational risk is broader than compliance risk: inability to restore critical ePHI systems can disrupt patient care, delay claims, impair revenue operations, and increase the likelihood of improper handling of ePHI during manual downtime workflows.

Practical 30/60/90-day execution plan

First 30 days (stabilize the minimum viable contingency plan)

• Confirm the in-scope list of systems that contain ePHI and identify system owners.
• Draft or refresh the contingency plan policy and activation criteria tied to damaging events (45 CFR Parts 160, 162, 164).
• Assign roles, authority, and escalation paths, including third parties.
• Create a short “first hour checklist” for responders: declare, communicate, isolate, preserve evidence, start restore path.

By 60 days (make it executable for the critical path)

• Build runbooks for the highest-impact ePHI systems first.
• Define downtime workflows for the business units dependent on those systems.
• Conduct a tabletop exercise focused on a realistic system-damage scenario; record gaps and assign remediation owners.
• Add third party response steps and evidence requests into your procedures.

By 90 days (prove operational readiness and institutionalize updates)

• Run a technical recovery test for at least one critical ePHI system; record results and improvements.
• Establish a cadence for keeping contact lists, system inventories, and runbooks current.
• Implement a post-incident review process that forces plan updates after outages.
• Centralize artifacts (plans, runbooks, test evidence, third party contacts) in a controlled repository; Daydream can help coordinate owners, collect evidence, and keep third party dependencies mapped to ePHI systems.

Frequently Asked Questions

Does “contingency plan” mean I need to cover cyberattacks like ransomware?

The text covers any emergency or occurrence that damages systems containing ePHI, and it provides examples like system failure and vandalism (45 CFR Parts 160, 162, 164). If a cyber event damages or disrupts ePHI systems, your procedures should address response and recovery.

How detailed do the procedures need to be?

Detailed enough that the responsible team can execute them during an outage without inventing steps. A good test is whether a new on-call engineer could follow the runbook to restore service safely.

If we outsource our EHR to a third party, can we rely on their disaster recovery plan?

You can incorporate third party capabilities, but you still need your own policies and procedures for responding when systems containing your ePHI are damaged (45 CFR Parts 160, 162, 164). Your plan should define internal downtime workflows, escalation, and evidence you will obtain from the third party.

What evidence should I show an auditor to prove “implement as needed”?

Provide incident records where the plan was activated, plus exercise/test documentation and follow-up remediation tracking. Auditors look for proof the plan drives action, not just that it exists.

How do we handle ePHI during manual downtime workflows?

Define who can create, access, transport, and reconcile downtime records, and where they are stored until systems are restored. Your contingency plan should connect downtime procedures to the specific system outage scenarios that trigger them.

Our inventory is messy. Can we start without a perfect system list?

Yes, start with the highest-impact ePHI systems and build outward, but document your scoping approach and owners. The plan is hard to execute without a clear view of which systems contain ePHI (45 CFR Parts 160, 162, 164).