How Hospital Ransomware Incident Response Really Works

In February 2024, a single ransomware attack (malicious software that scrambles a computer’s files and demands payment to unlock them) knocked the patient-records systems of more than a hundred hospitals in Romania offline within a day. Doctors switched to pen and paper for admissions, lab requests traveled between departments by hand, and pharmacies filled orders from handwritten notes. No deaths were reported, and most hospitals were close to normal within about a week. That calm outcome, rather than a catastrophic one, is exactly why the case is worth studying: hospital ransomware incident response is less about preventing every attack and more about what happens in the hours and weeks after one gets through.

What incident response actually covers

Prevention and incident response solve two different problems, and a hospital that is good at one is not automatically good at the other. Prevention tries to keep an attacker out in the first place: patching software, segmenting the network, training staff to spot phishing emails. Incident response starts from a different assumption: that an attacker has already gotten in. It asks a narrower set of questions. Can the affected systems be isolated fast enough to stop the damage from spreading? Can the organization restore from backup instead of negotiating with the attacker? How does patient care keep running while the computers are down? And once the visible outage ends, how long does the invisible part of recovery, catching up on everything that piled up while the systems were dark, actually take?

Romania’s hospitals answer all four of those questions well, which is why the case rewards a close look rather than a glance at a headline. The attack itself was not unusual: outdated software, a criminal group after money, a shared system that gave one break-in a wide reach. What made the outcome unusual was the response that followed, built months before anyone knew an attack was coming.

What happened in Romania’s hospitals

The attack started at a children’s hospital in Pitești on Saturday, February 10, 2024, when staff found patient records suddenly encrypted and unreadable. Over the following two days, it spread to dozens of other facilities running the same software, a system called the Hipocrate Information System, built by a Bucharest-based vendor called Romanian Soft Company that handles admissions, lab results, pharmacy orders, and billing for a large share of Romania’s hospital beds. Because so many hospitals connected to that same platform, the ransomware moved through the network faster than any single hospital’s IT staff could have reacted on its own. By the time Romania’s national cybersecurity directorate, known as DNSC, had finished assessing the damage, 26 hospitals had data actually locked up, and roughly 79 more had been disconnected from the internet as a precaution before the ransomware could reach them. Combined, that is where the widely reported figure of “100 hospitals” comes from: a mix of hospitals that were hit and hospitals that were pulled offline before they could be.

The tool behind the attack was a ransomware strain called Backmydata, a variant of an older ransomware family named Phobos that has circulated among criminal groups for years. The attackers demanded 3.5 bitcoin, worth somewhere between roughly 157,000 and 160,000 euros depending on the exchange rate the outlet used to convert it. Those numbers are useful for scale, but they are also the most perishable part of the story. What matters six months or six years later is not the bitcoin price. It is what the hospitals did next.

Why one break-in became a hundred-hospital problem

This was not a hundred separate hospital security failures happening at once. It was one shared piece of software cascading into every hospital plugged into it, regardless of how well any individual IT team had prepared.

The same logic explains software supply chain attacks, where one compromised component quietly reaches every organization that installed it, and the push toward zero trust design, where connecting to a shared platform should not automatically grant broad access to everything else on the network. Neither idea would have stopped this specific attack, but both point at the same weakness: shared infrastructure means a shared blast radius.

The ransom nobody paid

Romanian authorities, through DNSC, publicly recommended against paying the ransom, and no ransom was paid. The ransom note itself broke an unwritten industry pattern: according to DNSC, the attackers’ message gave only an email address for contact, with no group name, no logo, and none of the branding modern ransomware operations typically use to advertise themselves and pressure victims into negotiating. The group behind the attack was never publicly identified, an unusual gap for an attack this size.

A coordinator, not just a hundred separate hospitals

Part of what limited the damage happened before most of the affected hospitals even knew they were at risk. DNSC, acting as a single coordinating body, made the call to preemptively disconnect roughly 79 healthcare units from the internet as soon as the scale of the attack became clear. That is a decision only a body with authority over many hospitals at once can make quickly. An individual hospital’s IT team, however competent, cannot disconnect a neighboring facility it has no authority over.

This is the part of the response that rarely shows up in after-action headlines, because it is boring by design: someone with the authority to act across an entire sector, and a pre-existing plan for what to do when a shared system is compromised, rather than dozens of hospitals independently discovering the same emergency and improvising in parallel.

The backup that actually worked

