164.308(a)(7)(ii)(C) Emergency mode operation plan

What the emergency mode operation plan requires and why it is hard to get right

If your contingency plan covers backup and restore but you cannot yet show how clinical or billing workflows keep running securely during an outage, you have a gap that assessors will notice. Under 45 CFR 164.308(a)(7)(ii)(C), you must establish, and implement as needed, procedures that continue your critical business processes while protecting the security of ePHI when you operate in emergency mode. It is a required implementation specification, so it cannot be documented away as optional. The key distinction is timing: this specification covers how you operate during the event, while the data backup and disaster recovery plans cover getting data back afterward.

The common difficulty is that security controls are usually designed for normal operations. Role-based access, single sign-on, session timeouts, logging pipelines and network segmentation all assume that the identity provider, the database and the monitoring stack are healthy. In an outage, staff often need break-glass access, a fallback application on a different host, or a paper or offline workflow, and each of those shortcuts can quietly remove a safeguard. Start by listing the critical processes identified in your applications and data criticality analysis, then document, for each one, which controls are relaxed, who may approve the change, how it is logged and how normal controls return.

Ask your team to confirm three things before the next test. First, which emergency access paths already exist for ePHI, and whether the technical emergency access procedure in 164.312(a)(2)(ii) and the facility contingency operations specification in 164.310(a)(2)(i) are covered in the same plan. Second, whether monitoring still works when the primary environment is down, since alerting that depends on the failed system gives no warning. Third, whether the plan has been exercised in a tabletop or live test. NIST SP 800-66 Rev. 2 treats developing and implementing this plan as a key activity of the contingency plan standard, which makes it a reasonable reference for the evidence an assessor will ask to see.

Which systems, sites, teams and vendors the emergency mode operation plan covers

The emergency mode operation plan is only as good as its scope. Before writing procedures, the organization must decide which processes, sites, teams and third parties it must keep running during an emergency, and which ePHI each one needs. The cards below cover the scoping decisions that change the plan and the evidence an assessor will ask to see.

Critical business processes that depend on ePHI

Start by listing the business processes that cannot stop without ePHI, such as patient scheduling, medication ordering, lab result release, claims submission and clinical documentation. Each process should name the applications, data stores and interfaces it uses. This list defines what the plan must keep running and gives the assessor a traceable starting point for 164.308(a)(7)(ii)(C). Check that the list was built from the process owners' view, not only from the IT asset inventory.

Applications and data criticality ranking

The applications and data criticality analysis, an addressable specification under 164.308(a)(7)(ii)(E), ranks systems by how much the business depends on them. That ranking sets which systems get emergency access, which run in degraded mode and which can wait for restoration. Record the ranking, the rationale and the date it was approved. An assessor will compare the emergency procedures against this ranking to see whether priorities match the stated risk.

Facilities and workstations used during an outage

Identify which clinics, wards, pharmacies, data centers and offices must keep operating if the primary site is unavailable, and which workstations and mobile devices staff will use there. The facility contingency operations specification in 164.310(a)(2)(i) supports facility access for the emergency mode plan, so the plan must name who can enter which areas and under what conditions. Confirm that alternate sites have the same access controls and that workstation use rules still apply.

Emergency access to ePHI by named roles

Decide which roles may obtain ePHI during an emergency, such as on-call clinicians, break-glass administrators or regional incident leads. The technical emergency access procedure in 164.312(a)(2)(ii) covers obtaining necessary ePHI in an emergency, so the plan must link each role to a documented access path and a logging method. Ask whether access can be revoked quickly once the emergency ends, and whether every emergency session is reviewed afterward.

Third parties that keep systems running

List every vendor, hosting provider, managed service and telecom carrier that must keep systems available in an emergency, and what each one does during an outage. Business associate arrangements under 164.308(b)(1) must already cover their access to ePHI. Confirm each vendor's emergency contact path, response commitments and whether its own contingency plan is current. Gaps here often surface only during a real outage, so test these dependencies in exercises.

Internal teams and their emergency duties

