HIPAA backup and disaster recovery requirements, explained

What HIPAA requires for backup and disaster recovery today

When a customer, contract or OCR inquiry asks for backup and disaster recovery evidence, the answer starts with 45 CFR 164.308(a)(7). The current Security Rule requires a data backup plan, a disaster recovery plan and an emergency mode operation plan, and all three are required implementation specifications. It also adds testing and revision procedures and applications and data criticality analysis, both addressable. Appendix A to Subpart C lists these alongside the other contingency plan standards, so an assessor will expect to see each one addressed in writing.

The rule sets no recovery time objective and no numeric backup frequency. What counts as adequate depends on the organization's risk analysis, its criticality analysis and the systems it actually runs. A practice with one scheduling system and a hospital running clinical applications face very different restoration targets, and the criticality analysis is the document that ties each system to its restoration priority. Before answering a customer, confirm which systems hold ePHI, which of them are essential to patient care, and how long the organization can operate without each one. The rule also has no certification, so any claim that a backup vendor or consultant made the organization compliant should be treated with caution.

The organization owns these plans and the decisions behind them, including who approves restoration priorities and how often tests are run and documented. An implementation partner can prepare the backup configuration, restore runbooks, test records and evidence of past restorations. Only an independent assessor can report on whether the controls work as described. Before engaging anyone, ask who will hold the criticality analysis and test results, and confirm that the plans name owners for each system.

Which contingency specifications are required and which are addressable

The contingency plan standard in 45 CFR 164.308(a)(7) contains five implementation specifications. Three are required, so every covered entity and business associate must have them, while two are addressable, so the organization must document its reasoning and any equivalent alternative.

Retrievable exact copies (required)

This required specification asks for procedures to create and maintain retrievable exact copies of electronic protected health information. The copies must be complete and restorable, not just a snapshot of file lists. Check that backup scope covers every system holding ePHI, that copies are encrypted and access-controlled, and that at least one copy is kept offline or otherwise isolated from the network, as HHS ransomware guidance advises. An assessor will ask for the backup policy, job schedules, backup logs and sample restore results.

Restoring any loss of data (required)

This required specification requires written procedures to restore data after a loss, whether from ransomware, hardware failure, deletion or a faulty change. The procedures should name who authorizes a restore, the order in which systems come back and how restored data is verified against the last good copy. Check that restore steps have been performed, not only written. Assessors typically ask for the restore procedure, the record of the most recent test restore and the corrective actions from any real recovery.

Emergency mode operation (required)

This required specification asks for procedures to keep critical business processes protecting ePHI running while the organization operates in emergency mode. The plan should list which functions continue during an outage, how access controls and audit logging work on backup systems, and who can invoke emergency access. Check that emergency access does not weaken safeguards silently. Assessors usually ask for the emergency mode operation plan, its list of critical processes and evidence that staff know how to invoke it.

Periodic testing and revision (addressable)

This addressable specification calls for periodic testing and revision of contingency plans. Addressable means the organization must decide whether the measure is reasonable and appropriate. If it is not, it must document why and adopt an equivalent alternative measure, as 45 CFR 164.306(d) describes. Testing could be tabletop exercises, partial restores or full failover tests, and the scope and frequency should be documented with the reasoning. Assessors will ask for test plans, results, and the plan revisions that followed each test.

Applications and data criticality analysis (addressable)

This addressable specification requires assessing the relative criticality of specific applications and data to the other contingency plan components. The analysis sets the restore priority and drives recovery expectations for each system. Document each system, its ePHI, its dependencies and its business impact, then set restore order from that ranking. If the organization decides a formal analysis is not reasonable, it must record that decision and an equivalent method. Assessors will ask for the criticality inventory and how it feeds the backup and recovery plans.

How a contingency plan gets built, tested and kept current

The sequence turns the risk analysis into a contingency plan that names what must be recovered, how, and in what order, then proves it works through testing and keeps it accurate as systems change. Each phase produces a record that an assessor or OCR investigator can ask to see.

