HIPAA Contingency Plan Template — 45 CFR § 164.308(a)(7)

A HIPAA contingency plan is the written plan that lets a covered entity protect and restore ePHI when normal operations are disrupted by fire, system failure, natural disaster, ransomware, or vendor outage. The federal mandate is 45 CFR § 164.308(a)(7) — five implementation specifications, three required and two addressable.

What HHS actually requires

The Security Rule at § 164.308(a)(7) lists five implementation specifications under the Contingency Plan standard:

| Specification | Status | Citation | |---|---|---| | Data backup plan | Required | § 164.308(a)(7)(ii)(A) | | Disaster recovery plan | Required | § 164.308(a)(7)(ii)(B) | | Emergency mode operation plan | Required | § 164.308(a)(7)(ii)(C) | | Testing and revision procedures | Addressable | § 164.308(a)(7)(ii)(D) | | Applications and data criticality analysis | Addressable | § 164.308(a)(7)(ii)(E) |

OCR audits open with the contingency plan because ransomware is the highest-volume breach category and Resolution Agreements (Anthem, Premera, 21st Century Oncology, Athens Orthopedic Clinic, Touchstone Medical Imaging) all cite contingency-plan defects. The reference framework is NIST SP 800-34 Revision 1. What practices most often miss is the emergency-mode operation plan — the operational steps that keep the clinic running when the EHR is unavailable, distinct from the disaster-recovery steps that restore the EHR.

The four entities every credible contingency plan references: the HHS Office for Civil Rights (OCR), NIST SP 800-34 Rev. 1, NIST SP 800-66 Rev. 2, and the HHS Ransomware Fact Sheet.

Template — section by section

``` HIPAA CONTINGENCY PLAN [Practice Name] Effective: [DATE] Owner: Security Officer

1. PURPOSE

This plan implements 45 CFR § 164.308(a)(7) and its five implementation specifications. It defines how the practice protects ePHI during and after emergencies, restores access, and continues critical clinical and billing operations.

1. SCOPE

This plan covers every system that creates, receives, maintains, or transmits ePHI on behalf of the practice, every workforce member, and every BAA-covered vendor whose systems support clinical or billing workflows.

1. ROLES

Plan Owner: Security Officer Plan Activator: Security Officer or Practice Owner (either may declare emergency mode) Communications Lead: Privacy Officer Clinical Lead: <named clinician> IT Restoration Lead: <named IT lead or vendor PM> Vendor Liaison: <named person> ```

Section 4 — Data backup plan (required)

``` 4.1 What is backed up

• Full EHR database (production)
• PM system database
• Imaging / PACS
• Document management (signed forms, scans)
• Practice email and secure messaging archives
• Workstation configuration baselines
• Domain controllers, identity provider exports
• Vendor SaaS exports (where vendor offers export)

4.2 Cadence and retention

• Full backup nightly at 2:00 AM local
• Hourly incremental during business hours
• 30-day retention on warm storage (immediate restore)
• 7-year retention on cold/immutable storage (regulatory)
• 12-month minimum on a second geographic location

4.3 Encryption (cross-ref encryption policy) AES-256 at rest, FIPS 140-2/140-3 validated module. TLS 1.2+ in transit. Backup encryption keys stored separately from the data.

4.4 Immutability / air-gap Production backups written to immutable retention storage that cannot be modified or deleted by a compromised credential. A second copy is held offline or in a tenant-isolated cloud account.

4.5 Vendor responsibilities Each BAA-covered vendor that hosts ePHI provides written backup attestation: cadence, retention, encryption, restoration SLA.

4.6 Verification Restore drill at least quarterly. Test file selected randomly. Restoration time recorded. Result filed (Appendix D). ```

Section 5 — Disaster recovery plan (required)

