Forty Servers Down and a 72-Hour Clock
At 03:10 on a Saturday, ransomware detonated across 40 of 300 servers at a regional hospital system, encrypting the clinical documentation and imaging platforms. The backup appliance was domain-joined and its catalog is encrypted. A DR site exists, but its last successful replication was six weeks ago. The actor claims to have exfiltrated 80 GB including patient records and demands payment within 72 hours. Clinical staff have moved to paper. The CEO wants the entire network shut down; the CMO says paper operations become unsafe after roughly 24 hours. The general counsel asks whether notification is required by Monday.
1. Should the CEO's instruction to shut down the entire network be followed as stated?
Read the worked answer
Follow the intent (stop spread and preserve patient safety) but not the literal instruction, because a flat shutdown can itself be the patient-safety event the CMO is warning about.
Recommended position:
- Segment and isolate rather than flatten. Identify affected network zones and cut them; keep clinical systems that support care, pharmacy, and life-safety running where they are provably unaffected.
- Preserve evidence on affected hosts before remediation - memory and logs - because attribution, scope, and notification obligations all depend on it, and rebuilds destroy it.
- Verify the backup and DR position immediately; six-week-old replication means DR restore is a data-loss decision the clinical and legal sides must be briefed on, not a silent IT choice.
- Engage the retained IR firm and insurer now, and confirm decision authority explicitly: the incident commander runs the response, the CEO owns business decisions, the CMO owns clinical safety.
On payment: do not decide under a 72-hour clock. The common exam trap is treating payment as a technical decision; it is a legal, regulatory, and ethical one requiring counsel, insurer, and executive sign-off.
2. The general counsel asks whether notification is required by Monday. How should the incident commander frame the answer?
Read the worked answer
Do not answer yes or no on incomplete facts, and do not let the question become a reason to slow the response. Frame it as facts, obligations, and deadlines in parallel.
- Facts known now: 40 servers encrypted, clinical platforms affected, actor claims 80 GB exfiltrated including patient records. A claim is not confirmation, but it is enough to start the regulatory clock analysis.
- Obligations: patient-notification and regulator-notification duties typically attach to confirmed or reasonably suspected unauthorised access to personal health information, with statutory clocks running from discovery - not from the end of forensics. Legal owns the determination; security supplies evidence continuously.
- What must not happen: waiting for a complete forensic picture before telling legal, or letting legal caution stop containment.
The practical output by Monday is a documented determination: which regimes apply, what is confirmed versus alleged, what the notification deadlines are, and what evidence would change the answer. If the deadline is genuinely triggered and facts are uncertain, many regimes permit notification with an initial description and updates - silence is usually the costlier error.
3. How should communications and decision rights be structured through the first 72 hours?
Read the worked answer
Incident response fails on ambiguity more often than on technology. Establish, in writing and circulated within hours:
- One incident commander with named authority over technical containment; the CEO sets business posture, the CMO sets clinical operating mode, legal owns disclosure. Deputies named for each.
- A fixed cadence - e.g., executive briefings every four hours for the first 24, then twice daily - with a single source of truth so the CEO and CMO stop negotiating in real time.
- A single external voice, briefed by legal, so staff, regulators, patients, and press get consistent statements; clinical staff need scripts for paper-mode questions.
- A decision log recording who decided what and when, which protects the organisation and produces the timeline regulators will ask for.
Also pre-agree the escalation triggers that change the response posture (e.g., proof of exfiltration, new encryption events, DR restore failure). The 72-hour ransom deadline should be treated as an adversary's scheduling preference, not the organisation's decision deadline.