Name the teams that run the emergency mode operation, including clinical operations, IT operations, security, privacy, facilities and communications, and assign each one specific duties. Record who declares emergency mode, who decides when to end it, and how staff reach each other if normal channels fail. An assessor will look for evidence that these people were trained on the plan and that the roster reflects current staffing, not last year's org chart.

How an assessor tests the emergency mode operation plan

This table lists the five steps an assessor typically takes when testing 164.308(a)(7)(ii)(C), with the approach, the evidence requested and the findings that come up most often. Read each row as a question the organization should be able to answer with dated records before an assessor asks it.

Test step	Test approach and evidence requested	Common findings
Review the written plan against critical processes	The assessor compares the written emergency mode operation plan with the applications and data criticality analysis (164.308(a)(7)(ii)(E)) and asks which business processes must keep running while ePHI is protected. Evidence: the dated plan, the list of critical processes, owners and approval records.	Plan lists processes that the criticality analysis never ranked, or names no owner for a critical clinical or billing process.
Walk through emergency access	The assessor asks how a clinician or administrator obtains necessary ePHI during an emergency under the technical emergency access procedure (45 CFR 164.312(a)(2)(ii), required). Evidence: the break-glass procedure, sample access grants and the audit log entries that record them.	Emergency access exists only as an informal practice, or emergency logins are not logged or reviewed afterward.
Check facility contingency operations	The assessor checks that facility access procedures under 45 CFR 164.310(a)(2)(i) allow authorized staff to enter the sites and areas needed to run the plan, and that access is still controlled. Evidence: facility contingency procedures, badge or key override records and designated authorizers.	Facility procedures are written for disaster recovery only, or emergency entry rules are not coordinated with the plan.
Confirm the plan was exercised and revised	The assessor asks for records of tests, drills or tabletop exercises of the emergency mode operation plan and the changes made afterward, in line with the testing and revision specification (164.308(a)(7)(ii)(D)). Evidence: exercise dates, scenarios, attendee lists, issues logged and plan revision history.	Plan has never been exercised, or results from an exercise are not linked to a revised version of the plan.
Check third-party arrangements	The assessor reviews whether hosting providers, managed IT providers and other business associates have emergency operation duties written into their contracts or arrangements (164.308(b)(1)) and can support the plan. Evidence: contract clauses, service descriptions, escalation contacts and recent test participation.	Contracts cover backup or recovery only, with no commitment to keep the processes running during an emergency.

How to build an emergency mode operation plan step by step

This sequence turns the criticality analysis into a tested emergency mode operation plan that keeps essential processes running while ePHI stays protected. Each step ends with a document or record that an assessor can inspect.

Confirm critical business processes from the criticality analysis
Start from the applications and data criticality analysis, which ranks systems and data by importance. Pull out the business processes that must keep running during an emergency, such as patient registration, medication ordering, scheduling, claims submission or clinical documentation, and name the systems and data each one depends on. Involve operations managers and clinical leads, not only IT, because they know which processes cannot pause. The output is a process inventory that lists each critical process, its owner, its supporting systems and the ePHI it touches. The step is complete when every process has a named owner and every dependent system appears in the inventory.
Define protected operation for each process
For each critical process, write down what safe operation means while the normal environment is unavailable. This covers which safeguards must still apply, such as authenticated access, audit logging, encryption of data in transit, limits on who can view ePHI and secure handling of paper downgrades. Record the minimum set of controls the risk analysis says must hold, so staff do not trade protection for speed. The output is a protected operation matrix that pairs each process with its required safeguards and the fallback method used if a control cannot run. The step is complete when the security official and process owner have both signed off on the matrix.
Set and log emergency access procedures
Define how workforce members obtain the ePHI they need during an emergency through the technical emergency access procedure, which is a required safeguard. Specify who may invoke emergency access, the approval path, the time window, the systems covered and the review that happens after the event. Build in logging so each emergency access session records the user, the data accessed and the justification, and assign someone to review those logs once normal operations resume. The output is a written emergency access procedure and a sample access log template. The step is complete when a test user can follow the procedure and the resulting log entries show every required field.
Align facility access and workstation use with the plan
Walk through the physical locations that support critical processes, such as data closets, backup sites, clinical areas and alternate work locations. Document how facility access is granted for emergency operations under the facility contingency operations specification, including who holds keys or badges, how access is confirmed and how it is withdrawn. Update workstation use guidance for alternate sites and devices, so that staff working from temporary locations apply the same screen, device and authentication rules. The output is a facility access annex and an updated workstation use appendix. The step is complete when facility managers and the security official have reviewed both and the access instructions match the current badge and key records.
Document activation and return-to-normal criteria
Write the conditions that trigger the emergency mode operation plan, who decides to activate it and how the decision is communicated to staff. Then define the criteria for returning to normal operations, including when systems are verified as clean, when backlogs are reconciled and when emergency access is closed. Assign an incident commander and a deputy, and list the contact channels they will use if standard communication systems are down. The output is an activation and deactivation runbook with a decision checklist and a contact roster. The step is complete when the runbook names decision-makers, lists each trigger condition and includes a reconciliation checklist for the return to normal.
Schedule drills and revise after each exercise
Test the plan on a schedule the risk analysis supports, using tabletop walkthroughs and, where practical, operational drills that switch critical processes into emergency mode. Record what was attempted, who participated, which steps failed or took longer than expected, and which safeguards were tested. Feed each finding into a revision of the affected procedure, runbook or matrix, and record the change with its date and approver. The output is a drill record and a revision log for the plan. The step is complete when each finding has a documented change or a documented decision to accept the risk, and the next drill date is on the calendar. Confirm with your own counsel and risk owners how often drills should run, because the rule does not set a fixed interval.

