Hospital Ransomware Protection: Lessons From Change Healthcare and AIIMS

Hospital ransomware protection used to be filed under IT hygiene. Three incidents changed that. In November 2022, AIIMS Delhi lost its digital services for about two weeks. In February 2024, the attack on Change Healthcare disrupted claims and pharmacy processing across the US and eventually affected the data of 192.7 million people. In June 2024, the attack on Synnovis, a pathology provider to London hospitals, disrupted blood testing and was later linked by the NHS as a contributing factor in a patient's death.

None of these attacks used exotic techniques. They exploited missing multi-factor authentication, networks where one compromise could spread everywhere, and hospitals without a tested way to keep working when systems went dark.

This guide draws the practical lessons from each, sets out the controls that matter most for hospitals, and gives a 90-day plan. It complements our DPDP Act data security checklist, which focuses on privacy obligations rather than attack resilience.

Three incidents, three lessons

AIIMS Delhi: segmentation

When staff found the e-Hospital server down on 23 November 2022, the hospital had to revert to manual registration, sample collection and billing. CERT-In's preliminary findings reportedly attributed the spread to improper network segmentation, which let the infection reach critical applications. Recovery took about two weeks and involved new servers, isolation of infected systems, and work with CERT-In and NIC.

The lesson for Indian hospitals is direct: if your HMIS database, PACS, lab analysers and office PCs sit on one flat network, a single phishing click can reach everything.

Change Healthcare: identity

The ALPHV/BlackCat group entered through a Citrix remote access portal that lacked multi-factor authentication, then moved through the network for nine days before deploying ransomware. In July 2025, the breach total reported to the US Office for Civil Rights was revised to 192.7 million individuals (Becker's), the largest healthcare breach reported in the US.

The lesson: every remote access path, including vendor support accounts, needs MFA, and nine days of undetected movement means nobody was watching the logs.

Synnovis: dependency and fallback

The Qilin group's attack on Synnovis disrupted blood tests and transfusions at multiple NHS hospitals. The South East London integrated care board reported 170 cases of patient harm, two classified as severe, and in 2025 the NHS confirmed that delays in blood test results were among the contributing factors in a patient's death at King's College Hospital (The Record).

The lesson: your resilience is only as good as your critical suppliers', and paper fallback must be planned and practised before it is needed.

The controls that matter most

Hospitals cannot do everything at once. These controls address the failure points in all three incidents, roughly in order of impact for effort:

1. MFA on every remote and privileged access path. VPNs, remote desktop gateways, email, cloud consoles, vendor support accounts and administrator logins.
2. Network segmentation. Separate clinical systems (HMIS, LIS, PACS), medical devices, administrative PCs, guest Wi-Fi and servers. Allow only the flows each system needs.
3. Immutable, offline-tested backups. At least one backup copy that ransomware cannot reach or alter, with documented restore tests of the HMIS database at least quarterly.
4. Endpoint detection and response (EDR) on servers and workstations, with someone actually reviewing alerts, in-house or through a managed service.
5. Centralised logging from firewalls, servers, Active Directory and key applications, kept long enough to investigate.
6. Patch and remove exposed services. Internet-facing remote access, old VPN appliances and unpatched servers are the usual entry points.
7. Privileged access management. Separate admin accounts, no shared passwords, and vendor accounts disabled when not in use.
8. Third-party risk. Know which suppliers can take you down (lab, PACS, cloud HMIS, payment) and what their resilience and notification commitments are.
9. Downtime procedures. Paper forms, read-only record access and manual workflows for registration, lab, pharmacy and billing, rehearsed with staff.

Regulatory obligations to plan for

The CERT-In directions apply widely, and six hours is short. If your first conversation about who reports to CERT-In happens during an attack, you will miss the window.

Where hospital software design helps

Some resilience comes from how clinical software is built, not only from security tools. When we build hospital systems at Algon, we design for:

• Role-based access with MFA for remote and privileged users, built into the application, not bolted on.
• Read-only downtime views: a local, regularly refreshed export of key patient data (active inpatients, medication charts, allergies) that clinicians can use if the main system is unavailable.
• Audit logs for every access and change, retained and exportable for investigations.
• Clean separation between the application, database and integration layers, so the integration engine and external connections do not expose the core database.
• Tested restore paths: database backups and infrastructure as code so an environment can be rebuilt quickly. Our DevOps in healthcare work covers this.

Cloud hosting changes the shape of the risk rather than removing it. Our cloud vs on-premise HMS comparison discusses the trade-offs, including backup and recovery.

A 90-day plan for a 100-300 bed hospital

Expect resistance on MFA and segmentation, usually from vendors with remote support access and from departments with old devices. Those are the exact paths attackers use.

Questions the board should ask

Ransomware resilience fails most often for governance reasons, not technical ones. Hospital boards and owners do not need to understand firewalls, but they should ask these questions every quarter and expect clear answers:

1. Is MFA enabled on every remote access path, including vendor accounts? The answer should be "yes, all of them", with a list of exceptions and a date to close each.
2. When did we last restore the HMIS from backup, and how long did it take? If nobody knows, the backups are an assumption, not a control.
3. If the HMIS went down at 9 a.m. on a Monday, what would OPD, lab, pharmacy and billing do? Ask to see the downtime forms and the date of the last drill.
4. Which three suppliers could stop us working, and what do their contracts say about security and notification? Lab, PACS, cloud and payment providers are typical answers.
5. Who reports to CERT-In within six hours, and who decides on patient notification? Named people, not departments.
6. What did the last security review find, and what has been fixed? Progress against findings matters more than the number of findings.

These questions fit naturally into NABH-style quality and risk reviews. Treat cyber risk the way you treat infection control: as a patient safety risk with an owner, metrics and regular reporting. Our hospital KPIs dashboard guide shows how to put operational risk measures alongside clinical and financial ones.

Indicative effort and cost drivers

Costs depend heavily on size, existing infrastructure and whether you use managed services. The biggest drivers are: the number of sites and network complexity; whether EDR and log monitoring are handled in-house or through a managed security provider; the age of servers and medical devices that cannot be patched; and staff time for drills and training. Many of the most effective steps, MFA, disabling unused accounts, restore testing and downtime drills, cost more in attention than in money.

Conclusion

AIIMS Delhi, Change Healthcare and Synnovis show that hospital ransomware is a patient safety problem, not only an IT problem. The fixes are known: MFA on every remote path, segmented networks, immutable backups that have actually been restored, monitored endpoints and logs, managed third-party risk, and downtime procedures staff have practised.

Start with the 90-day plan, give someone senior ownership, and report progress to the board like any other clinical risk. If you want help designing resilience into your hospital systems, contact us.