Ransomware at a hospital with offline tapes and a 72-hour clock
At 21:40 on a Friday, a hospital's service desk receives reports that radiology images will not open. By 22:15, the electronic patient record is read-only, and a ransom note demands payment within 72 hours. The on-call analyst finds that a domain controller and 40 servers are encrypted, and that the backup catalogue server is also encrypted. Backups are stored on tapes in a fire safe and in an object-storage bucket; the bucket credentials were found in a script on an admin workstation. The last successful restore test was 14 months ago. The hospital has 600 beds, an active emergency department, and a regulatory duty to notify the data-protection authority within 72 hours of confirming a personal-data breach. The CEO wants to pay the ransom to restore services before Monday. The insurer says it will cover negotiation but not payment. The incident-response plan names a crisis team but has no decision log or pre-agreed thresholds for taking clinical systems offline.
1. What are the first 12 hours' priorities? Address containment, clinical safety, evidence and the ransom decision.
Read the worked answer
First 12 hours. Declare a major incident and run it from a known-good communication channel. The first priority is clinical safety: activate downtime procedures, confirm ambulance diversion if needed, and give ward teams paper workflows and a single point of contact. In parallel, contain: isolate affected network segments, disable compromised accounts, block command-and-control indicators, and protect the offline tapes by taking them out of the library process and documenting the chain of custody. Preserve evidence before rebuilding: memory and disk images of at least one domain controller, central logs, the ransom note, and the admin workstation with the bucket credentials.
Backups. Revoke the object-storage credentials and check versioning, object lock and access logs. Assume the bucket was read or deleted. The tapes are the most credible clean copy, but the last restore test was 14 months ago, so test a restore into an isolated clean room before promising a recovery time.
Ransom decision. It is not an IT decision. Convene the CEO, clinical leadership, legal, the insurer, law enforcement and the board. Decide against criteria: estimated clean restore time, clinical harm from continued downtime, evidence of exfiltration, legal or sanctions exposure, and whether payment would even produce a working decryptor. Log the options and the decision. Paying does not remove the 72-hour notification duty if personal data was breached; that clock is separate. Start the breach assessment now.
2. The CEO says paying is faster than restoring. How do you structure the decision and what evidence do you need?
Read the worked answer
Structure the decision as two parallel tracks with a decision deadline, not a binary bet. Track A is recovery: clean-room restore from tape, rebuild Active Directory, reset privileged credentials, and bring back the most clinically critical systems first. Track B is negotiation and legal: insurer, counsel, law enforcement and sanctions screening. The CEO should see both timelines side by side.
Evidence needed: a tested restore time for the record system and radiology, not a vendor estimate; the last known good backup point and likely data loss; a forensic view on whether data was exfiltrated; the attacker's demonstrated capability and any decryptor test on a sample; the hospital's legal and regulatory exposure; and the insurer's position. Also get clinical input on the harm of another 24 hours of downtime versus a partially restored service.
Set a hard review point, for example 12 hours, and record dissent. If payment is considered, use the negotiator, do not pay without sanctions checks, and do not assume the decryptor works. The decision must be made by the accountable executive with advice, because the security team cannot own the clinical and legal consequences. Paying does not buy immunity from notification, and it may fund the next attack.
3. What changes should follow to make the next incident faster and safer?
Read the worked answer
The post-incident programme should fix the failures that made this crisis: backup credentials stored in a script, a backup catalogue on the domain, no immutable copy, and no tested restore for 14 months. Move to immutable, offline or object-locked backups with separate credentials and MFA for backup administrators; test a restore quarterly and publish the result. Segment backup infrastructure from the domain, remove standing admin rights, and deploy endpoint detection with central monitoring.
Prepare the decisions in advance. The incident plan needs pre-agreed clinical downtime thresholds, a named decision-maker for ransom, a decision log template, call trees, and a communication plan for regulators and patients. Run a tabletop with clinicians, not just IT. The 72-hour notification test should be exercised with the data protection officer. Finally, track recovery time objectives by clinical system and report them to the board, because the next incident will be judged on restore speed and patient safety, not on whether the ransom note was deleted.