On a Tuesday morning in late 2023, a community hospital in the Midwest lost access to its electronic health records. Not a slowdown, access was gone. Ransomware had moved laterally from an administrative workstation into clinical systems overnight. Within hours, the ED was running on paper. Surgeries were postponed. Pharmacy orders were being verified manually. Staff were doing the job they trained for, just without the tools they depend on.

The hospital had backups. What they did not have was a tested, documented ability to restore from those backups within a defined timeframe. It took them nine days to return to full operations. Nine days.

That scenario, and dozens like it, are precisely what the new HIPAA Security Rule final rule is responding to with one of its most operationally significant requirements: healthcare organizations must now demonstrate a 72-hour recovery capability for critical ePHI systems. And it must be proven that you can do it in practice.

Why backups and recovery are not the same thing

Most healthcare organizations have backups. Far fewer have recovery programs.

The distinction matters. A backup is a copy of data. Recovery is the ability to restore that data to a known-good state across interdependent systems, under pressure, within a defined window, and to prove you can do it before a crisis forces the test.

A 2023 Ponemon Institute study found that healthcare organizations take an average of 21 days to fully restore systems after a ransomware attack. The new HIPAA rule sets the bar at 72 hours for critical systems. For many organizations, this is a major adjustment, and it requires a fundamental rethink of how backup infrastructure, recovery runbooks, and tabletop exercises are approached.

The gap is usually not the backup technology. Azure Backup, for example, gives healthcare organizations running Microsoft 365 robust tools for point-in-time recovery across cloud and hybrid workloads. The gap is almost always the plan around it: what gets restored first, in what order, by whom, and how that sequence has actually been tested.

What the 72-hour requirement actually asks for

The final rule does not simply require that you have a disaster recovery plan. It requires that your BCP/DR documentation reflect your current environment and that recovery capability has been validated through testing, not just asserted in a document.

That means three things need to be true simultaneously:

1. Your recovery infrastructure has to work. Azure Backup configurations, Azure Site Recovery settings, and replication jobs need to be actively monitored and periodically tested, not set-and-forgotten.
2. Your runbooks have to be current. A recovery playbook that references systems, network configurations, or vendors from three years ago is not a recovery playbook; it is a liability. Clinical environments change. The documentation has to keep pace.
3. Your team has to have practiced it. Tabletop exercises that walk through a realistic incident scenario, AKA ransomware, not a theoretical "system outage", reveal the gaps that documentation alone cannot surface. Who makes the call to invoke DR? Who has the credentials to restore from backup? What happens when the primary IT contact is unavailable?

Clinical downtime is a patient safety issue

The operational framing of the 72-hour rule matters, but so does the clinical one. A 2021 study published in the Journal of the American Medical Association found statistically significant increases in in-hospital mortality at hospitals that diverted patients during cyberattacks. Downtime is not an IT problem. It affects care delivery in ways that are measurable.

Healthcare organizations operate differently from other industries because the consequences of prolonged system unavailability are different. The 72-hour requirement reflects that reality, and organizations that treat it as a compliance checkbox rather than an operational standard are missing the point.

Where to start

The most productive first step is a BCP/DR assessment that evaluates your current recovery posture against the 72-hour requirement at the technical level. What are your actual recovery time objectives for EHR, imaging, pharmacy, and scheduling systems? Have those RTOs been tested? What would it take to close the gap?

RELATED READ Stop Paying for Security Twice: Operationalizing the MSFT Security Stack

For organizations running Microsoft 365 and Azure, many of the technical building blocks are already in place. The work is in configuration, validation, and documentation.

The HIPAA Security Rule final rule is here, and the clock is running. Download our practical guide, built specifically for healthcare organizations using Microsoft 365, for a compliance readiness checklist, real-world examples, and a quarter-by-quarter action plan through the deadline.

Find the content useful? Subscribe to The Catch, our exclusive weekly LinkedIn newsletter focused on real-life experiences doing cyber right in the most highly regulated industries.