HIPAA Disaster Recovery Testing Requirements Explained

Most healthcare organizations have backups. Far fewer can answer three questions on the spot: when did we last fail over, how long did it take, and where is the report?

That gap is what HIPAA disaster recovery testing requirements are really about. A backup that has never been restored under test conditions is an assumption, not a control. This post walks through what the Security Rule expects today, what the January 2025 proposed update would add, what a real test of an EHR or imaging system looks like, and how automated test failover makes a regular cadence realistic for a small IT team.

Does HIPAA require disaster recovery testing?

Yes — in substance. The contingency plan standard at 45 CFR 164.308(a)(7) includes a “Testing and Revision Procedures” implementation specification. Historically that specification has been classified as addressable, which is where a lot of organizations get it wrong.

Addressable does not mean optional. It means you must assess whether the specification is reasonable and appropriate for your environment, then either implement it or document an equivalent alternative and why you chose it. “We never got around to it” is not one of the two acceptable outcomes.

One more point worth stating plainly: the compliance obligation sits with the covered entity. If a service provider runs your backups, that provider is accountable to you under contract, but HIPAA still looks to you for the contingency plan, the testing, and the documentation.

How often does HIPAA require you to test your disaster recovery plan?

Today, HIPAA does not name a frequency. The Security Rule calls for periodic testing and revision of contingency plans without specifying an interval, so anyone telling you “HIPAA requires annual DR testing” is describing industry practice or a proposal, not current text.

Guidance from compliance software vendor Medcurity suggests testing a HIPAA disaster recovery plan at least annually, running tabletop exercises quarterly, and re-testing after significant infrastructure change such as an EHR or cloud migration. That is a sensible baseline, and it maps well to how audits and insurance questionnaires are actually written.

The change-triggered re-test is the one people skip. If you migrated your EHR, added an imaging system, or moved a workload to a new cloud provider since your last test, your documented recovery procedure describes an environment that no longer exists.

What would the 2025 proposed HIPAA Security Rule change?

OCR issued a Notice of Proposed Rulemaking on January 6, 2025 that would tighten contingency planning considerably. Per law firm summaries of the NPRM:

• Regulated entities would have to establish security incident response plans and implement procedures for testing and revising them at least once every 12 months (Covington).
• Covered entities would have to test the contingency plan annually and perform a criticality analysis documenting the relative criticality of systems and data to set restoration priority (Faegre Drinker).
• Contingency plans would need written procedures to restore critical systems and data within 72 hours of an incident (Taft Law and RSI Security).
• Broader proposed changes include removing the addressable/required distinction, elevating encryption of ePHI at rest and in transit to required, requiring MFA, vulnerability scanning at least every six months, and annual penetration testing (Accountable HQ).

Important caveat: this is a proposed rule. It is not current law, and none of the above is binding unless and until it is finalized. Confirm the rule’s status before you build a compliance plan around it.

What does the 72-hour restoration expectation mean in practice?

It means you would have to design against a clock, not a hope. A 72-hour target for critical systems forces two decisions most healthcare organizations have deferred.

First, criticality. Which systems are “critical”? EHR database, EHR application server, the lab or HL7 interface engine, PACS, DNS, badge and printing services, phones. They do not all carry the same urgency, and the proposed criticality analysis is essentially a requirement to write that ranking down.

Second, measurement. You cannot know whether you can restore an EHR in 72 hours unless you have restored one. The test produces the number. Everything else is an estimate.

Is a backup the same as a disaster recovery plan under HIPAA?

No. A backup is a copy of data. Disaster recovery is the documented, tested ability to bring services back in a defined order, within a defined window, using known people and known steps.

The gap between the two is where clinics get hurt: the backups exist, but nobody has ever booted the EHR from them, nobody knows the sequence, and the person who did know is no longer on the team.

Can you test failover without disrupting production systems?

Yes, and this is the objection that kills most DR test programs before they start. Clinics assume a test means downtime, so the test gets scheduled for “after the busy season,” which never arrives.

Isolated test failover is designed to address that. It is meant to run recovery workloads in an isolated network so production is not touched, which gives you a window to validate boot, application launch, database connectivity, and login. Acronis states that with its Disaster Recovery service you can perform scheduled test failover for any server on a monthly basis, and describes test failover as simplified and automated.

