The HIPAA Security Rule proposal’s hardest line was a 72-hour restore

HHS proposed turning HIPAA’s flexible security safeguards into firm requirements. Most were controls hospitals already had or paperwork they could build. One was different: being able to restore key systems within 72 hours, which needed clinical planning, tested capacity and real money.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

Two-minute summaryThe dek and the first sentence of each section, quoted from the article

HHS proposed turning HIPAA’s flexible security safeguards into firm requirements. Most were controls hospitals already had or paperwork they could build. One was different: being able to restore key systems within 72 hours, which needed clinical planning, tested capacity and real money.

  1. The week On December 27, 2024, the HHS Office for Civil Rights announced a proposed rule to modify the HIPAA Security Rule, its first major update since 2013.
  2. Locks, floor plans and fire recovery A health system’s security can be described in terms of a large building.
  3. Controls most systems already had Multi-factor authentication, encryption, anti-malware, patching and access controls were standard in most large health systems by 2024.
  4. Evidence most lacked The second group concerns proof.
  5. Recovery capability few could demonstrate The most demanding element required written procedures to restore relevant systems and data within 72 hours, backed by a criticality analysis and testing.
  6. Obligations reaching into business associates The fourth group addressed the supply chain.
  7. One health system times its own recovery Suppose a regional health system has three hospitals and a network of clinics.
  8. Making the budget case for recovery Of the four groups, recovery is the one that most often stalls at the finance committee.
  9. Patients, money, regulators and the board State rules add to the federal picture for some hospitals.
  10. With hindsight The proposal drew thousands of comments.

The week

On December 27, 2024, the HHS Office for Civil Rights announced a proposed rule to modify the HIPAA Security Rule, its first major update since 2013. The office is the part of the federal health department that enforces patient privacy and security rules. For health system security chiefs, it made unwelcome reading between Christmas and New Year.

Some background helps. HIPAA is the federal law that governs how health care organizations protect patient information. Its Security Rule sets the safeguards that hospitals, clinics, health plans and their contractors must apply to electronic protected health information: any digital record that identifies a patient and relates to their health or care. For two decades the rule had been deliberately flexible. Many of its safeguards were labeled “addressable,” meaning an organization could decide, with a documented reason, that a measure was not reasonable for it and do something else instead.

The proposal had been signaled for a year. In December 2023 HHS published a concept paper on health sector cybersecurity that said it would seek to update the Security Rule. In January 2024 it released voluntary cybersecurity performance goals for health care, split into essential and enhanced practices. Then came 2024 itself. The February ransomware attack on Change Healthcare, a claims and payment clearinghouse, disrupted billing and pharmacy work across the country. In May an attack on Ascension, one of the largest U.S. nonprofit health systems, pushed its hospitals onto paper for weeks.

The notice was published in the Federal Register on January 6, 2025, with comments due by March 7. The proposal would remove the distinction between “required” and “addressable” implementation specifications, making most safeguards mandatory with limited exceptions. A final rule would take effect 60 days after publication, and HHS proposed the standard compliance date of 180 days after that.

The list of specifics was long. It would require encryption of electronic protected health information at rest and in transit, meaning data would be scrambled both while stored and while moving across networks. It would require multi-factor authentication, the familiar second step beyond a password. It would also require a written technology asset inventory and network map, vulnerability scanning at least every six months and penetration testing at least annually. A vulnerability scan is an automated check for known weaknesses; a penetration test hires skilled people to try to break in, as a real attacker would.

Other provisions set clocks. Critical-risk patches would be due within 15 calendar days and high-risk ones within 30. Regulated entities would audit their own compliance with the rule at least once every 12 months and test their contingency plans on the same cycle. They would notify other regulated entities within 24 hours when a workforce member’s access to those entities’ systems or data changed or ended. Backups would have to be no more than 48 hours older than the live data.

Then came the line that would prove hardest. It would also require written procedures to restore critical systems and data within 72 hours of a loss, with other systems restored in the order set by a written criticality analysis.

The proposal reached beyond hospitals too. Business associates, the contractors that handle patient data for health care organizations, would have to verify their technical safeguards to covered entities in writing at least every 12 months. They would also have to report activation of their contingency plans within 24 hours.

HHS made its case in numbers. It said that between 2018 and 2023, reports of breaches of unsecured health information rose by 100 percent and the number of people affected rose by 950 percent, with hacking and ransomware driving the growth. It estimated first-year compliance costs at about $9 billion and recurring costs of about $6 billion a year in years two through five. Those two sets of numbers framed the argument that followed.

