Ransomware readiness for hospitals

For most organisations, ransomware is a business continuity problem. For a hospital it is a patient safety problem. Laboratory results stop arriving, records cannot be opened, imaging is unavailable and medication charts may be lost at the moment they are needed. Readiness therefore has two goals that must be pursued together: reduce the chance and spread of an attack, and make sure that care can continue safely while systems are down and then restored.

Backups that survive the attack

Modern ransomware operators look for backups first and destroy or encrypt them before triggering the main attack. A backup that sits on the same network, uses the same administrator accounts or can be deleted from the same console is not a recovery plan. At least one copy of critical data must be offline or immutable: written to media that is physically disconnected, or to storage that cannot be altered or deleted for a set retention period, even by an administrator. Encrypt backups, and store the keys somewhere that does not depend on the systems being recovered.

• Identify the systems care depends on: patient records, laboratory, pharmacy, imaging, scheduling and identity services.
• Keep separate credentials for backup administration, protected by multi-factor authentication and not used for anything else.
• Back up configuration and identity systems, not only data, because restoring a database is useless without the directory that authenticates users.
• Document the order in which systems must be restored, based on clinical priority rather than technical convenience. Keep a copy of the restoration runbook offline alongside the backups.

Test restores, not backups

A backup job that reports success proves only that data was written somewhere. Readiness is proved by restoring. Schedule regular restore tests of each critical system into an isolated environment, have clinical or departmental users confirm that the restored data is complete and usable, and record how long each restore took. Those timings are the real recovery time, and they should inform both the downtime procedures and any conversation with leadership about acceptable risk.

A backup job that reports success proves only that data was written somewhere. Readiness is proved by restoring.

Segment clinical devices and contain legacy systems

Hospitals run many devices that cannot be patched or protected like ordinary computers: imaging modalities, laboratory analysers, infusion pump servers and monitors, often running old operating systems certified by the manufacturer. Place them on dedicated network segments, allow only the specific connections they need, and block their access to the internet and to general office networks. Maintain an inventory of every connected medical device, its owner, its software version and the manufacturer’s support status. Segmentation does not prevent an attack on the office network, but it can stop an attack from reaching the bedside. Monitor the boundaries between segments, because unexpected traffic from a clinical device is often the earliest sign that something is wrong. Patch what can be patched, quickly, starting with internet-facing systems, remote access gateways and identity infrastructure, which are the usual points of entry. For systems that cannot be patched, record the reason, apply compensating controls such as segmentation and strict access lists, and work with the manufacturer on a replacement or upgrade plan. An unpatched system that is documented and contained is a managed risk; one that nobody knows about is an open door.

Downtime procedures on paper

Every clinical area should be able to work for days without its systems. That requires preparation that is unglamorous and essential:

• Printed downtime forms for admissions, orders, results, medication administration and discharge, stored where staff can find them.
• A regularly refreshed, securely stored summary of current inpatients and their medications that can be accessed when systems are unavailable.
• Clear manual processes for laboratory and imaging requests and for communicating critical results.
• A procedure for entering paper records back into systems after recovery, with responsibility assigned.

Incident roles and exercises

Decide before an incident who does what during one. A typical structure separates an incident lead who coordinates, a technical lead who directs containment and recovery, a clinical lead who decides how care adapts, a communications lead for staff, patients and media, and a liaison for legal, regulatory and law enforcement contact. Each role needs a named deputy. Keep contact details and the plan itself available offline, because the systems that hold them may be the ones encrypted. Decide in advance how the organisation will approach any ransom demand, with legal advice, rather than under pressure at the worst moment. Agree too who may authorise disconnecting systems or the whole network from the internet, because that decision must be taken quickly and will affect clinical services. Include external parties in the plan: system suppliers, internet providers, insurers and any national computer emergency response team, with contact routes that do not depend on the hospital’s own email. Prepare template messages for staff and patients in advance, so that the first communications are accurate and calm rather than improvised. Tabletop exercises bring the people in those roles together to walk through a realistic scenario, hour by hour. They reveal the gaps no document review will: the contact number that is out of date, the ward that never received downtime forms, the decision nobody has authority to make. Run them regularly, include clinical staff and executives, and turn every finding into a tracked action. A plan that has never been exercised is a hypothesis; a plan that has been exercised and improved is readiness.

Where to start

Hospitals with limited budgets and staff cannot do everything at once, and should not try. A sensible order is to protect identity first, with multi-factor authentication on remote access and administrator accounts; then to secure at least one offline or immutable copy of the systems care depends on and prove it can be restored; then to put paper downtime packs in every clinical area. Segmentation, patching programmes and regular exercises follow. Frameworks such as the NIST Cybersecurity Framework and ISO 27001 provide a structure for tracking this work over time, but the early steps matter most, because they decide whether an attack becomes an inconvenience or a crisis.