How does Acronis test failover work?

Acronis positions test failover as part of its Disaster Recovery capability, with orchestration handled by runbooks. Per Acronis’ help documentation, runbooks are predefined instruction sets that automate spinning up a production environment in the cloud, can automatically verify failover success by pinging server IP addresses and checking specified port connections, and can define the sequence of operations for servers running distributed applications.

That last item matters in healthcare. An EHR is rarely one server — it is a database, an application tier, an interface engine, and dependencies like DNS and printing that have to come up in order. A runbook turns that tribal knowledge into a sequence anyone on call can execute.

Acronis’ Advanced Disaster Recovery data sheet (dated 2022) states the service can achieve RPOs and RTOs of less than 15 minutes using the Acronis RunVM engine, and lists test failover, production and test failover to the Acronis Cloud, multiple runbook templates, and failover to a malware-free recovery point among its capabilities. Those are vendor-stated capabilities under specific configurations and licensing tiers — treat them as a starting point for scoping, not as a guaranteed outcome, and confirm current figures against current Acronis documentation.

Acronis has also released a public API for Acronis Disaster Recovery that lets management tooling automate DR testing and failover, retrieve failover readiness status, manage RTOs and RPOs per server, and run test failovers. That is what makes “tested on a schedule, reported automatically” possible instead of aspirational.

Two scoping notes before anyone assumes this is turned on already. Several of these features depend on the Advanced Disaster Recovery add-on rather than base Acronis Cyber Protect Cloud. And Acronis’ help documentation notes real constraints: a recovery server must be created in advance, failover is only possible from recovery points created after the recovery server was created, and the maximum number of supported recovery points is 100.

Why does a clean restore matter more than a successful restore?

Because in a ransomware scenario the question is not only whether the restore works — it is whether the recovery point is clean. Failing over into re-encrypted or already-compromised data is a successful technical restore and a failed recovery.

This is why Acronis lists failover to a malware-free recovery point as a capability, and why your test procedure should validate recovery point integrity, not just that a VM boots.

What documentation do you need after a disaster recovery test?

Auditors, and increasingly cyber insurers, ask for evidence rather than intent. Keep a short, date-stamped record for every test that captures:

• Date of the test and who ran it
• Scope: which systems, which recovery points, production or isolated test failover
• RTO and RPO actually achieved, versus target
• What failed or behaved unexpectedly
• Remediation actions, owners, and completion dates
• The trigger for the next test, including change-driven re-tests

That record is the deliverable. A plan document with no test log behind it tells an auditor that the control was written, not operated.

No product makes an organization HIPAA compliant. Compliance is organizational; tooling supports the controls and produces the evidence.

Where palmiq fits

palmiq is an Acronis Platinum partner, in the top 1% globally, and we build DR programs for clinical environments without a dedicated DR engineer. That usually means defining criticality and recovery order with your clinical and practice leadership, configuring recovery servers and runbooks, running test failovers on a schedule you can defend, and handing you the report. Our 24/7 SOC and 15-minute response SLA on critical issues cover the other half of the equation — the incident that starts the clock.

Start with the self-assessment: can you name the date of your last test failover, the systems it covered, and the recovery time it produced? If any of those three is blank, that is your next project — and it is a small one compared with finding out during an actual outage.

When you want a second set of eyes on it, book a discovery call.

---

Notes for the reviewer (remove before publishing):

• The two runbook and test-failover constraint claims are cited in the research brief to a partner-hosted knowledge base mirror (Libyan Spider), not to Acronis directly. The draft attributes them to “Acronis’ help documentation” — please swap in links to Acronis’ own help docs and confirm the wording before this goes live.
• The annual / quarterly / change-triggered cadence is attributed to Medcurity, which the brief flags as “verify before quoting.” Confirm the page still states that cadence.
• The January 6, 2025 NPRM is framed throughout as proposed. Verify its status (pending, finalized, withdrawn) on the publication date and adjust the caveat if it has changed.
• Confirm the Acronis “less than 15 minutes” RPO/RTO figure against current Acronis product documentation; the source data sheet is dated 2022 and is attributed as such in the draft.