The notice also reached group health plans, whose plan documents would require sponsors to apply the rule’s safeguards and to tell the plan when they activated a contingency plan. It closed with dozens of questions for commenters. Among them were whether 72 hours was reasonable for critical systems and whether every system, critical or not, should meet it. The announcement came in the last weeks of an outgoing administration, so any final rule would fall to its successor.

Consider what three days means in a hospital. In 72 hours, an emergency department may see hundreds of patients. Pharmacies dispense thousands of doses. Laboratories run tests whose results decide surgeries. Every one of those activities now depends on computer systems. Ask a hospital chief executive how long it would take to bring all of them back after a ransomware attack, and the honest answer, in many cases, would be: we do not know, and probably a lot longer than three days.

That is why the 72-hour line mattered so much more than its single sentence suggested.

Early reactions focused on cost. Hospital groups argued that small and rural providers could not afford the proposal. Security practitioners noted that much of it codified what well-run organizations already did. Both points were true, and neither helped a health system decide where to start.

Sorting the proposal’s requirements by the kind of effort each demands is more useful. There are four groups, and every requirement falls into one: controls most systems already had, evidence most lacked, recovery capability few could demonstrate, and obligations reaching into business associates. The third group was the hardest by a wide margin.

The proposal would apply to every HIPAA covered entity and business associate, but the four groups land differently across them. A large academic medical center has a security team, a data center and recovery contracts; its problem is scale. A critical access hospital, a rural facility with 25 or fewer inpatient beds, may have an IT department of a few people and depend on a hosted record system. An ambulatory network of physician practices has many small sites, many devices and little central control. A health plan or clearinghouse has fewer clinical constraints and more concentration risk. The sections below note where those differences change the answer.

Locks, floor plans and fire recovery

A health system’s security can be described in terms of a large building.

  • Controls are the locks, alarms and ID badges. Multi-factor authentication is a badge plus a PIN. Encryption is putting valuables in a safe rather than on a desk. Patching is fixing broken windows as soon as they are found.
  • Evidence is the floor plan, the key register and the inspection log. An asset inventory lists every device and application. A network map shows how data moves between them. A risk analysis looks at the whole building and asks where the weak points are.
  • Recovery is what happens after a fire: how fast you can rebuild, which rooms you restore first, and how you keep working in the meantime.
  • Business associates are the contractors who have keys to the building: billing firms, cloud providers, imaging archives and many others.

The proposal touched all four. The trouble is that they are not equally hard. Buying a better lock is quick. Keeping an accurate floor plan of a building that changes every week is harder. Rebuilding a burned-out building in three days, while patients are still inside, is a different kind of problem altogether.

The legal change underneath all four groups was the end of “addressable.” Under the 2003 rule, an addressable specification had to be implemented if reasonable and appropriate. If it was not, the organization documented why and adopted an equivalent alternative where one was reasonable. Many organizations read that as permission to defer encryption or multi-factor authentication indefinitely, with a memo on file. The proposal would turn most of those memos into findings.

A 2021 amendment to the HITECH Act already pointed the same way from the enforcement side. It requires HHS to consider whether an organization had recognized security practices in place for the previous 12 months when it decides on penalties and audit outcomes. The proposal would move from rewarding good practice to requiring it.

Controls most systems already had

Multi-factor authentication, encryption, anti-malware, patching and access controls were standard in most large health systems by 2024. HHS’s voluntary cybersecurity performance goals, released earlier that year, pointed the same way. Removing the “addressable” category would turn them from judgment calls into explicit obligations.

The work in this group is coverage. Legacy clinical systems, medical devices and affiliated practices often lack multi-factor authentication or encryption because the technology cannot support it. An infusion pump designed fifteen years ago, or an imaging machine running software its manufacturer no longer updates, may simply have no way to add a second login step.

The proposal allowed limited exceptions, but each would need documentation: the gap, the reason and the compensating control. A compensating control is an alternative protection used where the standard one is impossible. One example is isolating an old device on its own section of the network so that even if it is weak, attackers cannot reach it easily. A register of exceptions, reviewed each quarter by a named owner, turns that from an audit scramble into routine work.