Evidence that satisfies the emergency mode operation plan

An assessor testing 164.308(a)(7)(ii)(C) looks for a plan that names the critical processes, shows how ePHI stays protected while those processes run, and proves the plan has been exercised and kept current. The artifacts below connect those three points, and each one needs a dated owner and a refresh trigger to stay credible between audits.

Written emergency mode operation plan

The plan itself should list each critical business process, the systems and ePHI it depends on, the staff who run it, and the security controls that stay active in emergency mode. Assessors check that the plan ties back to the applications and data criticality analysis, so the process list should match that analysis. Confirm that the plan names who may declare emergency mode and how it ends. Keep one current version with a named owner.

Emergency access procedures and logs

Emergency access shows how workforce members obtain ePHI when normal access paths fail, which is the subject of the technical emergency access procedure in 164.312(a)(2)(ii). Keep the break-glass accounts, their approval steps and their activation records, then review the access log entries after each activation. Assessors often ask whether emergency access was reviewed and whether it was revoked once the event ended. Store logs where the people running the plan cannot edit them.

Facility contingency operation records

These records show how facility access works during an emergency, which connects to the facility contingency operations specification in 164.310(a)(2)(i). Keep the list of alternate sites or access arrangements, the people authorized to enter, and any sign-in or badge records from activations. Confirm that facility access rules still protect ePHI when staff work from alternate locations. Update the list whenever a site, badge system or landlord arrangement changes.

Drill and tabletop reports

A drill or tabletop report records the scenario, the critical processes tested, the time each process took to resume, and the gaps found. Assessors expect the report to show who participated and whether results went back into the plan. Each finding should carry a corrective action with an owner and a closure date. Schedule the next exercise on the calendar so the report history shows regular testing rather than a single event.

Backup restore and monitoring evidence

Emergency mode depends on ePHI remaining available, so assessors often ask for proof that backups can be restored during the drill. Keep restore job records and integrity check results, such as those from Bareos restore jobs or restic check runs with read-data options. Monitoring alerts from Grafana or Prometheus that fired during a drill show whether the team saw the event. Retain these outputs with the drill report they support.

Plan revision and approval history

The revision history shows that the plan changed when systems, staff or critical processes changed, and that management approved each version. Keep a dated change log, the reason for each revision and the approver's name. Assessors compare this record with system change tickets to see whether the plan kept pace with the environment. Documentation must be retained for six years under 164.316, so keep older versions available too.

What meeting the emergency mode operation plan costs