``` 5.1 Activation triggers

• Confirmed ransomware on any ePHI system
• Loss of facility (fire, flood, structural)
• Multi-system outage exceeding 4 hours
• Loss of primary identity provider exceeding 2 hours
• Loss of EHR vendor exceeding the published SLA

5.2 Restoration sequence (Recovery Time Objective per system) Hour 0: Activator declares DR; Communications Lead notifies workforce and patients Hour 0–2: Identity provider restored or alternate IDP cut over Hour 0–4: Network and connectivity restored Hour 4–8: EHR restored from most recent clean backup (RPO ≤ 1 hr) Hour 4–12: PM and billing systems restored Hour 12–24: Imaging, document management, secondary systems Hour 24–72: Email, secure messaging, ancillary systems

5.3 Recovery Point Objective (RPO) EHR: ≤ 1 hour data loss tolerated PM: ≤ 4 hours Imaging / PACS: ≤ 24 hours Email / secure messaging: ≤ 4 hours

5.4 Recovery Time Objective (RTO) EHR: 8 hours PM: 12 hours Imaging: 24 hours Email: 24 hours

5.5 Restoration runbook Step-by-step procedures filed in Appendix E for each tier-1 and tier-2 system. Each runbook names the vendor support line, the credential set, and the verification step that confirms restore success. ```

Section 6 — Emergency mode operation plan (required)

This is the section most plans miss. It is what the clinic does during the outage.

``` 6.1 Activation Activator declares emergency mode. Notification cascade: Security Officer → Practice Owner → all clinical and front-desk leads → workforce-wide message.

6.2 Clinical operations during outage

• Downtime encounter template (paper) printed and stocked at every

workstation. Template captures: patient name, DOB, chief complaint, vitals, assessment, plan, medications, allergies, provider signature.

• Last printable patient list (MRN, name, appointment time, reason,

allergies, active medications) generated nightly and stocked in the front-desk binder.

• Critical patient information binder updated daily: hospice

patients, anticoagulation patients, recent post-op patients, pending lab results.

• Medication administration record (MAR) backup printed daily.

6.3 Billing and front-desk operations

• Paper superbill and encounter form by CPT category.
• Manual appointment book maintained at every front desk.
• Authorization-required services deferred where clinically safe;

documented decisions filed.

6.4 Communications

• Patient-facing voicemail script and website banner published

within 1 hour of activation.

• Daily workforce briefing.
• Vendor support tickets opened within 30 minutes; daily status

update.

6.5 Documentation backfill Within 72 hours of restoration, every paper encounter is entered into the EHR with a downtime documentation flag.

6.6 Termination of emergency mode Activator declares restoration. Communications Lead notifies workforce and patients. Post-incident review scheduled within 10 business days. ```

Section 7 — Testing and revision procedures (addressable)

``` 7.1 Backup restore drill: quarterly

• Restore a random file from production backup
• Document restoration time
• Confirm file integrity
• File result in Appendix D

7.2 Tabletop disaster simulation: annually

• Scenario rotated each year (ransomware, fire, vendor outage,

regional internet outage)

• All key roles participate
• Run for 90–120 minutes
• Document gaps and assign remediation owners

7.3 Live failover test: annually (for systems that support it)

• Failover identity provider, EHR sandbox, or PM sandbox
• Document outcome and any unplanned dependencies

7.4 Revision Plan reviewed and revised at least annually and after every activation, every tabletop, and every material change to operations or technology. Version history retained six years under 45 CFR § 164.316(b)(2)(i). ```

Section 8 — Applications and data criticality analysis (addressable)

``` 8.1 Method Each ePHI-bearing system is ranked on:

• Clinical impact of outage (1-5)
• Financial impact of outage (1-5)
• Maximum tolerable downtime (hours)
• Upstream dependencies (identity, network, vendor)

Tier assignment: Tier 1 (MTD ≤ 4h), Tier 2 (≤ 24h), Tier 3 (≤ 72h), Tier 4 (> 72h).

8.2 Output Filed in Appendix C; reviewed annually. ```

Applications and Data Criticality Analysis (Appendix C)