Each register entry needs a few fields to be useful: the system or device, its clinical owner, the control that is missing, the reason, the compensating control, the date it was last verified and a target date for removing the exception. Entries without a target date tend to become permanent. A quarterly review that closes or renews each one, with the owner present, keeps the list short.

What the specifics would demand

Several controls carried clocks or conditions that would change daily operations. Patching critical risks within 15 calendar days is routine for a laptop fleet. It is hard for clinical systems whose vendors must validate each update, and for medical devices whose software the hospital cannot change at all. The proposal allowed exceptions, but each would need to be documented and backed by compensating controls.

Other items look simple and are not. Removing extraneous software means knowing what is installed on every system and why. Network segmentation means drawing boundaries that clinical workflows cross constantly, such as between imaging devices, the archive that stores images and the reading workstations. Multi-factor authentication everywhere includes shared clinical workstations, where clinicians log in dozens of times a shift and badge-tap solutions are usually the only acceptable answer.

Medical devices

Since 2023 federal law has required makers of new network-connected medical devices to submit cybersecurity information to the FDA before marketing them, including plans to monitor and patch vulnerabilities. That helps with the next generation of equipment. It does nothing for the installed base, which hospitals keep for many years. For those devices, the realistic compensating controls are isolation on dedicated network segments, strict rules about what each device may talk to, monitoring for unusual traffic, and documented replacement plans tied to capital budgets.

How the work differs by organization

For a large system, the controls group is a coverage exercise across thousands of endpoints and hundreds of applications, and the exception register is the main product. For a critical access hospital, the controls are often delivered by its hosted record vendor and managed service providers, so the work is contractual: confirming who configures multi-factor authentication, encryption and patching, and getting evidence. Ambulatory networks face the hardest version of coverage, because small practices often run their own devices and local software. A health plan’s controls problem is closer to a bank’s, with fewer legacy clinical systems and more third-party data flows.

Evidence most lacked

The second group concerns proof. A written asset inventory and a network map showing how electronic protected health information moves are foundations of any security program. Many health systems did not keep them complete and current. The proposal also called for regular compliance audits and risk analyses with specified content.

This is a discipline problem more than a technology purchase. Inventories decay quickly in hospitals, where departments acquire devices and software on their own. A cardiology group signs up for a new reporting tool; a research team spins up a database; a clinic buys a tablet-based check-in system. Each may be perfectly sensible. Each, unrecorded, is a door nobody is watching.

Keeping inventories current needs biomedical engineering, clinical departments and procurement, with a rule that nothing connects to the network without an inventory record. The network map forces conversations about data flows that many organizations have never had, such as which research databases, analytics platforms and vendor portals receive patient data.

The risk analysis belongs in this group as well. OCR had long cited missing or superficial risk analyses as the most common failure in its investigations, and in late 2024 it launched an enforcement initiative focused on them. A risk analysis built on an incomplete inventory inherits its gaps. The order of work is therefore inventory, then map, then analysis, each feeding the next. Skipping ahead produces documents that look complete and are not.

Building an inventory that stays true

No single source holds a complete inventory. Network discovery tools find devices that talk on the network. Biomedical engineering keeps its own maintenance database for clinical equipment. Procurement records what was bought, and the identity system shows which software-as-a-service applications staff sign in to. Cloud accounts list servers and storage that never appear on a hospital network at all.

A durable inventory reconciles those sources on a schedule and assigns each record an owner. A useful metric is the share of devices found by discovery that match an inventory record with a named owner. Anything unmatched is either an inventory gap or an intruder, and both deserve a ticket.

An annual compliance audit

The proposal would require each regulated entity to audit its own compliance with every standard and implementation specification at least once every 12 months. Large systems would likely give the work to internal audit, with periodic outside assessments. Smaller providers would probably buy it from consultants. Either way, the audit is only as good as the evidence behind it, which is why it belongs with inventory, mapping and risk analysis rather than with controls.

Network maps that mean something

A network map that shows boxes and lines satisfies an auditor for a year and helps nobody in an incident. The useful version follows patient data: where it is created, which interfaces carry it, which systems store copies and which outside parties receive it. In a hospital that usually means tracing the interface engine, which passes orders, results and admissions between dozens of systems, and the feeds to registries, payers, research platforms and analytics vendors.

That tracing has a security payoff. The interface engine and the identity system are two of the few components that touch almost everything, which makes them prime targets and top priorities for recovery. A map built around data flows shows those dependencies in a way an equipment list does not.

