The HIPAA Security Rule requires every covered entity and business associate to have a contingency plan, and three of its five parts are Required implementation specifications with no alternative path: a data backup plan, a disaster recovery plan, and an emergency mode operation plan. Most organizations have some version of the first. The second and third are where the gaps usually sit, largely because the rule asks three separate questions that sound like one.
What the standard says
The provision is 45 CFR 164.308(a)(7)(i), and the parenthetical examples are the regulation's own:
Two details in that sentence are worth slowing down for.
“System failure” sits in the same list as fire and natural disaster. The standard is not reserved for catastrophes. A failed server, a corrupted database, or a botched update is the same category of event as a flood as far as the rule is concerned, and it is the far more likely one.
“Establish (and implement as needed)” is a phrase the drafters reused deliberately. Establishing the procedure is not conditional. Implementing it is what waits for the emergency. You do not get to skip writing the plan on the grounds that nothing has gone wrong yet.
The five specifications, and which are Required
| Specification | Status | What it requires |
|---|---|---|
| 164.308(a)(7)(ii)(A) Data backup plan | Required | Establish and implement procedures to create and maintain retrievable exact copies of ePHI |
| 164.308(a)(7)(ii)(B) Disaster recovery plan | Required | Establish (and implement as needed) procedures to restore any loss of data |
| 164.308(a)(7)(ii)(C) Emergency mode operation plan | Required | Establish (and implement as needed) procedures to enable continuation of critical business processes for protection of the security of ePHI while operating in emergency mode |
| 164.308(a)(7)(ii)(D) Testing and revision procedures | Addressable | Implement procedures for periodic testing and revision of contingency plans |
| 164.308(a)(7)(ii)(E) Applications and data criticality analysis | Addressable | Assess the relative criticality of specific applications and data in support of other contingency plan components |
Three Required, two Addressable. The Addressable label is the most misread word in the Security Rule, so it is worth restating what it means: under 45 CFR 164.306(d), you implement the specification if it is reasonable and appropriate, or you determine it is not, document why, and implement an equivalent alternative measure where one is reasonable and appropriate. Addressable is a documented decision. It is not permission to ignore.
Three plans that answer three different questions
The most useful thing to understand about 164.308(a)(7) is that its three Required specifications are not three names for one document. Each answers a distinct question, and an organization can genuinely satisfy one while being silent on the others.
- Data backup plan. Do retrievable exact copies of the ePHI exist? Note the word retrievable. A copy you cannot get back is not a backup, and the specification says so on its face.
- Disaster recovery plan. How do you restore the data after it is lost? Having the copy and being able to put it back are different capabilities. This is the one most often assumed rather than written.
- Emergency mode operation plan. How do you keep protecting ePHI while the systems are down? This is not about restoration at all. It is about the outage itself.
That third one is the specification most often missing entirely, and the reason is that it asks about a period nobody wants to plan for. During an outage, the normal controls are the very things unavailable. Charting moves to paper. Someone needs the record from a system that will not load. The workaround that gets invented under pressure at 2 a.m. is usually the one that bypasses access control, and the emergency mode operation plan is where you decide, in advance and calmly, what protecting ePHI looks like when your usual mechanisms are gone.
The Required backup and the Addressable test
Here is the structural oddity worth noticing: creating backups is Required, and testing that they work is Addressable.
That is what the regulation says, and it is not an invitation to skip the test. An untested backup is a hypothesis. The failure modes are ordinary and well known: the job silently stopped months ago, the backup covers the database but not the configuration needed to read it, the restore takes four days when the practice can absorb four hours, or the encryption key for the archive lived on the server that burned.
Because testing is Addressable, an organization that decides not to test has to document that determination and implement an equivalent alternative measure where one is reasonable and appropriate. In practice, articulating a written rationale for why verifying your own backups is not reasonable and appropriate is harder than performing a restore test. The Addressable label here is less a discount than an invitation to think, and most organizations who think about it will test.
A restore test worth the name restores to somewhere other than production, from the backup you would use in a real event, performed by someone other than the person who set it up, with the elapsed time recorded. That last field is what converts the test into a planning input for the emergency mode operation plan.
The physical safeguard nobody connects to this
Contingency planning also appears in the physical safeguards, and it is easy to miss because it sits in a different section of the rule.
This is the specification that asks whether anyone can physically get in. If the recovery plan requires access to a server room, and the person who holds the key is unreachable, and the badge system is unavailable because the power is out, the plan has a dependency it never wrote down. The provision exists because restoration is a physical act before it is a technical one, and access control designed to keep people out works exactly as designed during an emergency.
Applications and data criticality analysis
164.308(a)(7)(ii)(E) asks you to assess the relative criticality of specific applications and data in support of other contingency plan components. It is Addressable, and that closing phrase explains why it is worth doing anyway: it is the input the other four specifications need.
Without it, a recovery plan implicitly treats everything as equally urgent, which in a real event means the order is decided by whoever is loudest. The analysis is the difference between a plan that says “restore the systems” and one that says which system comes back first, what the practice can operate without for a day, and what it cannot operate without for an hour.
Where contingency planning meets ransomware
Contingency planning is often filed under availability, and ransomware is what collapsed the distinction between availability and confidentiality for most organizations.
Two connections are worth drawing. First, a ransomware event is squarely inside the standard's own language: it is an occurrence that damages systems containing ePHI. It does not need a special plan, it needs this one. Second, a backup that is reachable from the compromised environment with the same credentials is a backup that encrypts along with everything else. The data backup plan's word retrievable is where that problem lives.
Separately, an impermissible acquisition or disclosure of PHI is presumed to be a breach under 45 CFR 164.402 unless the entity demonstrates a low probability that the PHI has been compromised, based on a risk assessment of at least four specified factors. A contingency plan does not answer that question, but the evidence a well-run recovery produces, including logs and a clear picture of what was touched, is what the analysis draws on.
How often to revisit it
There is no federal calendar for this, and anyone who quotes you one has invented it. What the rule supplies instead is a trigger.
164.308(a)(8) requires a periodic technical and nontechnical evaluation, performed initially against the standards and subsequently in response to environmental or operational changes affecting the security of ePHI. 164.316(b)(2)(iii) requires documentation to be reviewed periodically and updated as needed in response to the same kinds of changes.
So the events that should move a contingency plan are changes: a new EHR, a second location, a migration to a hosted system, a vendor swap, turnover in the person who knew how the restore worked, or an actual incident. Reviewing annually as a backstop is sensible practice. It is not a legal deadline, and treating it as one tends to mean the plan goes stale for eleven months at a time.
What this looks like in a small practice
The standard applies at every size, and 45 CFR 164.306(b) is explicit that a covered entity or business associate may use any security measures that reasonably and appropriately implement the standards, taking into account its size, complexity, and capabilities, its technical infrastructure, the costs of security measures, and the probability and criticality of potential risks to ePHI.
So the scope scales. The existence of the three Required plans does not. For a small practice, a defensible version of this is a few pages: what is backed up and how often, where the copies live, who restores them and how, what the practice does clinically while the system is down, how ePHI stays protected during that window, and when the plan was last tested and by whom. Short and true beats long and aspirational, and it is the version someone can follow at 2 a.m.
Common questions
Does HIPAA require a disaster recovery plan?
Yes. 45 CFR 164.308(a)(7)(ii)(B) makes a disaster recovery plan a Required implementation specification: establish (and implement as needed) procedures to restore any loss of data. It sits under the Contingency plan standard alongside two other Required specifications, a data backup plan at 164.308(a)(7)(ii)(A) and an emergency mode operation plan at 164.308(a)(7)(ii)(C). Because all three are Required rather than Addressable, there is no documented-alternative path for any of them. The rule does not prescribe a format or a length, and a plan proportionate to a small practice can be short.
Is testing your HIPAA contingency plan required?
Testing is Addressable, not Required. 45 CFR 164.308(a)(7)(ii)(D) lists testing and revision procedures as an Addressable implementation specification, which means you implement it if it is reasonable and appropriate, or document why it is not and implement an equivalent alternative measure where one is reasonable and appropriate. Addressable does not mean optional. It means the decision has to be made deliberately and written down. Given that an untested backup is a hypothesis rather than a control, most organizations will find testing reasonable and appropriate, and will need a documented rationale if they conclude otherwise.
What is an emergency mode operation plan?
45 CFR 164.308(a)(7)(ii)(C) requires procedures to enable continuation of critical business processes for protection of the security of electronic protected health information while operating in emergency mode. It is a Required implementation specification. The distinction that matters is that it is not a plan for restoring systems, which is the disaster recovery plan's job. It covers how you keep protecting ePHI during the outage itself, while normal controls are unavailable. If your downtime procedure involves paper charts, shared logins, or a workaround that bypasses your usual access controls, the emergency mode operation plan is where you address how ePHI stays protected anyway.
How often does a contingency plan need to be updated?
The Security Rule does not set a calendar. Two provisions drive the timing instead. 45 CFR 164.308(a)(8) requires a periodic technical and nontechnical evaluation, performed initially against the standards and subsequently in response to environmental or operational changes affecting the security of ePHI. 45 CFR 164.316(b)(2)(iii) requires documentation to be reviewed periodically and updated as needed in response to environmental or operational changes. So the trigger is change, not a date: a new system, a move, a new location, a vendor swap, or an incident. Many organizations also review annually as a backstop, which is a reasonable practice rather than a federal deadline.