Start from the risk analysis
Confirm the scope of the contingency plan against the existing risk analysis before drafting anything. The risk analysis identifies where ePHI lives and which threats could cause loss or unavailability, and the contingency plan responds to those findings. The organization's security official and leadership own this scope, and an implementation partner usually prepares the working inventory and gap notes for their review. The step is done when the scope statement names the systems and threats it covers and links each one to a risk entry.
Inventory systems and data holding ePHI
Build a system and data inventory listing every application, database, file share, endpoint, backup repository and third-party service that creates, stores, processes or transmits ePHI. For each entry, record the owner, hosting location, data types and who depends on it. Cloud accounts, data center hardware and business associate platforms all belong in the list. The output is the inventory, reviewed by system owners and signed off by the organization. Ask the partner to show how the inventory was reconciled against the risk analysis, since gaps here carry into every later phase.
Rank applications and data by criticality
Perform the applications and data criticality analysis, which the Security Rule treats as addressable. Rank each system by how much the organization's patient care, billing and other critical business processes depend on it, and by how quickly its loss would cause harm. The ranking sets the order of restoration and the depth of backup for each tier. Record the method and the reasons for every ranking, because the proposed rule would tie restoration timing to this analysis. The output is a ranked criticality analysis approved by clinical and operational leaders.
Write backup and recovery procedures by tier
Draft the data backup plan and the disaster recovery plan, with separate backup and recovery procedures for each criticality tier. Each procedure states what is copied, how often, where the copy is stored, how it is protected, who can restore it and how a loss of data is restored to a known point. Include guidance on keeping at least one set of backups offline and unavailable from the network, as HHS's ransomware fact sheet advises. The output is a set of tiered procedures that system owners can follow without the author present, approved by the security official.
Define emergency mode operation for critical processes
Write the emergency mode operation procedure, which explains how critical business processes continue while systems are down, and how the protection of ePHI is maintained during that period. Cover manual or downtime workflows, access to paper or cached records, who may authorize emergency access, and how data entered during downtime is reconciled once systems return. Walk through the procedure with the department leads who will run it. The output is an approved procedure and a list of the trained staff who must be able to follow it.
Test restores and record the results
Run the first full recovery test against the tiered procedures, restoring representative systems from backup within a controlled environment and checking the data for completeness and integrity. Record what was restored, the time taken, who performed each step, what failed and what was corrected. Test emergency mode operation at the same time where practical. The test record lists results and gaps with an owner and a due date for each gap. Confirm with the partner and the organization whether the test environment reflects production closely enough for the results to be relied upon.
Revise the plan and keep a revision log
Update the contingency plan to close the gaps found in testing, then schedule periodic testing and revision as the Security Rule requires. Trigger an unscheduled review when a major system changes, when a business associate changes its hosting, after a real incident, or when the risk analysis is updated. Each revision is logged with the date, the reason, the author, the approver and the sections changed. The revision log and the superseded versions give an assessor evidence that the plan is maintained rather than written once. Confirm the review cadence with the security official and document it in the policies.

Which backup and recovery design fits your ePHI systems

This table compares four backup designs for ePHI systems: production-only copies, copies kept offline, cloud backup under a business associate agreement, and self-hosted backup in your own infrastructure. Read each row against your own threat model, and use the confirm column to ask vendors where copies live and who can delete them. No single design is named as sufficient on its own; most programs combine two of them.

Design	When it fits	What it protects against and what it does not	Confirm with the vendor or in your environment
Copies kept only on the production network	Low-stakes systems where a short outage is tolerable and data loss is covered elsewhere	Protects against accidental deletion and hardware failure. Does not protect against ransomware, since HHS notes some variants remove or disrupt online backups	Whether backup credentials can reach the copies, and whether snapshots can be deleted by the same account that runs production
Copies kept offline or unavailable from the network	Any ePHI system where restoration after ransomware is required, which covers most covered entities and business associates	Aligns with HHS ransomware advice to keep backups offline and unavailable from the network. Restore speed depends on how fast copies can be brought back into service	How media is detached, who controls the detachment, and how often a test restoration is run from these copies
Cloud-hosted backup under a business associate agreement	Organizations that want managed storage and geographic separation and can sign a business associate agreement with the provider	Separates copies from the production network. Protection depends on provider account controls, since a compromised administrator could affect both production and backup	Whether the provider signs a business associate agreement, where copies are stored, whether immutability or object lock is available, and who can delete or shorten retention
Self-hosted backup inside your own infrastructure	Organizations with the staff to run storage, network segmentation and restoration testing, or with data residency needs	Gives direct control over isolation, access and restore testing. Protects only as well as the segmentation and administrator separation you build and document	Which accounts can write, modify or delete copies, whether copies are isolated from the production directory, and how restores are tested and logged
Immutable or write-once copies, in any location	Systems where an attacker with admin rights must not be able to erase recent copies	Helps keep at least one recoverable copy after credential theft. Does not replace testing, because an immutable copy that cannot be restored is of limited use	Whether immutability is enforced by the storage platform, how the retention lock is set, and who holds the keys that could remove it
Restoration testing from any design	Every design, because the Security Rule expects periodic testing and revision of the contingency plan	Shows whether copies are complete and usable. An untested design has unknown recovery behavior	Test scope, the systems included, the evidence produced, and whether results feed the contingency plan revision