The 24-hour access notice

One proposed requirement reached across organizational lines. When a workforce member’s access to another regulated entity’s systems or data changed or ended, the organization would notify that entity within 24 hours. Health care is full of such access: physicians with privileges at several hospitals, billing staff using payer portals, clinicians using a health information exchange.

Meeting a 24-hour clock means knowing, for each person, which outside systems they can reach. Few organizations keep that list. It also means connecting human resources events to the identity team quickly, including for contractors and residents whose departures are often recorded late.

Recovery capability few could demonstrate

The most demanding element required written procedures to restore relevant systems and data within 72 hours, backed by a criticality analysis and testing. A criticality analysis ranks systems by how much harm their loss would cause, so the organization knows which matter most. Ransomware recoveries at large health systems in 2024 had taken weeks. The Change Healthcare outage and the Ascension attack had each disrupted operations for much longer than three days.

Why does recovery take so long? After a ransomware attack, an organization cannot simply switch systems back on. It must first be confident the attackers are gone, or they will strike again. It must find backups that were not themselves encrypted or tampered with. It must rebuild servers on clean equipment, restore data, reconnect hundreds of interdependent applications in the right order and check that everything works. Doing that for one system is routine. Doing it for an entire hospital network at once, while patients are still being treated, is another matter.

The proposal required procedures aimed at that timeframe, not a guarantee that every system would return. Procedures never tested at scale are not credible, so in practice the requirement meant a recovery program with three parts.

A clinically agreed restore sequence

Which systems come back first depends on how care is delivered: the electronic health record, laboratory and imaging, pharmacy dispensing, and the identity and network services they all need. Identity services are the systems that confirm who users are and what they may access; without them, nobody can log in to anything else. IT cannot set that order alone. A chief nursing officer, a chief medical officer and department heads must agree which clinical functions matter most in the first hours and days.

Recovery infrastructure

Immutable, isolated backups, clean build environments and enough compute and staff to rebuild many systems at once are expensive and rarely sized for a full-estate event. An immutable backup is a copy that cannot be changed or deleted for a set period, even by an administrator, so attackers cannot destroy it. Isolated means kept separate from the main network. A clean build environment is a set of trusted computers on which systems can be rebuilt without risk of reinfection. A full-estate event is one that takes down everything at once, rather than a single system.

Tests at realistic scale

Tests should be timed and repeated, with results reported to the board. Restoring one test server on a calm weekend proves little. Restoring a representative set of critical systems, in sequence, against the clock, shows what the organization can really do.

What the 72 and 48 hours imply

Two numbers in the proposal work together. Backups no more than 48 hours older than live data set a ceiling on how much data could be lost. Restore procedures aimed at 72 hours for critical systems set a ceiling on how long they could be down. Recovery engineers call these the recovery point objective and the recovery time objective. Most hospitals already had targets of this kind for individual systems. Few had tested them for a scenario in which every system failed at once.

The proposal limited the 72-hour expectation to critical systems and data, and asked commenters whether all systems should meet it. That narrows the problem but does not remove it. Identity, networking and the electronic health record are critical by any definition, and they depend on each other. If the directory that authenticates every user is lost, it has to come back before almost anything else can.

Why speed and safety pull against each other

Restoring fast can mean restoring the attacker. Incident responders usually want to understand how the intruders got in and confirm they are gone before systems are reconnected. Cyber insurers and law enforcement may want evidence preserved. A procedure that aims at 72 hours has to build those steps into the timeline, typically by having clean, pre-built recovery environments ready so that rebuilding can start while investigation continues.

Hosted records change the division of labor

Many hospitals, especially smaller ones, run their electronic health record in a vendor’s hosted environment. That shifts much of the database and application recovery to the vendor. It does not shift the hospital’s own network, identity systems, workstations, interfaces and printers. A hosted record that is running in the vendor’s data center is no use to clinicians whose workstations have been encrypted. Recovery plans should cover the whole path from the vendor’s data center to the bedside.

Rehearsing the decision as well as the restore

Recovery exercises often start at the moment systems are declared down. In real incidents, much time is lost earlier, while leaders debate whether to disconnect systems, divert ambulances or switch units to paper. A tabletop exercise that includes the chief executive, chief medical officer, chief nursing officer, communications and legal staff can agree those triggers in advance: who may order a shutdown, on what evidence, and who tells the units. Hours saved at the start count toward any restore target.

