Skip to main content
Patient Protect circular logo mark in purple and white used for site navigationPatient Protect

Breach analysis · Patient Protect

§164.308(a)(7) Contingency Planning: Keeping Clinical Operations Running When Connectivity Fails

A simultaneous phone and internet failure across all hospital locations is what §164.308(a)(7) contingency planning is designed to prevent from becoming a patient-safety crisis — here's how to close the gap.

Patient Protect ResearchJuly 30, 2026First reported in HIPAA Pulse →

The control gap

System-wide communications failure is the scenario that separates practices with tested contingency plans from those with documented-but-undrilled ones. When both phone and internet go down simultaneously across an entire health system, every layer of clinical operations that depends on network connectivity — EHR access, lab results, imaging, internal communications — becomes unavailable at once. A recent multi-hospital outage affecting all four of AnMed Health System's Upstate South Carolina locations illustrates exactly this failure mode: emergency rooms remained open, but the breadth of the simultaneous loss raised immediate questions about EHR access, PHI availability, and whether clinical staff had functional downtime procedures to fall back on. First reported in HIPAA Pulse → https://hipaapulse.com/developing-anmed-reports-phone-and-internet-outage-impacting-all-hospital-locations-ers-760cbc0c

The pattern — full phone and internet loss across all facilities at once — is consistent with both ransomware-initiated network isolation and unplanned infrastructure failure. Until the cause is confirmed, the HIPAA implications remain open. What is already clear is that centralized network dependencies create shared failure points, and those failure points require explicit contingency controls under the Security Rule.

The HIPAA Security Rule provision in play

45 CFR §164.308(a)(7) — the Contingency Plan standard — requires covered entities to establish policies and procedures for responding to emergencies that damage systems containing ePHI. Its five required and addressable implementation specifications are directly implicated here:

  • (i) Data Backup Plan — ensuring retrievable, exact copies of ePHI exist
  • (ii) Disaster Recovery Plan — restoring data systems and operations
  • (iii) Emergency Mode Operation Plan — maintaining critical business processes during emergencies
  • (iv) Testing and Revision Procedures — periodically testing contingency plans
  • (v) Applications and Data Criticality Analysis — prioritizing which systems must be restored first

If the outage is ultimately attributed to a cyber incident, 45 CFR §164.400–414 breach notification obligations would also apply, requiring notification to HHS and affected individuals within the specified 60-day discovery clock.

How Patient Protect addresses this

  • Security Risk Assessment (SRA): Patient Protect's SRA surfaces single points of network failure and gaps in contingency plan coverage before an outage forces the discovery. It maps ePHI-dependent systems and scores unaddressed contingency risks against the §164.308(a)(7) specifications.
  • Policy Generation: Produces written downtime procedures, emergency mode operation plans, and disaster recovery documentation — the paper-based artifacts that staff need to function when EHR and internet access are gone.
  • Autonomous Compliance Engine: Continuously recalculates compliance state as new risks are identified or configurations change, so contingency plan gaps don't silently accumulate between annual reviews.
  • Information Systems Inventory: Catalogs ePHI-touching systems and their connectivity dependencies, enabling the criticality analysis §164.308(a)(7)(ii)(E) requires — and identifying which systems represent shared failure points.
  • BAA Management / Vendor Risk Scanner: If cloud-based EHR, billing, or scheduling vendors lose connectivity, BAA terms govern notification timelines. Patient Protect tracks those agreements and flags gaps in vendor notification obligations.

Practical next steps

  • Pull your current contingency plan and verify it has an Emergency Mode Operation Plan — a written, offline-accessible procedure for documenting care, communicating internally, and reaching patients without internet or phone access
  • Audit your network topology for single points of failure — if one provider outage or one routing failure can take down phone and internet simultaneously, that dependency needs to be documented in your risk register
  • Schedule a downtime drill — run a 30-minute tabletop exercise in which staff document a patient encounter without EHR access; gaps in paper-based workflows surface quickly
  • Test backup communications — confirm that cellular failover lines, out-of-band staff contact lists, and emergency patient contact methods are functional, not just documented
  • Review your BAA notification requirements — confirm how quickly your cloud EHR and billing vendors are contractually required to notify you of connectivity disruptions affecting ePHI availability

Try Patient Protect

  • Start a free trial at hipaa-port.com → https://hipaa-port.com
  • Run a free Security Risk Assessment at patient-protect.com/risk-assessment → https://patient-protect.com/risk-assessment

This commercial companion is published by Patient Protect and may be co-written with editorial AI assistance, drawing on the source HIPAA Pulse article. First reported in HIPAA Pulse → https://hipaapulse.com/developing-anmed-reports-phone-and-internet-outage-impacting-all-hospital-locations-ers-760cbc0c