What makes backup and DR work larger for one organization than another

The contingency plan specifications apply to every organization, but the effort behind them scales with how much ePHI exists, where it lives and who else touches it. The six drivers below determine how large the backup and disaster recovery program becomes, and each one can be narrowed with decisions made early.

Number and type of ePHI systems

Each system that creates, stores or transmits ePHI needs a retrievable exact copy plan, a restore procedure and a place in the criticality analysis. An EHR, a PACS, a billing database and a shared file server each carry different data shapes and restore steps. Inventory them from the risk analysis, not from memory, and group systems that share a backup method so the procedures stay maintainable.

Sites and cloud accounts holding ePHI

Every data center, clinic, cloud account, subscription and backup repository that holds ePHI widens the backup plan and the emergency mode plan. Ask which accounts were created for pilots or old projects and still hold copies. Consolidating accounts or retiring unused copies before the plan is written usually reduces the procedures you must maintain and test.

Third parties that host or process ePHI

Hosting providers, managed IT firms and backup vendors that handle ePHI for you must sign business associate terms, and their own contingency arrangements affect your recovery time. Confirm in writing what each vendor backs up, where copies sit, how restores are requested and whether they will take part in your tests. A vendor without signed terms is a gap to close before any data moves.

Maturity of existing backup logs

Backup job logs, retention settings and past restore records show whether the plan can prove it works. Organizations with complete logs can show that retrievable copies were created on schedule. Those without logs must first build reporting for failed and successful jobs, because an auditor will ask for evidence of past operation, not only a written policy. Check whether logs are protected from the same accounts that run backups.

Systems ranked as critical

The applications and data criticality analysis determines which systems must be restored first and which can wait. Every system added to the critical list needs a tested restore path and documented dependencies. Work with the business owners of clinical and revenue systems to agree which systems truly stop care or billing when down. A shorter, defensible critical list is easier to test and to explain than one that includes everything.

Test windows without disrupting clinical work

Periodic testing and revision of contingency plans must happen often enough to be credible, but restore tests can consume bandwidth, storage and staff time that clinical operations need. Schedule tests against a calendar of clinical peaks, use isolated restore environments where possible and reuse runbooks from prior incidents. Confirm with clinical leaders which windows are acceptable before committing to a test cadence.

What the proposed 72-hour restore rule would change

The HHS proposed rule published on January 6, 2025 (90 FR 898) would replace the current contingency planning standard's open-ended wording with a concrete target: restore critical relevant electronic information systems and data within 72 hours of loss, and restore other systems according to the applications and data criticality analysis. Today the Security Rule sets no recovery time objective at all. The contingency plan specifications require procedures to restore lost data, but they leave the speed of recovery to the covered entity or business associate. As of October 2026 the rule was not final, and the latest Unified Agenda entry for RIN 0945-AA22 lists final action as projected for July 2027. Treat that date as a schedule that can move, not a commitment.

The 72-hour figure is a proposal, so use it as a planning assumption rather than a settled requirement. Before any budget is committed, check the current status of RIN 0945-AA22 on reginfo.gov and confirm whether the text has changed since publication in the Federal Register proposed rule. Then ask a practical question of your own environment: could your current backup repositories, restore runbooks and recovery hardware bring the systems you would classify as critical back into service within that window, and has anyone timed a full restore recently?

The criticality analysis decides which systems fall into the 72-hour group, so it is the document to prioritize. An illustrative example: a practice might place its electronic health record, its scheduling database and its imaging archive in the critical group, while a training server and an archived reporting system fall into a longer recovery tier. Each system placed in the group needs a documented owner, a recovery procedure, and a tested restore path that does not depend on the failed environment. Keep the analysis current, because a system added after the last review may silently inherit a weaker recovery commitment.

