Emergency Access Procedure

HIPAA’s Emergency Access Procedure requirement means you must have a defined, tested way to retrieve necessary ePHI during emergencies, without breaking access controls or losing auditability. Put in place a “break-glass” workflow, pre-approved roles, alternate authentication options, and downtime procedures so care and operations can continue while you preserve minimum necessary access and logging. ¹

Key takeaways:

• You need a written, implementable procedure for emergency ePHI access, not an informal understanding. ¹
• “Break-glass” access must be bounded: approved users, time limits, logging, and post-event review. ¹
• Plan for real failure modes: EHR outage, network loss, IAM downtime, disaster relocation, and third-party hosted systems. ¹

Emergency access is one of those requirements that looks simple until an incident hits. During a ransomware event, a regional outage, an EHR downtime, or an evacuation, your normal access controls can become a blocker to patient care and continuity of operations. HIPAA doesn’t let you choose between security and access; it expects you to pre-plan controlled emergency access to ePHI and execute it as needed. ¹

For a Compliance Officer, CCO, or GRC lead, the practical goal is to translate this into an operational workflow that IT, Security, Clinical Ops, and Help Desk can run under pressure. That means: defining what counts as an “emergency,” specifying who can approve and use emergency access, building a technical method (often “break-glass” accounts or privileged access workflows), and making sure you can prove what happened afterward through logs and review records. ¹

This page focuses on requirement-level execution: scope, step-by-step implementation, evidence to retain, audit questions, and common failure patterns. It also covers third-party dependencies, because many emergency access failures happen when a hosted EHR, managed identity provider, or MSP becomes the single point of failure.

Regulatory text

Requirement: “Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.” ¹

Operator interpretation (what you must do):

• Establish procedures: Write and approve a procedure that explains exactly how authorized staff obtain necessary ePHI when normal access paths are disrupted or insufficient due to an emergency. ¹
• Implement as needed: The procedure cannot be shelfware; you must be able to execute it during real events and exercises, and you must do so when conditions require emergency access. ¹
• Obtain necessary ePHI: The scope is “necessary” ePHI, so your process should incorporate minimum necessary thinking (role limits, dataset limits, time limits) and maintain accountability (logging and review). ¹

Plain-English requirement

You need a pre-planned “how we get access when things go wrong” playbook for ePHI systems. It should let the organization keep providing care and critical services during an emergency while keeping emergency access controlled, traceable, and reviewed afterward. ¹

Who this applies to

Entity scope

• Covered Entities and Business Associates that create, receive, maintain, or transmit ePHI. ¹

Operational scope (where this shows up)

• Clinical systems: EHR/EMR, PACS, lab, pharmacy, radiology, ED tracking, telehealth platforms.
• Identity and access infrastructure: SSO/IdP, MFA, directory services, privileged access tools.
• Data platforms: HIE interfaces, data warehouses with ePHI, secure messaging containing ePHI.
• Third parties: hosted EHR, cloud hosting, MSPs, SOC providers, call centers handling ePHI, document management platforms.

If a third party is required to restore access (for example, managed EHR hosting or outsourced IAM), your emergency access procedure must address how you reach them, what authority they have, and how you obtain ePHI if they are unavailable. ¹

What you actually need to do (step-by-step)

1) Define “emergency” in operational terms

Write a definition your teams can apply in real time. Include:

• Trigger conditions: system outage, ransomware containment steps, facility disaster, loss of network connectivity, loss of IAM/MFA services, mass casualty events, emergency relocation.
• Decision authority: who declares emergency access mode (for example, Incident Commander, CIO on-call, Clinical Operations leader).

Avoid vague phrasing. If staff can’t tell whether to invoke the procedure, they will either bypass controls ad hoc or freeze. ¹

2) Identify “necessary ePHI” and minimum access sets

Create an emergency access matrix by role and scenario:

• Which roles need access (ED physician, pharmacist, house supervisor, on-call IT security)?
• Which systems and data types are required (med list, allergies, recent labs)?
• What constraints apply (read-only vs. write, export restrictions)?

This becomes your justification for limiting break-glass privileges to what is actually needed. ¹

3) Implement a technical emergency access method (pick a primary and a fallback)

Common patterns:

• Break-glass within the application: users authenticate normally, then elevate with justification and enhanced logging.
• Emergency privileged accounts: sealed credentials in a controlled vault with strict checkout and approval.
• Downtime access process: pre-generated downtime reports or replicated read-only datasets available during primary system outage.

Design for failure: your emergency method must still work if SSO, MFA, or network segments are degraded. ¹

4) Set governance rules: approval, time-bounding, and monitoring

Document:

• Who can initiate emergency access (named roles, not individuals).
• Who approves (if approval is possible during the emergency) and what to do if the approver is unavailable.
• Time limits: when emergency access ends and how accounts are disabled or privileges revoked.
• Logging requirements: what must be logged (user, timestamp, system, patient record accessed, reason code) and where logs are retained. ¹

5) Build the runbook your teams will follow under stress

Your Emergency Access Procedure should read like an incident runbook:

• Preconditions and triggers
• Step-by-step actions (by team)
• Communication plan (Clinical, IT, Security, Compliance, third party contacts)
• Escalation paths
• “Return to normal” steps and post-incident review checklist

Keep it short enough to execute. Put the longer rationale in an appendix. ¹

6) Validate with exercises and operational tests

Test the procedure in tabletop exercises and controlled technical tests (for example, simulate IdP outage). Capture gaps and assign remediation owners. The requirement explicitly expects you to “implement as needed,” so you need evidence you can run it. ¹

7) Integrate third-party dependencies

For each critical third party that touches ePHI availability:

• Confirm their downtime and emergency access support path.
• Ensure your contract and operational contacts allow rapid engagement.
• Confirm how you obtain data exports or continuity access if their platform is unavailable.

A practical way to operationalize this is to track third-party emergency access contacts, escalation paths, and outage procedures in the same repository as your runbook, so the incident team doesn’t hunt through old email threads.

Tooling note: Many teams operationalize this in a GRC system that assigns owners, collects evidence, and preserves version history. Daydream can centralize the runbook, approvals, and evidence requests across IT, Security, and third parties so emergency access isn’t scattered across shared drives and ticket queues.

Required evidence and artifacts to retain

Maintain artifacts that prove the procedure exists and works in practice:

• Emergency Access Procedure document with version history and approvals. ¹
• Emergency access role matrix (roles → systems → permissions → constraints).
• Configuration evidence: screenshots or exports showing break-glass settings, privileged account vault controls, or emergency role assignments.
• Access logs and audit trails for emergency access events (or test events).
• Exercise records: tabletop agenda, attendees, scenarios, outcomes, remediation tickets.
• Incident records (when invoked): who declared the emergency, when emergency access began/ended, approvals/justifications captured, post-incident review notes.
• Third-party contact and escalation list and proof it is maintained (change log, periodic review notes).

Common exam/audit questions and hangups

Auditors and security assessors tend to focus on these points:

• “Show me the documented procedure and where it is approved.” ¹
• “How do you ensure emergency access is limited to necessary ePHI?” ¹
• “Demonstrate logging for break-glass access and how you review it.”
• “What happens if SSO/MFA is down? Can clinicians still access necessary records?”
• “When was this last tested, and what changed afterward?”
• “Which third parties are involved in restoring access, and how do you reach them during an outage?”

Hangup to expect: teams often have downtime procedures for clinical care but no controlled emergency access path for administrative ePHI systems (billing platforms, document repositories) that still contain ePHI.

Frequent implementation mistakes (and how to avoid them)

1. One shared emergency account with a posted password.
   Fix: use named users or tightly controlled vault checkout with individual accountability and immediate post-use rotation.

2. Break-glass without real monitoring.
   Fix: require reason codes/justification, generate alerts to Security/Compliance, and perform a documented post-event review.

3. No clear trigger for invocation.
   Fix: define emergency triggers and designate a role that declares “emergency access mode.”

4. Emergency access exists only for the EHR.
   Fix: extend scope to all systems that store or route ePHI, including cloud storage, secure messaging, and data platforms.

5. Third-party single point of failure.
   Fix: document third-party escalation, confirm contractual support paths, and maintain an alternate method to obtain necessary ePHI if the platform is impaired.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, emergency access failures create two simultaneous risks:

• Patient safety and operational continuity risk if clinicians cannot retrieve needed information.
• Security and privacy risk if staff bypass controls through unsafe workarounds (sharing passwords, exporting data to unmanaged devices) during high-stress events. ¹

Treat emergency access as both a security control and a continuity control. Your strongest posture is a designed workflow that staff trust, because it works when normal systems do not. ¹

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign an owner (often Security + Clinical Apps) and name a cross-functional working group.
• Inventory ePHI systems and identify which ones lack a documented emergency access method.
• Draft the Emergency Access Procedure runbook with triggers, authorities, and step-by-step actions. ¹
• Identify top failure modes (IdP outage, EHR outage, facility disruption) and map them to access paths.

By 60 days (Near-term)

• Implement or refine break-glass controls in priority systems.
• Build the emergency access role matrix and have Clinical leadership validate “necessary” datasets.
• Configure logging, alerting, and a post-event review workflow.
• Collect third-party emergency contacts and document escalation steps for hosted systems.
• Run a tabletop exercise and capture remediation items. ¹

By 90 days (Operationalize and sustain)

• Run a technical test in a controlled window (for example, simulate SSO disruption) and document results.
• Train Help Desk, on-call IT, and clinical supervisors on invocation and documentation.
• Add a recurring review process: update contacts, validate access lists, and confirm log review is happening.
• Centralize evidence collection (policy versions, test results, logs, and review notes) in a system of record such as Daydream to reduce audit scramble and avoid missing artifacts.

Frequently Asked Questions

Does HIPAA require “break-glass” access specifically?

The regulation requires procedures to obtain necessary ePHI during an emergency, but it does not mandate a specific technical pattern. Break-glass is a common way to implement controlled emergency access with accountability. ¹

What counts as an “emergency” for this requirement?

Define emergencies based on conditions that prevent normal authorized access or require rapid expanded access to protect care and operations. Document trigger criteria and who can declare emergency access mode so staff don’t guess. ¹

Can we use a shared emergency account if we rotate the password afterward?

Shared accounts create accountability gaps during audits and post-incident investigations. Prefer named-user elevation or vault checkout that records who accessed credentials, when, and why. ¹

How do we handle emergency access when MFA is down?

Design a fallback that remains controlled, such as offline recovery codes in a secure vault, a separate emergency authentication path, or pre-provisioned emergency roles that don’t depend on the failed component. Document the exact steps and test them. ¹

Do we need to test emergency access procedures?

HIPAA says “establish (and implement as needed),” and auditors commonly expect proof the procedure works. Tabletop exercises plus at least one controlled technical validation provide strong evidence of operational readiness. ¹

How do business associates meet this requirement if the covered entity controls access?

Business associates should document their own emergency access procedures for systems they operate and coordinate with covered entities on incident workflows, contacts, and responsibilities. Where the covered entity controls access, the BA should still define how it requests or supports emergency access and how it preserves logs. ¹

Footnotes

1. 45 CFR Parts 160, 162, 164