| System | Clinical impact | Financial impact | MTD | Dependencies | Tier | RPO | RTO | |---|---|---|---|---|---|---|---| | EHR (prod) | 5 | 5 | 4h | IDP, network | 1 | 1h | 8h | | Identity provider | 5 | 5 | 2h | network | 1 | 1h | 2h | | PM / billing | 3 | 5 | 12h | EHR, network | 2 | 4h | 12h | | Imaging / PACS | 4 | 3 | 24h | network | 2 | 24h | 24h | | Secure messaging | 4 | 2 | 4h | IDP | 1 | 4h | 8h | | Email | 3 | 3 | 24h | IDP, network | 2 | 4h | 24h | | Cloud backup | n/a | 5 | n/a | network | n/a | n/a | n/a | | Telehealth | 4 | 3 | 8h | IDP, network | 2 | 4h | 8h | | Document mgmt | 2 | 2 | 48h | IDP | 3 | 24h | 48h |

Backup Restore Drill Log (Appendix D)

| Date | Tester | System | File restored | Restore time | Integrity check | Notes | |---|---|---|---|---|---|---| | 2026-03-15 | <name> | EHR | random encounter 2026-02 | 14 min | OK | passes | | 2026-06-15 | <name> | PM | random claim 2026-05 | 22 min | OK | | | 2026-09-15 | <name> | Imaging | random study 2026-07 | 31 min | OK | | | 2026-12-15 | <name> | EHR | nightly DB image | 47 min | OK | |

How to deploy

The deployment sequence: ratify the plan with the Security Officer, Privacy Officer, and practice owner; complete the criticality analysis by walking the asset list and asking what stops clinical care; build the downtime encounter packet (paper templates, last printable patient list, MAR backup, critical patient binder) and pre-stock it at every workstation; document the restoration runbook for each tier-1 and tier-2 system with vendor contact, credential set, and verification step; run the first quarterly restore drill before the plan goes live; book the annual tabletop on the calendar.

The fastest measurable improvement is the downtime encounter packet. It costs nothing and converts a ransomware day from chaos into measured continuity. Practices that have the packet typically restore documentation backfill inside 72 hours; practices that do not lose claims for the affected period and may face medical-necessity gaps when payers audit.

Common gaps

The five most common defects from binder review:

1. No emergency mode operation plan. DRP exists; the operational continuity piece is absent. Clinic stops when the EHR stops.
2. Untested backups. Backup runs nightly; no one has ever restored from it. Discovered during the ransomware event.
3. No immutable backup. Backups are written to a NAS the same credentials reach. Ransomware encrypts both.
4. Vendor SLA mistaken for the practice plan. The cloud EHR has 99.9% uptime; the practice has no plan for the 8.76 expected downtime hours per year.
5. No criticality analysis. Plan treats all systems equally; the upstream dependency on the identity provider is not surfaced; an IDP outage takes the practice down without a documented response.

Maintenance cadence

• Quarterly: backup restore drill; criticality analysis review for new vendors or systems.
• Annually: full plan refresh; tabletop simulation; live failover test where supported; criticality analysis re-ranked; downtime packet refresh.
• On any incident: post-incident review within 10 business days; plan revisions filed; six-year retention starts.
• On any material change: EHR migration, new vendor, new location, M&A — re-run the affected sections.

State preemption note: California's CMIA and NY SHIELD require reasonable safeguards including business-continuity planning. State breach-notice timelines run independently of contingency-plan testing — if ransomware triggers a breach, Massachusetts General Laws ch. 93H, § 3, NY SHIELD, and Texas Business and Commerce Code Chapter 521 all impose their own timelines on top of HIPAA's 60-day window.

How d3rx fits

The d3rx compliance binder generates the contingency plan, the criticality analysis, the restoration runbook scaffolds, the downtime encounter packet, the restore-drill log, and the annual tabletop scenario library with § 164.308(a)(7), § 164.316(b)(2)(i), NIST SP 800-34, and the HHS Ransomware Guidance cited inline. The practice's Security Officer remains responsible for setting RTO/RPO, testing, and activating the plan.