Bridging the gap: downtime procedures

Downtime procedures fill the gap between outage and restoration, which can differ by system by days. They need the same clinical ownership as the restore sequence. Read-only downtime viewers, which hold recent medication administration records, allergies and active orders on isolated hardware, let clinicians work safely for days without the main record. Paper forms and runners cover the rest. Each unit should know how to switch over without waiting for instructions from IT.

The test of a downtime plan is simple: on a busy night shift, with no warning and no help from IT, can a charge nurse find the downtime viewer, pull the paper forms and keep medications on schedule? If the answer depends on one experienced person being on duty, the plan is not finished.

For many health systems, the honest first output of this work is a measured restore time far above 72 hours and a funded plan to close the gap.

Obligations reaching into business associates

The fourth group addressed the supply chain. Business associates would verify their technical safeguards in writing each year and tell covered entities promptly when they activated contingency plans. Change Healthcare had shown how one business associate’s outage could halt claims and payments nationwide.

For covered entities, oversight would shift from a contract signed once to an annual evidence process. That creates a basis to request recovery test results and restore times from critical vendors, which ties this group back to the third. A health system cannot meet its own 72-hour objective if the vendor running its revenue cycle or imaging archive cannot. Where a vendor cannot show a credible restore time, the health system needs its own fallback for that workflow. Counsel should review how existing business associate agreements would need to change.

What the annual verification would look like

Under the proposal, covered entities would obtain written verification from each business associate, at least every 12 months, that it had deployed the required technical safeguards. The verification would include a written analysis by someone with appropriate cybersecurity knowledge and experience. A health system with hundreds of business associates cannot run deep reviews of all of them. A tiered approach is the practical answer: full evidence for vendors that hold large volumes of data or run critical workflows, and lighter attestations for the rest.

Existing third-party reports, such as SOC 2 examinations or HITRUST certifications, can feed the verification but may not map neatly to every Security Rule standard. Contracts would need to say who pays for the analysis and what happens when a vendor fails it.

Acting on a 24-hour notice

The proposed requirement that business associates report contingency plan activation within 24 hours is only useful if someone receives the notice and acts. Each critical vendor should map to a named internal owner and a pre-agreed response: switch to the backup workflow, notify clinical leaders, prepare patient communications. A notice that lands in a shared mailbox on a holiday weekend helps nobody.

The business associate’s side

For the vendors themselves, the proposal would multiply requests. A billing company or hosted record vendor serving hundreds of providers could face hundreds of separate verification demands each year, each with its own questionnaire. The rational response is a single annual written analysis, shared with every customer under confidentiality terms. Covered entities would do well to accept a credible standard package rather than insisting on bespoke forms, and to spend their own effort on the vendors that matter most. Business associates would also need to push the same obligations down to their own subcontractors.

Concentration risk

Change Healthcare showed that some business associates are effectively shared infrastructure. In March 2024, CMS offered accelerated and advance payments to providers whose cash flow had been disrupted, an unusual step that showed how far the effects spread. The British pathology provider Synnovis, attacked in June 2024, disrupted blood testing and procedures at London hospitals for weeks. The practical response is alternative arrangements signed in advance, such as a second clearinghouse connection or a reference laboratory agreement, tested before they are needed.

One health system times its own recovery

Suppose a regional health system has three hospitals and a network of clinics. After reading about the proposal, its board asks a simple question: how long it would take to recover.

The chief information officer starts with the inventory and discovers it is out of date; several departments have systems nobody in IT knew about. After updating it, the team convenes clinical leaders to agree a restore order: identity and network services first, then the electronic health record, then pharmacy, laboratory and imaging, then everything else. Next, it runs a timed test, restoring a representative set of critical systems from isolated backups onto clean hardware.

The result is sobering. Even the first tier takes longer than three days, mostly because there is not enough clean hardware and not enough trained staff to rebuild many systems in parallel. Its billing vendor and imaging archive vendor, asked for their own restore times, provide marketing language rather than numbers.

That is not a failure. It is the first honest picture the board has seen. With it, the board can fund specific gaps, more recovery capacity, more rehearsals and stronger vendor terms, and track the measured restore time as it falls. Without it, the board would be approving a 72-hour procedure on paper and hoping it held.

The same exercise in a small hospital