This table lists the cost components of building and keeping an emergency mode operation plan, who is paid for each one, and whether it is one-time or recurring. Read the drivers column to see what pushes each cost up, then use the list of quote questions to compare written scopes. No dollar figures or durations appear here because none are supplied for this requirement; figures come from the written scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Process mapping and critical process list	Internal operations and clinical leads, sometimes with an outside facilitator	One-time, then recurring at each review	Number of critical business processes and how many systems each one touches
Plan writing and approval	Security official, operations owners and compliance staff	One-time, then recurring at each revision	Number of sites, departments and manual workarounds that must be documented
Emergency access and degraded-mode engineering	Internal engineers or an implementation partner under a fixed-scope agreement	One-time build, recurring configuration changes	Maturity of existing identity, backup and monitoring; number of systems needing break-glass access
Drills and tabletop exercises	Staff time across departments, plus facilitator fees if external	Recurring on the schedule set in the plan	Number of critical processes exercised, frequency and whether live failover is tested
Tooling and licenses	Software vendors, or no license fee for self-hosted open-source components	Licenses recur; open-source tooling still needs hosting and staff time	Choice between commercial monitoring and backup suites and self-hosted open-source alternatives
Evidence upkeep	Internal control owners who keep drill records, logs and sign-offs current	Recurring	Retention periods set by the organization, number of systems covered and how evidence is stored
Third-party review or testing	Independent testers or consultants, separate from the plan author	Usually one-time per cycle, recurring if tied to an audit calendar	Number of third parties whose services support critical processes and how their failover is verified
Auditor sampling and assessment	Independent assessor, paid by the organization under its own engagement	Recurring with each assessment cycle	Scope of the assessment, number of drill records sampled and quality of existing evidence

Which self-hosted open-source tools support emergency mode evidence

Four self-hosted open-source tools can produce operational evidence that an emergency mode operation plan is practiced and working. None of them satisfies 164.308(a)(7)(ii)(C) on its own, because the requirement is met by the documented procedures, the people who run them and the records of how they performed.

Bareos scheduled restore jobs

Bareos schedules and supervises backup, restore and verify jobs, and its SQL catalog records what was backed up. Its restore function can return files from the current backup or from one taken before a chosen date and time. Keep the job logs and restore records from periodic emergency-mode drills, since they show that ePHI can be reached while primary systems are down. Bareos is licensed under AGPL-3.0-only, so confirm with counsel what that license requires if you modify and distribute it.

restic check runs

The restic check command verifies the structure of snapshots, trees and pack files. With the read-data or read-data-subset option, it reads pack files back to confirm the stored data has not been modified. Schedule these checks and retain their output as evidence that backed-up ePHI is intact before anyone relies on it during an emergency. A passing check does not prove that a restore into a working environment will succeed, so pair it with restore tests.

Grafana Alerting across metrics and logs

Grafana Alerting builds rules from queries across several data sources, so one rule can combine metric and log signals. During an incident, this lets the team see degraded services and related log events in a single view and act on them. Document who receives each alert, the escalation path and the runbook it links to. Grafana is licensed under AGPL-3.0-only, so review the license terms before modifying or distributing it.

Prometheus service health metrics

Prometheus collects metrics over HTTP using a pull model and stores them as time series on local storage, queried with PromQL. Its records show which critical services stayed available and how performance changed during degraded operation, which is the evidence an assessor would ask for when reviewing the plan. Prometheus stores data on local disk, so decide how long history is kept and whether the monitoring server itself is covered by your contingency plan.

Who writes, operates and assesses the emergency mode plan

Your organization owns the emergency mode operation plan under 45 CFR 164.308(a)(7)(ii)(C). The Security Rule places the duty on the covered entity or business associate, so the plan must be written around your own critical business processes, your own clinical workflows and your own risk decisions. The security official, usually designated under 164.308(a)(2), coordinates the work, but operational leaders must define what "critical" means for their services.

Plan ownership: One named owner maintains the plan, schedules reviews and records changes after each drill or real event.
Emergency access approval: Leaders decide who may use break-glass or emergency access to ePHI, under what conditions, and how that access is logged and reviewed. This links to the technical emergency access procedure in 164.312(a)(2)(ii).
Clinical sign-off: Clinical and operational leaders confirm that the reduced workflows keep patient care safe while systems are degraded.
Facility coordination: Facilities staff confirm how physical access supports emergency operations under 164.310(a)(2)(i).
Drill participation: Workforce members who run the processes take part in drills and report gaps.

