A regional health system’s electronic health record went dark for exactly five minutes early one morning. Clinicians did what clinicians do: shrugged, reached for paper, and were back on the keyboard before most of them had finished their coffee. No harm done. But the incident review that followed surfaced something that unsettled the CISO far more than the outage itself: if those five minutes had been five hours, nobody on staff could say with certainty which systems needed to come back first the EHR, the e-prescribing link to the pharmacy, the lab interface, the imaging archive, the engine quietly translating messages between all of them or in what order, or who was actually authorized to make that call at 3 a.m. They had backups. What they did not have was a plan for using them.
That gap between owning the pieces and owning a strategy is where resilience quietly lives or dies. And in healthcare, unlike almost anywhere else, the gap isn’t measured in lost revenue. It’s measured in delayed care.
Redundancy Is Not The Same Thing As A Strategy
Most health systems past a certain size have already bought themselves some redundancy. Multiple availability zones, automated failover, patient data replicated across regions. That is good infrastructure, and it is worth having. It is also not the same thing as knowing what to do when something breaks in a way the redundancy never anticipated, which is precisely what a real incident tends to do.
Cloud reliability, taken seriously, means building a decision structure around the infrastructure, not just standing up the infrastructure and hoping. Who declares an incident. Which systems get restored first, and by what logic. What “acceptable data loss” actually means expressed as a number, not a vague sentence in a policy nobody has opened since the day it was written.
Healthcare is unusual here in that the law already spells out the discipline most organizations skip. The HIPAA Security Rule’s contingency-plan standard requires covered entities and their business associates to maintain a data backup plan, a disaster recovery plan, and an emergency-mode operations plan and, tellingly, to perform an “applications and data criticality analysis,” the formal exercise of deciding in advance which systems and data must come back first. The regulation names the exact conversation the five-minute scare had let this health system postpone for years.
If you want the cautionary version of skipping it, look at February 2024, when the Russia-linked ALPHV/BlackCat group ransomwared Change Healthcare. This clearinghouse processes roughly half of all U.S. medical claims. Systems were down for weeks; an estimated 192.7 million people had data exposed, the largest health-data breach ever recorded. A March 2024 American Hospital Association survey of nearly 1,000 hospitals found 74% reporting a direct impact on patient care and 94% reporting a financial hit. As a Congressional Research Service brief noted, the fallout rippled nationwide: pharmacies unable to verify coverage, providers unable to get paid. Most of the affected organizations discovered how completely they depended on a single vendor at the precise moment that vendor stopped answering.
Backup Tooling Gets Chosen Once And Almost Never Revisited
Here is a pattern worth naming: an organization picks a backup platform early, usually whatever fits the infrastructure at the time. Then it stops thinking about it for years, even as the environment and the actual requirements drift a long way from where they started.
The tradeoffs between AWS Backup and N2WS come up constantly in these conversations, because they represent two genuinely different philosophies rather than a simple better-or-worse ranking. AWS Backup is native, inexpensive, and covers standard use cases inside the AWS ecosystem with very little setup. For a clinic group running a moderate footprint across a handful of accounts, it is frequently exactly enough.
N2WS starts to earn its higher price tag when the requirements outgrow that simplicity: granular recovery down to individual database tables, cross-account orchestration that doesn’t depend on a lattice of custom scripts to hold together, and audit-ready reporting for a setting where “we’re fairly sure it backed up” satisfies neither a patient-safety review nor an Office for Civil Rights auditor. A hospital network managing electronic protected health information across a dozen AWS accounts is not solving the same problem as a ten-person digital-health startup, and pretending the cheaper option is always the smarter one ignores what is actually at stake for each of them.
The mistake I see most often is not choosing the wrong tool at the outset. It is never revisiting that choice as the organization scales and ending up either paying for capability nobody touches or, far worse in this field, under-protecting a system that has quietly grown past what its original setup was ever built to hold. In most industries, “under-protected” means an awkward week. In healthcare, it can mean patient records that don’t come back.
Recovery Time Objectives Are Usually Aspirational, Not Real
Ask most health-IT leaders what their recovery time objective is, and you’ll get a number: four hours, maybe two. Ask them when they last tested whether that number is true, and the room tends to go quiet.
The vocabulary here is worth borrowing from NIST’s contingency-planning guidance (SP 800-34), which pins down the terms most plans wave at: the recovery time objective, or how long a system can stay down before the impact becomes unacceptable; the recovery point objective, or how much data loss you can actually tolerate; and the business impact analysis that sets recovery priorities in the first place. These are meant to be numbers you have stress-tested, not aspirations you have written down.
One hospital found out the expensive way that its four-hour restore target was closer to eleven hours in practice because the restore process hinged on one engineer’s specific, undocumented knowledge of a script that lived nowhere else. He happened to be reachable that day. The plan worked because of luck, not because of planning, and luck is not a control you can put in a policy binder.
The stakes turn that gap from an operational embarrassment into a clinical problem. In Proofpoint and the Ponemon Institute’s 2025 healthcare survey, 72% of organizations that suffered a common cyberattack reported a disruption to patient care, delayed procedures, longer stays, patients diverted elsewhere and, more soberingly, some studies have argued the disruption can extend to patient survival itself. That last claim deserves an honest asterisk: the mortality figures come from surveys of IT staff rather than controlled studies of patient outcomes, and hospital groups have rightly cautioned against reading them as proven causation. But even setting the hardest numbers aside, the direction is not in dispute. Downtime in a hospital is a care event, not just an IT event.
Testing Has To Be Scheduled Like It Matters, Because It Does
The organizations that actually recover well during real incidents share one unglamorous habit: they run recovery drills on a real calendar, not “whenever things slow down,” which for most teams means never. NIST recommends testing at least annually, and more often for high-impact systems; HIPAA, for its part, expects testing and revision to be part of the plan rather than an afterthought. The strongest programs go further and run tabletop exercises and downtime procedures rehearsing the “digital darkness” while the lights are still on and they run them on the assumption that the person who normally handles recovery might be the one person unreachable when it counts.
These drills catch the quiet failures that never surface otherwise. A database schema change from eight months ago that silently broke a restore script. A credential that expired without anyone noticing because nothing had tried to use it since. A backup job that completes cleanly every night and cannot actually be restored. None of this shows up on a dashboard. It shows up when someone finally tries to use the recovery plan and discovers it doesn’t behave the way everyone assumed.
There’s a newer wrinkle worth planning for, too. Attackers have increasingly shifted toward stealing data and extorting victims without encrypting anything, which means pristine backups, essential as they are for getting systems back, no longer save you from the breach itself. Backups restore availability. They do not restore confidentiality once records are already out the door.
What A Resilient Strategy Actually Looks Like
The infrastructure has genuinely gotten better: more distributed, more automated, harder to knock over with a single point of failure. That progress breeds a specific complacency, because technology working well most of the time is very persuasive evidence that the harder organizational questions can keep waiting.
The financial framing alone should end that argument. Healthcare has been the most expensive industry for data breaches for fourteen consecutive years, averaging $7.42 million per incident in 2025 even after a meaningful drop from the prior year, with the longest containment timeline of any sector at 279 days. The ruinous part is rarely the moment of encryption. It’s the weeks of degraded operations, manual workarounds, and delayed care that follow.
The health system with the five-minute scare didn’t need better infrastructure. It needed an actual decision tree, tested backups tied to tooling that matched its real requirements and its regulatory obligations rather than whatever it happened to pick years earlier, and the habit of finding its own weak points before an incident found them first. That is less about which vendor’s logo ends up on the contract and more about whether anyone bothered to ask the hard questions while things were still calm enough to answer them honestly.
A Closing Note
In most sectors, the difference between resilience and luck is a bad quarter. In healthcare, it can be the difference between a patient’s procedure happening on schedule and happening after a transfer to another facility. The tools matter, but the plan for using them matters more than who declares the incident. Put the restore order in writing before you need it. Define acceptable downtime and acceptable data loss as numbers. Then test the whole thing on a calendar, with your best person assumed to be on a plane. It is the quietest, most boring work an IT team does, and it is exactly what keeps a five-minute outage from becoming an eleven-hour one or a headline, or worse.
Disclaimer
This article is for general informational purposes only and does not constitute legal, compliance, security, or medical advice. HIPAA obligations and the appropriate design of a contingency, backup, or disaster-recovery program vary by organization, and the statistics and regulatory details cited here can change over time. Nothing here should be relied upon as a substitute for guidance from qualified cybersecurity, compliance, and legal professionals familiar with your specific environment. Vendor and product references are illustrative and are not endorsements; evaluate any tooling against your own requirements before relying on it.
References
- American Hospital Association. “Change Healthcare Cyberattack Underscores Urgent Need to Strengthen Cyber Preparedness for Individual Health Care Organizations and as a Field.” AHA.org, 2024. https://www.aha.org/change-healthcare-cyberattack-underscores-urgent-need-strengthen-cyber-preparedness-individual-health-care-organizations-and
- Congressional Research Service. “The Change Healthcare Cyberattack and Response Considerations for Policymakers” (Insight IN12330). Congress.gov / Library of Congress, April 24, 2024. https://www.congress.gov/crs-product/IN12330
- U.S. Department of Health and Human Services. “45 CFR § 164.308 Administrative Safeguards” (HIPAA Security Rule, Contingency Plan standard). Electronic Code of Federal Regulations (eCFR), current edition. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
- Swanson, M., et al. “NIST Special Publication 800-34, Revision 1: Contingency Planning Guide for Federal Information Systems.” National Institute of Standards and Technology (NIST). https://csrc.nist.gov/pubs/sp/800/34/final
- HIPAA Journal. “Average Cost of a Healthcare Data Breach Falls to $7.42 Million” (reporting on IBM Cost of a Data Breach Report 2025). HIPAAJournal.com, July 30, 2025. https://www.hipaajournal.com/average-cost-of-a-healthcare-data-breach-2025/
- Proofpoint, Inc., and Ponemon Institute. “Nearly Three in Four U.S. Healthcare Organizations Report Patient Care Disruption Due to Cyber Attacks” (Cyber Insecurity in Healthcare: The Cost and Impact on Patient Safety and Care 2025). Proofpoint.com, October 8, 2025. https://www.proofpoint.com/us/newsroom/press-releases/nearly-three-four-us-healthcare-organizations-report-patient-care-disruption
- Healthcare IT News. “Ransomware Stakes Are Life-or-Death, Says Ponemon Report.” HealthcareITNews.com. https://www.healthcareitnews.com/news/ransomware-stakes-are-life-or-death-says-ponemon-report
- Riggi, John (American Hospital Association). “Proofpoint Press Release on Cybersecurity Survey Does a Disservice to Health Care Providers.” AHA News, September 23, 2022. https://www.aha.org/news/blog/2022-09-23-proofpoint-press-release-cybersecurity-survey-does-disservice-health-care