Contingency planning: the backup nobody has tested

Contingency planning is the standard that costs nothing to skip until the one day it costs everything. Ransomware, a failed drive, a flooded office, a vendor outage that lasts three days: none of these are hypothetical anymore, and the rule stopped treating them as hypothetical in 2003.

What the rule actually requires

The contingency plan standard is Required: establish and implement as needed policies and procedures for responding to an emergency or other occurrence, for example fire, vandalism, system failure, or natural disaster, that damages systems containing ePHI (45 CFR 164.308(a)(7)(i)).

It carries five implementation specifications, and the split matters:

Required, all three:

• Data backup plan (164.308(a)(7)(ii)(A)). Establish and implement procedures to create and maintain retrievable exact copies of ePHI.
• Disaster recovery plan (164.308(a)(7)(ii)(B)). Establish and implement as needed procedures to restore any loss of data.
• Emergency mode operation plan (164.308(a)(7)(ii)(C)). Establish and implement as needed procedures to enable continuation of critical business processes for protecting ePHI while operating in emergency mode.

Addressable, both:

• Testing and revision procedures (164.308(a)(7)(ii)(D)). Procedures for periodic testing and revision of contingency plans.
• Applications and data criticality analysis (164.308(a)(7)(ii)(E)). Assess the relative criticality of specific applications and data in support of the other contingency plan components.

Three Required specifications in one standard is unusual. Most standards in the Security Rule lean addressable. This one does not, and a clinic that has never written a disaster recovery plan is missing something the rule does not leave to judgment.

Backup is a noun, recovery is a verb

The most common failure here is treating the first specification as if it satisfies the second. A backup is the copy. A disaster recovery plan is the documented procedure for using that copy to get back to operating. They are separate specifications because they are separate things, and having one does not produce the other.

The word in the backup specification worth reading closely is retrievable. Exact copies that cannot actually be retrieved are not a backup plan, they are a backup job that runs. The difference is only visible when someone tries a restore, which is what the testing specification exists to prompt.

“You can have a perfect backup and no disaster recovery plan. The backup is the copy. The plan is what you do with it.”

The specification with no answer

Emergency mode operation is the one most clinics have never considered. It asks what you do while degraded: your EHR is down, your scheduling is down, and you still have sessions today and still have to protect PHI while running on whatever you can improvise.

For an ABA clinic this is concrete. Do RBTs collect data on paper? Where does that paper go afterward, and who reconciles it into the record later? How do you reach families if your normal channel is unavailable? How do you keep a paper session note from becoming an uncontrolled disclosure sitting in someone’s car?

Answering those before the day arrives is the whole specification.

Addressable, and the honest assessment

Testing and criticality analysis are Addressable, which means you assess whether they are reasonable and appropriate for your clinic, then implement them or document a genuine alternative.

Run that assessment honestly for a clinic holding children’s clinical records. A backup nobody has tested is a backup nobody knows works. A recovery plan with no criticality analysis has no order of operations, so on the day it matters nobody knows whether to restore scheduling or clinical records first. The assessment that concludes these are not reasonable is difficult to write.

What a real answer looks like, next to what most clinics have

	What the rule requires	What most clinics actually have
Backup	Retrievable exact copies, confirmed retrievable	A backup job that runs, never restored from
Disaster recovery	A documented procedure for restoring loss	Assumed to be the vendor’s problem
Emergency mode	A plan for operating degraded while protecting ePHI	Nothing at all, this is the most commonly absent piece
Testing	Periodic testing with a date	Never tested
Criticality	A ranked order of what comes back first	No ranking, so no order on the day

The gap in the second row is worth naming. Many clinics assume their EHR vendor handles disaster recovery, and the vendor may well handle theirs. That does not produce your plan, and it does not tell you what your clinic does during the outage.