Ask your leadership to confirm which of these decisions sit with named individuals and how sign-off is recorded.

Where emergency mode plans usually fail and how to close each gap

Emergency mode plans tend to fail in predictable places: they copy recovery steps instead of describing operations, they leave emergency access and facility access undocumented, and they are never tested against current systems. Each card names one gap, the fix that closes it, and the evidence an assessor would look for under 164.308(a)(7)(ii)(C).

Recovery steps instead of operations

Many plans list how to restore servers and databases, which belongs in the disaster recovery plan under 164.308(a)(7)(ii)(B). The emergency mode plan must describe how critical processes keep running while the event is still underway, such as manual intake, paper or downtime workflows, and who decides to switch. Check that each critical process has a documented operating procedure that states the safeguards still in force during the emergency, not only the steps to recover afterward. Evidence: a per-process operating procedure signed by the process owner.

Emergency access without logging

During an outage, staff often use shared or break-glass accounts to reach ePHI, and nothing records who did what. The technical emergency access procedure in 164.312(a)(2)(ii) requires a way to obtain necessary ePHI in an emergency, so the emergency mode plan should name the accounts, the approver and the review that follows. Fix this by pre-approving break-glass roles, logging every use to a system that staff cannot edit, and reviewing the log after the event. Evidence: the approval record, the access log and the post-event review.

Undocumented facility access

Emergencies often require people to enter buildings or data rooms outside normal hours, and the plan rarely says who may do so. The facility contingency operations specification in 164.310(a)(2)(i) supports facility access for the emergency mode plan, so the plan should name the roles, the entry method and how entries are recorded. Confirm that badge or key procedures for emergency entry are written, that a log captures each entry, and that the list of authorized responders is current. Evidence: the facility access log and the responder roster.

Third parties without emergency duties

Cloud hosts, managed IT providers and billing vendors frequently hold a critical part of a process, yet their contracts cover only normal service levels. A business associate arrangement under 164.308(b)(1) should state what the vendor must do to keep the process running in an emergency, including contact paths and who authorizes their staff to access ePHI. Ask each critical vendor for its own continuity commitments and confirm they match what your plan assumes. Evidence: the contract clauses or written arrangements that assign emergency duties.

Plans that are never exercised

A plan that has never been run tends to fail on its first real use, because manual workflows, contact lists and access steps have not been checked. The testing and revision procedures in 164.308(a)(7)(ii)(D) are addressable, but an untested emergency mode plan is hard to defend as reasonable. Run a tabletop exercise that switches a critical process into emergency operation, then record what broke and update the plan. Evidence: the exercise scenario, attendee list, findings and the revised plan version.

Critical process lists that predate current systems

The list of critical processes often reflects the systems that existed when the plan was written. New applications, cloud services or integrations may now carry ePHI without appearing in the plan at all. Tie the list to the applications and data criticality analysis under 164.308(a)(7)(ii)(E), and refresh it after material system changes. Confirm that every system holding ePHI maps to a process with an emergency procedure. Evidence: the dated criticality analysis and the mapping from systems to processes.

Questions buyers ask about the emergency mode operation plan

Can we write the emergency mode operation plan in-house?

Yes. The Security Rule does not require outside help to write this plan, and the organization owns it. The plan has to describe which critical business processes must keep running during an emergency, who runs them, which systems and ePHI those processes need, and how security is maintained while the organization operates in emergency mode. Staff who know the clinical, billing and operational workflows usually provide the content, while the security official checks that protections such as access controls and audit logging still apply in degraded conditions. An in-house team with that knowledge can produce a usable draft. Outside help is most useful when the team lacks the time, lacks someone who can map dependencies across systems, or needs an independent reviewer before the plan is adopted.

How much effort does the emergency mode plan take, and what drives it?