A critical access hospital would run a shorter version. Its restore order might be the same, but most of its systems are hosted, so the timed test is partly a test of its vendors. The first question is whether the hosted record vendor can restore the hospital’s environment, and in what time. The next is whether the hospital can rebuild its own workstations and network quickly enough to use it, and who would do that work at night. The answer often depends on one managed service provider. The board’s decision then concerns that contract, not hardware.

What the board gave up

Funding recovery capacity means not funding something else. In the regional system’s case, the money for clean hardware and extra rebuild staff might come from a delayed application upgrade or a slower rollout of a new clinical tool. Boards should see that trade-off stated plainly, alongside the measured restore time, so the choice is deliberate.

What the board sees each quarter

A short dashboard keeps the work honest. It can show the measured restore time for the first tier of systems and the date of the last test. It can add the share of discovered devices matched to an inventory record, the number of open exceptions with compensating controls, and the critical vendors that have supplied tested restore times. Each figure should come from evidence the board could ask to see, not from a self-assessment. Trends matter more than any single quarter.

Making the budget case for recovery

Of the four groups, recovery is the one that most often stalls at the finance committee. Controls can be justified by audit findings, and evidence work is mostly staff time. Recovery capacity, by contrast, means paying for hardware, backup systems and specialist staff that, on a good day, sit idle. That makes it an easy line to trim.

A more productive framing treats recovery spending as insurance whose value can be estimated. Finance and clinical leaders can work together to estimate what each additional day of a full outage would cost: diverted ambulances, postponed procedures, delayed billing, overtime for paper-based work, agency staff and the expense of reconciling records afterward. Set beside the cost of shortening the outage, by buying more clean hardware, isolating backups properly or training more staff to rebuild systems, the comparison is often clarifying. A recovery investment that shortens a hypothetical outage by several days may pay for itself many times over in the one year it is needed.

Three practical points help the case land.

  • Tie money to the measured number. Boards respond to a clear metric. “Our tested restore time for critical systems is currently X days; this investment is expected to bring it to Y” is far more persuasive than a list of products.
  • Phase the spending. Not every system needs the fastest recovery. The criticality analysis shows where speed matters most, so the first tranche of money can go to the identity services and clinical systems at the top of the restore order.
  • Count what the organization already pays. Cyber insurance premiums, incident response retainers and existing backup contracts are part of the same picture. Sometimes the right move is to redirect money rather than add it.

Smaller and rural providers, whose objections featured prominently in early reactions, face the hardest version of this arithmetic. For them, the realistic path may be to rely more heavily on well-rehearsed downtime procedures and on vendors with credible restore times, rather than building large recovery environments of their own. The principle is the same: know the number, and make a deliberate choice about how much to spend to improve it.

The case against a hard number

The strongest objection to the 72-hour line was that any fixed number is arbitrary. Hospitals differ in size, complexity and threat exposure. A number could push organizations to restore before they are sure attackers are gone, or lead them to rank too few systems as critical to make the target achievable. Critics also argued that small providers would spend money on paperwork rather than recovery.

Those objections have weight, and they argue for flexibility in how the target applies. They do not argue against measuring. The organizations that struggled most in 2024 typically did not know their own restore times until an attack measured them. A fixed number, even an imperfect one, forces that measurement in advance. A health system that tests, reports and funds against its own measured number gets most of the benefit whether or not the regulator’s figure survives.

What insurers and lenders ask

Cyber insurers already ask about backups, isolation and restore testing in their applications, and premiums and coverage reflect the answers. Bond investors and rating agencies ask health systems about cyber risk as part of operational risk. A measured restore time, with test evidence, answers those questions too. The same work therefore serves the regulator, the insurer and the finance committee.

Patients, money, regulators and the board

  • Patient safety. Long outages force clinicians onto paper and divert ambulances. Recovery speed is a clinical quality issue as much as a technical one.
  • Money. Every day of downtime means delayed billing, overtime and lost revenue. Recovery infrastructure is expensive, but so is a multi-week outage.
  • Regulators. Whatever happened to the proposal, OCR’s focus on risk analysis meant enforcement was already reaching the evidence group.
  • Board oversight. A measured restore time is one of the few cyber metrics a board can understand and track without technical training.

State rules add to the federal picture for some hospitals. New York, for example, adopted hospital cybersecurity regulations in 2024. They require general hospitals to maintain cybersecurity programs and incident response plans, appoint a chief information security officer and report cybersecurity incidents to the state health department within 72 hours. A New York hospital preparing for the HIPAA proposal was therefore building on obligations it already had. Organizations in other states should check with counsel on any state-level requirements that apply to them.