The reason Romanian authorities could recommend against paying, and have hospitals actually follow that advice, comes down to one unglamorous fact: most of the affected hospitals had recent backups that had actually been tested and could be restored. DNSC credited those backups as the specific reason systems came back online without anyone needing to negotiate with the attackers.

A backup that exists on paper in an IT policy document is not the same as one that has been rehearsed and confirmed to work under pressure, and the gap is usually invisible until the day it matters.

Pen and paper still has a job

While digital systems were down, hospital staff did not improvise. They fell back to handwritten admissions, lab requests, and pharmacy orders, a manual continuity process that had been established and practiced before the attack, not invented in the moment. That distinction matters: a rehearsed fallback lets a hospital keep functioning at a slower pace, while an improvised one tends to produce errors exactly when patients can least afford them.

The paper era did not end the moment the computers came back. Re-entering weeks of handwritten records into the digital systems took considerably longer than getting the hospitals themselves back to normal operation, which happened in about five days. The visible recovery and the invisible one run on different timelines, and organizations that only plan for the first one tend to be caught off guard by the second.

What made Romania’s outcome different

Two other well-documented hospital cyberattacks make a useful contrast. The 2017 WannaCry attack on the UK’s National Health Service (NHS) disrupted dozens of hospital trusts and led to thousands of cancelled appointments, but it was an uncontrolled worm spreading indiscriminately across the internet rather than an attack aimed specifically at hospitals, and it left no confirmed link to a patient death. The 2024 attack on Synnovis, a pathology-services provider for London hospitals, was more targeted and more severe in its consequences: a 2025 review by King’s College Hospital NHS Trust found that the disruption, largely through delayed blood-test results, contributed to one patient’s death, the first publicly confirmed case in the UK of a cyberattack contributing to a death.

Romania’s incident sits between those two in scale but stands apart in outcome. No deaths were reported, and normal hospital operations resumed within days rather than weeks. The technology involved, off-the-shelf ransomware hitting outdated or unsegmented systems, was not meaningfully more advanced or less advanced than in the other two cases. What differed was preparation: tested backups, a national body with an established playbook for coordinating the response, and staff who already knew how to run a hospital on paper.

Frequently asked questions

What does responding to hospital ransomware actually involve?

It is the set of decisions and actions a hospital takes once an attack is already underway or already discovered: isolating affected systems, deciding whether to restore from backup or negotiate, keeping patient care running through manual processes, and coordinating with outside authorities. It is a distinct problem from prevention, and hospitals that are good at one are not automatically good at the other.

Why are hospitals targeted by ransomware so often?

Hospitals run on shared, interconnected systems that need to stay available around the clock, which makes an outage unusually disruptive to patient care and creates pressure to restore systems fast. Many hospitals also rely on decades-old software that is difficult to replace without interrupting patient care, which leaves known vulnerabilities unpatched for longer than in other industries.

Should a hospital ever pay the ransom?

In this case, DNSC’s recommendation was not to pay, and the hospitals followed that advice because their backups let them recover without it. Security agencies such as the US government’s CISA cybersecurity agency and the FBI generally advise the same, for three reasons: paying does not guarantee a working decryption tool, it funds further attacks, and it creates an incentive to be targeted again. The decision usually comes down to whether reliable backups already exist, which is exactly why testing them in advance matters more than the payment decision itself.

How long does it realistically take a hospital to recover from ransomware?

In Romania’s case, hospitals were close to normal operation in about five days, but re-entering the backlog of paper records into digital systems took weeks longer. Recovery speed depends far more on whether backups are current and restorable than on the severity of the attack itself.

What can a hospital actually do to prepare for this?

The recurring lesson across hospital ransomware cases, not just this one, is to keep backups that are regularly tested and provably restorable, maintain a rehearsed manual fallback that staff have actually practiced rather than just read about, and know in advance which outside authority or incident response team to call. None of those require exotic technology, which is part of why they are so often skipped.

The takeaway for hospital IT teams

The most striking thing about Romania’s outcome is how little of it depended on stopping the attack. The hospitals were still breached, the ransom demand still arrived, and the shared software was still compromised. What kept the incident from becoming a tragedy was decided months earlier: whether backups had been tested, whether a national authority had a playbook ready to coordinate the response, and whether staff had actually rehearsed running a hospital on paper. Any hospital reading this as a story about ransomware software is missing the point. It is a story about which decisions get made before the attack, because by the time the attack starts, those decisions are the only ones still available.