HIPAA and EHR Data Access: What Covered Entities Must Maintain During an Outage

18 August 2026

AUTHORED BY: Chloe Williams

Healthcare organizations spend considerable effort ensuring HIPAA compliance during normal operations. Access controls are implemented and audited. Workforce training is conducted. Business associate agreements are maintained. The privacy and security infrastructure of the typical covered entity reflects years of investment and ongoing operational commitment.

What receives far less systematic attention is what HIPAA requires during an EHR outage. The assumption, sometimes explicit but more often simply unstated, is that an outage is a temporary technical emergency that creates a pause in normal operations, and that HIPAA’s requirements are calibrated for normal operations rather than for emergency conditions. That assumption is incorrect and it creates compliance exposure that most covered entities have not fully evaluated.

HIPAA’s requirements do not pause during an EHR outage. The Security Rule’s contingency planning standards specifically address system failures and require that covered entities have documented, tested procedures for maintaining the protection of electronic protected health information during emergency conditions. What changes during an outage is not the applicability of the requirements but the difficulty of meeting them, and organizations that have not built their downtime infrastructure with HIPAA compliance in mind tend to discover that difficulty at the worst possible moment.

What the HIPAA Security Rule Requires for Emergency Conditions

The Security Rule’s Contingency Plan standard, found at 45 CFR 164.308(a)(7), is the primary regulatory provision governing EHR outage preparedness. It requires covered entities to establish and implement policies and procedures for responding to an emergency or other occurrence that damages systems containing electronic protected health information. The standard has five required or addressable implementation specifications:

  • Data backup plan: A documented procedure for creating and maintaining retrievable exact copies of ePHI. During an outage, this means having a mechanism for ensuring that ePHI generated during the downtime period is preserved and not lost when normal operations resume
  • Disaster recovery plan: A documented procedure for restoring any loss of data. This addresses the system restoration dimension of the outage rather than the clinical continuity dimension
  • Emergency mode operation plan: A documented procedure for enabling continuation of critical business processes for protection of the security of ePHI while operating in emergency mode. This is the provision most directly relevant to downtime clinical operations, and it is the one most frequently underimplemented
  • Testing and revision procedures: A procedure for periodic testing and revision of contingency plans. The testing requirement is specific and enforceable, and the absence of documented testing is one of the most common findings in OCR enforcement actions related to contingency planning
  • Applications and data criticality analysis: An assessment of the relative criticality of specific applications and data in support of other contingency plan components. This requires that covered entities specifically identify which systems and data are most critical and prioritize their protection accordingly

The emergency mode operation plan is the provision that most directly governs what a covered entity must do during an EHR outage to maintain HIPAA compliance. It requires not just that critical business processes continue but that they continue in a way that maintains the protection of ePHI. A downtime procedure that allows staff to access patient data through an uncontrolled, unaudited backup system does not satisfy the emergency mode operation plan requirement, even if it keeps clinical workflows running.

The Access Control Requirement During Downtime

Under normal operations, the EHR’s access control system ensures that only authorized users can access ePHI, that access is role-based, and that sessions time out after periods of inactivity. These controls satisfy the Security Rule’s Access Control standard at 45 CFR 164.312(a)(1). During an outage, the EHR’s access controls are not running. Whatever backup system provides access to patient data during the outage must have its own access control framework that satisfies the same standard.

This requirement has specific practical implications for how downtime workstations are configured and used:

  • Downtime workstations must require authentication before providing access to patient data, not simply be accessible to anyone in the vicinity of the workstation
  • Access must be limited by role so that clinical staff see the patient data relevant to their authorized scope of care, not all patient data in the system
  • Sessions on downtime workstations should have defined timeout periods after which re-authentication is required, mirroring the session management controls that apply in normal EHR operations
  • Access to downtime workstations should be tracked and logged so that the organization can demonstrate after an outage which staff accessed which patient information during the event

dbtech’s Downtime Solution is configured with authentication requirements and role-based access controls that satisfy the Security Rule’s Access Control standard during a downtime event. The access log maintained by dbtech’s system provides the audit evidence needed to demonstrate that access was controlled throughout the outage period.

The Audit Control Requirement and Why the Downtime Period Is High Risk

The Security Rule’s Audit Control standard at 45 CFR 164.312(b) requires that covered entities implement hardware, software, or procedural mechanisms to record and examine activity in information systems that contain ePHI. In normal operations, the EHR’s audit log satisfies this requirement by recording every instance of ePHI access, including who accessed it, when, and from which system.

During a downtime event, the EHR audit log is not running. If the covered entity’s backup system does not maintain its own audit log, the downtime period represents a gap in the audit trail that the organization cannot reconstruct after the fact. In an OCR investigation or a HIPAA audit that covers a period including a downtime event, an undocumented period of ePHI access is a significant finding.

The audit risk is compounded during downtime because access controls may be less rigorous than normal and because the operational stress of managing an outage can lead to access decisions that would not occur under normal conditions, such as a staff member accessing a patient record from a different unit because their own unit’s workstation is not yet active. Without an audit log capturing these access events, the organization cannot evaluate whether any inappropriate access occurred during the outage.

dbtech’s activity logging captures access events during the downtime period with the user, timestamp, and patient record information needed to satisfy the audit control requirement. This log is preserved after the EHR is restored and is available to the compliance team for review and to OCR if a review is ever initiated.

The Minimum Necessary Standard During Downtime

The HIPAA Privacy Rule’s minimum necessary standard requires that covered entities make reasonable efforts to limit the use, disclosure, and request of PHI to the minimum necessary to accomplish the intended purpose. During normal operations, role-based access controls in the EHR implement this standard automatically by limiting what each user can see based on their role and the patients they are authorized to treat.

During a downtime event, minimum necessary compliance becomes more challenging. If all patients in the facility are visible to all staff on all downtime workstations without role-based filtering, the organization is not meeting the minimum necessary standard regardless of whether the intent was appropriate. The practical implication is that downtime workstation configurations need to implement data filtering based on user role and patient assignment, not simply display the entire patient population to every authenticated user.

For covered entities with particularly sensitive patient populations, including behavioral health patients, substance use disorder patients, and HIV-positive patients whose records may carry additional state law protections, the minimum necessary standard during downtime deserves specific attention in the downtime policy.

What the Covered Entity Must Document

HIPAA compliance is ultimately demonstrated through documentation, and the downtime context is no exception. The documentation that a covered entity needs to maintain to demonstrate HIPAA compliance related to EHR outages includes:

  • The written emergency mode operation plan required by the Contingency Plan standard, specifically addressing how ePHI protection is maintained during an outage
  • Documented testing of the contingency plan within the required timeframe, with recorded outcomes
  • The access log from each downtime event, including both planned maintenance windows and unplanned outages, maintained for the six-year period required for HIPAA Security Rule documentation
  • Any breach risk assessments conducted in connection with a downtime event that involved a potential security incident, along with the determination reached and the basis for that determination
  • Training records demonstrating that workforce members have been trained on HIPAA obligations during downtime events

For covered entities that want to evaluate whether their current downtime infrastructure and documentation satisfy these HIPAA requirements, dbtech’s Downtime Audit Assessment includes a review of the compliance dimensions of the current downtime program. To learn more, contact our team or request a demo.

Want to learn more? Fill out the form below and a representative will call you ASAP!