Who owns the plan, who prepares the evidence, and who reports on it

Your organization owns the contingency plan under 45 CFR 164.308(a)(7). The Security Rule places responsibility on the covered entity or business associate, not on a vendor, so the decisions about what data matters most, how much loss is tolerable and who acts during an outage stay with your staff. The security official is accountable for the plan even when technical work is delegated.

Plan ownership: Your team writes and approves the data backup plan, disaster recovery plan and emergency mode operation plan, and keeps them current as systems change.
Criticality ranking: Your leaders decide the relative criticality of applications and data, using business input from clinical, billing and operations owners.
Test sign-off: Your staff schedules, runs or witnesses periodic restore tests and signs the results, including the failures and the revisions that followed.
Accountability: The security official tracks open findings from tests and drills and reports them to leadership.
Vendor oversight: Your team reviews any partner's work product and confirms that the records match what actually happened.

Before engaging anyone, confirm internally who holds each of these decisions and who can approve changes to recovery priorities.

What to have in place before an OCR inquiry or customer assessment

An OCR investigation or customer assessment usually starts with documents, not interviews. The cards below cover the artifacts that show your contingency planning is real, current and tested, and each one names how to check it internally before an assessor asks.

Current system and data inventory

Start with a list of every system that creates, stores or transmits ePHI, including cloud services, backup targets and endpoints, and tie each entry to the risk analysis. The contingency plan is only as complete as this inventory, so an assessor will compare the two documents. Check internally by picking three systems at random and confirming each appears in the risk analysis with an owner and a data location. Evidence requested: the inventory, its last update date and the matching risk analysis entries.

Written criticality analysis with owners

The relative criticality of applications and data is an addressable specification that feeds every other contingency decision. Record which systems must return first, who owns each one, and what business process depends on it. Check internally by asking each named owner to state the recovery order for their system without looking at the document. Evidence requested: the signed criticality analysis, owner names and the date of the last review.

Backup procedures and separated copies

Document how retrievable exact copies of ePHI are created, how often, and where they are kept. HHS ransomware guidance recommends keeping backups offline and unavailable from the network because some variants remove or disrupt online backups. Check internally by confirming at least one copy cannot be reached with production credentials. Evidence requested: backup schedules, job logs, the separation design and access lists for backup storage.

Dated restoration test results

Periodic testing is a required part of the contingency plan, and a plan that has never restored data is hard to defend. Run a restoration of a representative system, record the start and finish times, what was recovered, and what failed. Check internally by confirming the test record names the backup used and the person who verified the data. Evidence requested: the test report, its date, findings and the corrective actions opened from it.

Emergency mode operation procedure

Document which critical business processes continue while systems protecting ePHI are degraded, and how access controls and audit logging stay in force during that time. Clinical and billing teams need to know what they can do without the primary system. Check internally by walking through one critical process with the people who would run it and noting any step that depends on the failed system. Evidence requested: the emergency mode procedure, the list of covered processes and any drill records.

Plan revision history

The contingency plan must be reviewed and revised as systems change, so the document should show when it was last changed and why. A revision history links each update to a trigger such as a new system, a test finding or a change in owner. Check internally by comparing the revision dates with your last infrastructure change and last restoration test. Evidence requested: the version log, approval records and the reason recorded for each revision.

Common questions about HIPAA backup and disaster recovery

Does HIPAA set a specific recovery time for restoring ePHI?

No. The current Security Rule does not set a recovery time objective. It requires procedures to restore any loss of data (45 CFR 164.308(a)(7)(ii)(B)) and to continue critical business processes in emergency mode, but it leaves the speed of recovery to the organization's own risk analysis and contingency planning. The January 2025 proposed rule would add a specific expectation: restoring critical relevant electronic information systems and data within 72 hours of loss, with other systems restored according to the criticality analysis. That change was not final as of October 2026, so the current rule should not be read as containing a 72-hour requirement. Ask your compliance lead to document the recovery targets you choose and the reasoning behind them.

Does HIPAA require offline backups?

The rule does not use the word offline. It requires procedures to create and maintain retrievable exact copies of ePHI, which is a required implementation specification. HHS's ransomware fact sheet recommends frequent backups with periodic test restorations and suggests keeping backups offline and unavailable from the network, because some ransomware variants remove or disrupt online backups. Treat offline or logically isolated copies as the HHS-recommended practice and decide, through your risk analysis, how to protect copies from deletion or encryption by an attacker. Confirm the exact design with your own security team and, where needed, counsel.