Where recovery programs go wrong

  • Treating the proposal as a checklist of tools to buy rather than a program of evidence and recovery.
  • Letting IT set the restore order without clinical leaders.
  • Testing recovery on one system and assuming the result scales to all of them.
  • Keeping backups on the same network attackers would reach.
  • Accepting vendor assurances without asking for tested restore times.
  • Writing downtime procedures that nobody on the units has practiced.
  • Ranking too few systems as critical to make a restore target look achievable.
  • Assuming a hosted record vendor’s recovery covers the hospital’s own network, identity systems and workstations.
  • Sending business associate questionnaires once a year and never reading the answers.
  • Leaving the 24-hour access and contingency notices to land in a shared mailbox with no named owner.

Measured or estimated

  1. If everything went down tonight, how long would it take to restore our most critical systems? Is that number measured or estimated?
  2. Who decided the order in which our systems would come back, and did clinical leaders agree it?
  3. Do we have enough clean hardware and trained staff to rebuild many systems at once?
  4. Which vendors run workflows we cannot do without, and what are their tested restore times?
  5. Could each nursing unit switch to downtime procedures tonight without calling IT?

With hindsight

The proposal drew thousands of comments. A coalition of more than 100 hospital systems, provider organizations and associations, led by the College of Healthcare Information Management Executives, asked HHS to withdraw it. They cited unfunded mandates, prescriptive controls that clashed with how health systems run their technology, and documentation burdens on stretched teams. The change of administration in January 2025, and its broader push to reduce regulation, slowed the rule’s path.

The regulatory agenda then set May 2026 as the target for a final rule. That date passed without one. A later agenda moved the target to July 2027, while still listing the rule as active. As of this writing the existing Security Rule, with its addressable specifications, remains in force.

Enforcement did not wait for the rulemaking. OCR announced the first action under its risk analysis initiative on October 31, 2024: a $90,000 settlement with an Oklahoma ambulance provider whose patient data had been encrypted by ransomware. By early 2026 it had announced at least a dozen actions under the initiative. They reached covered entities and business associates alike, including imaging providers, cloud hosting firms and a public hospital. Several of those actions involved business associates, such as a cloud-based record and billing provider and a data hosting company, showing OCR applying existing rules to the supply chain the proposal would have formalized. Even without the new rule, the regulator kept pressing on the evidence group: organizations that cannot show a thorough, current risk analysis have continued to face consequences.

The size of the problem also became clearer. In January 2025 UnitedHealth Group said the Change Healthcare breach had affected about 190 million people, the largest health data breach reported in the United States. That figure confirmed the business associate argument. A single clearinghouse had become a single point of failure for much of the industry’s cash flow and a single source of exposure for most Americans’ data.

The proposal also had a second life as a benchmark. Because its requirements were written down in detail, with clocks and frequencies, auditors, insurers and boards could compare a program against them whether or not they ever became law. Several of the specifics, such as patch windows and backup age, were measurable enough to report every quarter.

The difficulty ranking has held. Controls kept spreading, with help from cyber insurers, which increasingly expect basics such as multi-factor authentication before they will offer coverage. Inventories and network maps stayed hard, because hospitals keep adding devices and software faster than records keep up.

Recovery capability remained the widest gap. Long ransomware outages at health care organizations continued through 2025. Kettering Health in Ohio, hit by ransomware in May 2025, spent weeks on downtime procedures while it restored its systems. Each such episode kept restore time a board-level question whether or not the 72-hour line becomes law.

The most useful number a board can track remains the measured restore time for critical systems, tested at scale and reported with the date of the test. It answers the question the proposal asked under any version of the rule, including none.

That last point is the practical one. The 72-hour figure was a regulatory proposal, but the underlying question does not depend on any rule: how long could this organization keep caring for patients safely if its systems went dark, and how quickly could it bring them back? A health system that measures that honestly, funds the gap and rehearses the plan will be better placed whatever form the final rule takes, and far better placed on the day an attack arrives. Rules can be delayed, rewritten or withdrawn. The patients in the beds at the moment the screens go dark are not affected by any of that, and neither is the responsibility to care for them.

Spotted an error? Tell us and we will check it and correct the article where needed.

  • HIPAA Security Rule
  • OCR
  • ransomware recovery
  • business associates
  • backup