Effort depends mainly on how many critical processes the organization runs, how many systems each one depends on, and how well those dependencies are already documented. The work usually includes listing critical processes, identifying the applications and data each needs (the applications and data criticality analysis under 164.308(a)(7)(ii)(E) feeds this directly), defining what must remain protected in emergency mode, and writing procedures staff can follow under pressure. Organizations with a current risk analysis and criticality inventory generally have less to do. Organizations with many hospitals, sites or legacy systems, or with cloud and on-premises services that depend on each other, have more. Ask any consultant or partner to break the quote into discovery, drafting, review and testing so you can see which parts scale with system count.

How long does it take to build an emergency mode operation plan?

The timeline depends on drivers rather than a fixed duration, and no supplied fact gives a standard figure. The main factors are the number of critical processes in scope, whether the criticality analysis already exists, how many departments must approve procedures, and whether the plan must be tested before it is considered complete. Dependencies on third-party platforms add time because their emergency arrangements must be confirmed, and facility arrangements that rely on the contingency operations specification in 164.310(a)(2)(i) need coordination with facilities staff. Ask any provider to state the milestones, the approvals required from clinical and executive owners, and the dates on which testing will occur, so the schedule reflects your governance rather than an assumed pace.

What does the work require from our own staff?

The work needs sustained input from people who know how operations actually run, not only from IT. Clinical or operational leaders must confirm which processes are critical and how much degradation is tolerable. System owners must document dependencies, access paths and manual alternatives. The security official must confirm that emergency access procedures under 164.312(a)(2)(ii), which cover obtaining necessary ePHI during an emergency, and the protections around them are defined and reviewed. Finally, staff who will execute the plan must be able to review procedures and attend exercises. Plan for scheduled working sessions with each of these owners, and confirm before work starts who will sign off on the final document.

Does a tabletop exercise satisfy the emergency mode requirement?

A tabletop exercise is evidence that the plan has been tested, but it does not on its own establish that the requirement is met. The Security Rule requires the organization to establish and implement procedures, so the evidence should show the plan exists, has been approved, and is understood by the people who run it. A tabletop can reveal gaps in decision-making and communication, and its findings should feed back into the plan. Technical checks add weight, such as confirming that backup data can be read and restored, that alerting still reaches responders during degraded conditions, or that emergency access accounts work. Whether a given exercise is sufficient is a judgment for the organization and, when it is assessed, for the independent auditor or assessor.

Can an implementation partner make us compliant with this requirement?

A partner can help prepare the plan, systems and evidence, but it cannot make the organization compliant or certify it. The organization owns its safeguards and decides what the plan contains. DeployOpen, for example, can plan, implement and document self-hosted open-source platforms, including backup and monitoring components that support emergency operations, and prepare evidence such as configuration records and test results. Only an independent auditor, assessor or certification body issues reports or attestations. HHS also states that the Security Rule does not require any certification, and that private certifications do not prevent a later finding of violation. Confirm the scope, deliverables and responsibilities in writing before any work begins.

How DeployOpen scopes and prepares emergency mode evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so emergency mode operation can be tested against the systems that hold your ePHI. The organization owns its plan and its controls, DeployOpen prepares the systems and evidence, and an independent assessor reviews them.

How we scope

Written scope names the critical business processes and ePHI systems the emergency mode plan must keep running.
Scope lists which facility, workforce and technical emergency access procedures the plan depends on.
Scope states which systems and data are in and out, and which tasks remain with your security official.

How we build

We configure monitoring and alerting so degraded operation during an incident is visible to responders.
We set up backup and restore tooling so ePHI remains retrievable while primary systems are unavailable.
We document step-by-step runbooks for operating critical processes in emergency mode, with named owners.

How we test

We run exercises that simulate loss of primary systems and record whether critical processes continued.
We capture test results, gaps and corrective actions so the plan can be revised after each exercise.
We confirm that emergency access to ePHI works under the plan and that access is logged for review.

How we hand over

You receive the emergency mode plan, runbooks, test records and configuration documentation in writing.
Handover identifies which evidence your organization must retain and which records an assessor will request.
Your team is trained to run the plan, so operation does not depend on DeployOpen staff being present.