How often must restore tests run under HIPAA?

The rule requires periodic testing and revision of contingency plans (45 CFR 164.308(a)(7)(ii)(D)), but it does not set a fixed interval. Your organization sets the frequency through its risk analysis, taking into account how fast systems change, how much ePHI could be lost, and what prior tests found. Document the schedule, the scope of each test, the results and the changes made afterward. Assessors look for evidence that tests happened on the schedule you chose and that failures led to plan updates, so a schedule you never follow is a finding in its own right.

Can we estimate the cost of HIPAA backup and disaster recovery before scoping?

Not with a meaningful number. The main cost drivers are the volume and location of ePHI, the number of systems that hold it, the backup and recovery technology already in place, how quickly you choose to restore each system, the frequency and depth of restore tests, and whether recovery must run in your own data center, a second site or a cloud account. Staff time for the risk analysis, runbooks and drills is often a larger part of the effort than software. Costs recur for storage, replication, monitoring and periodic testing. DeployOpen does not publish a price list. A quote follows from a written scope that names the systems, recovery targets, environments and deliverables, so ask any provider for that scope first.

Can our own team implement HIPAA backup and disaster recovery without outside help?

Often yes, if you have staff who can run backups, restore systems, document procedures and test them. The Security Rule does not require outside help, and the contingency plan is the organization's responsibility. Common gaps are an incomplete inventory of where ePHI lives, backups that are never restored, no defined criticality ranking, and plans that depend on one person. An implementation partner can prepare systems, runbooks and evidence, but the organization still owns its controls and decisions. Use a written checklist of the work to decide which parts your team can carry and which need outside skills.

What does the work need from our staff?

It needs named owners and time from people who know the systems. Typically this includes a security or compliance lead who owns the contingency plan and risk analysis, system administrators who know backup configuration and restore steps, application owners who can define which data and functions matter most, and leadership who approve recovery targets and accept residual risk. Expect each group to take part in the criticality analysis, plan review and at least some restore tests. Keep a record of who did what, because assessors and OCR investigators often ask for proof of participation as well as the plan itself.

Can a third-party assessment certify that our backup and DR meets HIPAA?

No. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, that HHS does not endorse or recognize private certifications, and that such certifications do not prevent HHS from later finding a violation. A third-party assessment can test your controls against the rule and report findings, and an independent assessor can give you an opinion on what it observed. It cannot make you compliant or issue a HIPAA certificate. Ask any assessor exactly what the deliverable is and what it does not cover before you buy it.

How does the proposed 72-hour restore requirement change our planning now?

Because the rule is not final, you are not required to meet a 72-hour target today, but planning for it is a sensible step. Identify which systems and data would count as critical relevant electronic information systems, measure how long their restores take in your environment, and note the gaps. Record these results in your risk analysis and contingency plan so you can show your reasoning if the rule takes effect. Monitor the rulemaking through the Federal Register and the Unified Agenda entry for RIN 0945-AA22, and have counsel confirm what applies to you at each stage.

How DeployOpen scopes backup and DR work and hands over the evidence

DeployOpen plans, implements and documents backup and disaster recovery for self-hosted open-source platforms inside your own infrastructure. We prepare the systems and records that support your contingency plan, while your organization owns the policy, the risk decisions and the final compliance position.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
We list which ePHI systems and data sets fall under the backup and recovery scope, drawn from your criticality analysis.
The written scope names the recovery targets you set and the test restorations DeployOpen will perform and record.

How we build

We configure retrievable copies of ePHI in your own accounts or data centers, with copy frequency and retention set in the plan.
We design offline or logically separated backup copies so that a network-level compromise cannot reach every copy.
We set up emergency mode procedures for the systems that must keep running, and document the dependencies behind them.

How we hand over

You receive the backup and disaster recovery plan, runbooks and restoration procedures written for your environment.
Test restoration results, dates, scope and any gaps are recorded so your team and assessors can review them.
Your security official and auditors receive the evidence package, which your organization reviews and accepts before reliance.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement closes.
Retainer work can include periodic test restorations and revision of the plan when systems or the proposed rule change.
Ask us to confirm in writing which parts of the plan remain your responsibility and which we operate.