Continuity and Downtime (CD)

Continuity and Downtime (CRI-CD), The Hospital: a radiograph of a server rack beside a clock.

Taxonomies › Hospitals and medical devices › Continuity and Downtime

The Hospital · CRI-CD · suit 17 of 17 · 13 entries

Estate-wide ransomware, shared services, backups, restore validation, downtime procedures and copies, diversion, incident communications and extortion.

Scope: Ransomware across the estate, downtime procedures that nobody has practised, paper fallback and its reconciliation, read-only downtime copies, diversion and its knock-on to neighbours, backups and their integrity, restore order, recovery validation of clinical data, shared services (pathology, imaging, IT) as single points, extortion and leak sites, incident command, staff exhaustion, regional surge, insurance and payment.

Entries are ranked Ace (most severe) to 2. In the taxonomy the ID is a stable reference, not a severity: rate each finding in your own system.

Continuity and Downtime: each entry's ID, title, threat, mitigation principle and design measures. The full text follows below.

Text version: every entry is written out below, with its card prompts and mappings. The same text is in the PDF and Excel downloads on the overview page.

The threats

CRI-CD-A Ransomware takes the whole estate

† Wrong or delayed treatment

Threat. Clinical and corporate systems share networks, accounts and management tools, so ransomware reaches records, imaging, labs, pharmacy and device servers at once. The hospital loses sight of its patients, diverts ambulances and cancels care for weeks while everything is rebuilt.

Principle. Design so that losing the corporate estate leaves a core of clinical care running.

Design measures:

  1. Segment clinical systems and devices so that a compromise of office IT cannot encrypt them.
  2. Define the minimum clinical service that must survive and engineer its systems to run in isolation.
  3. Rehearse an estate-wide outage with clinicians, not only IT, at least yearly.

Card prompts:

  • Which clinical services would keep running if the corporate estate fell?
  • What do clinical and corporate systems share: accounts, tools, networks?
  • How long would rebuilding the core clinical services take?

Mappings: STRIDE D, T · CAPEC-441 · CWE-1220 · ATT&CK T1486, T1489, T1490 · MDS2 MLDP, DTBK · IEC 80001-1; ISO 27799

CRI-CD-K A shared service stops many hospitals

† Wrong or delayed treatment

Threat. Pathology, imaging, radiotherapy planning or IT is provided by one company or one hub for many hospitals. When it is attacked, every hospital it serves loses that service together, with no local fallback, and operations, transfusions and cancer treatment stop across a region.

Principle. No single supplier or hub should be able to stop a clinical service across a region without a tested fallback.

Design measures:

  1. Map which clinical services depend on a shared provider and what each hospital does without it.
  2. Contract for and test fallback capacity, such as mutual aid between laboratories or a second planning system.
  3. Require shared providers to show segregation between customers so one attack does not stop all of them.

Card prompts:

  • Which clinical services come from one supplier shared by many hospitals?
  • What local fallback exists if that supplier is attacked?
  • Who coordinates across the region when a shared service fails?

Mappings: STRIDE D · CWE-1357 · ATT&CK T1199, T1486 · MDS2 DTBK · IEC 80001-1

CRI-CD-Q Backups reachable from what they protect

† Wrong or delayed treatment

Threat. Backups of records, images and device configurations are online, writable and run by the same accounts as production. Attackers find and destroy them before encrypting, so restoring takes weeks of rebuilding rather than days of recovery.

Principle. At least one copy of every clinical system’s data and configuration survives a full compromise of the estate.

Design measures:

  1. Keep immutable or offline copies managed by separate credentials that the main directory cannot reach.
  2. Back up device configurations, drug libraries and interface definitions, not only databases.
  3. Test full restores of clinical systems on a schedule and time them.

Card prompts:

  • Which backups would survive a full compromise of the estate?
  • Do backups use the same accounts as production?
  • How long would a restore from the offline copy take?

Mappings: STRIDE D, T · CAPEC-607 · CWE-732 · ATT&CK T1490, T1485 · MDS2 DTBK · IEC 80001-1; ISO 27799

CRI-CD-J Restored data nobody has checked

† Wrong or delayed treatment

Threat. After an outage, systems are restored from backups and paper records are typed back in, but nobody checks that results, orders, allergies and medication histories are complete and unaltered. Missing or tampered clinical data flows back into care looking trustworthy.

Principle. Recovered clinical data is verified as complete and unaltered before clinicians rely on it.

Design measures:

  1. Hash and sign clinical data at backup so restored records can be checked for tampering.
  2. Reconcile results, orders and medication given during downtime against the restored record, with clinical sign-off.
  3. Flag records touched during the outage window so clinicians know to double-check them.

Card prompts:

  • How do you check that restored clinical data is complete?
  • Who verifies records typed back in from paper?
  • Could tampered data return with the restore unnoticed?

Mappings: STRIDE T, R · CAPEC-184 · CWE-354, CWE-353 · ATT&CK T1565.001 · MDS2 IGAU, DTBK · IEC 80001-1

CRI-CD-10 Downtime procedures nobody has practised

† Wrong or delayed treatment

Threat. Paper forms, manual ordering, handwritten labels and runners exist on paper but have never been tried at scale. When systems go down for weeks, staff improvise, errors multiply in prescribing, identification and results, and staff exhaust themselves keeping it running.

Principle. Manual working is a planned, practised and staffed mode of the hospital, not an improvisation.

Design measures:

  1. Keep downtime packs on every ward with forms, label stock and contact lists, checked monthly.
  2. Run downtime drills that include pharmacy, labs, imaging and portering, and record what failed.
  3. Plan rotas and extra staff for long outages so manual working is sustainable for weeks.

Card prompts:

  • When were downtime procedures last practised at scale?
  • Who staffs runners, manual ordering and paper reconciliation?
  • How long could manual working last before errors climb?

Mappings: STRIDE D · ATT&CK T0826 · MDS2 DTBK · IEC 80001-1

CRI-CD-9 Devices that stop without their server

† Direct harm

Threat. Devices need a licence server, drug library server, worklist or vendor cloud to start or keep working. When the back end is encrypted or cut off, pumps, modalities and analysers refuse to run or lock into unsafe defaults, though they could work alone.

Principle. A device that can treat or diagnose safely on its own keeps doing so when its back end is gone.

Design measures:

  1. Require devices to keep working in a safe local mode, with their last good configuration, when servers are lost.
  2. Ask suppliers about back-end dependencies and grace periods in procurement and test them before go-live.
  3. Document how to run each critical device without its network, and practise it.

Card prompts:

  • Which devices refuse to start without their server or licence?
  • What defaults do devices fall back to when the back end is gone?
  • Could these devices treat or diagnose safely on their own?

Mappings: STRIDE D · CWE-754, CWE-1357 · ATT&CK T0826, T0816 · MDS2 DTBK, CONN · IEC 80001-1; IEC TR 60601-4-5; FDA premarket

CRI-CD-8 Diversion overloads the neighbours

† Wrong or delayed treatment

Threat. A hospital that loses its systems diverts ambulances and transfers to nearby hospitals, which are already busy. Travel times rise for critically ill patients and the neighbours run short of beds and staff, so one attack degrades emergency care across a region.

Principle. Regional plans assume a hospital can be lost to a cyberattack and share the load before it lands.

Design measures:

  1. Agree cyber diversion triggers and capacity with neighbouring hospitals and ambulance services in advance.
  2. Keep a way to update diversion status that does not depend on the affected hospital’s systems.
  3. Plan which time-critical services, such as stroke and cardiac care, must stay open and how.

Card prompts:

  • Which neighbouring hospitals absorb your patients if you divert?
  • Do regional plans assume a hospital lost to a cyberattack?
  • How is the extra load shared before it lands?

Mappings: STRIDE D · ATT&CK T0826 · IEC 80001-1

CRI-CD-7 One update takes the estate down

† Wrong or delayed treatment

Threat. A trusted security agent, operating system or management tool pushes a faulty or malicious update to every machine at once. Clinical workstations, servers and device consoles fail together, and the hospital cannot recover them faster than it can visit each one.

Principle. Updates reach critical clinical systems in stages, with a way to stop and roll back before all are affected.

Design measures:

  1. Stage updates to clinical systems in rings, holding critical areas back until earlier rings are healthy.
  2. Keep a tested way to recover machines in bulk without the failed tool, such as rebuild images on local media.
  3. Hold a minimum set of devices on a different platform or update channel for continuity.

Card prompts:

  • Which tools can push an update to every machine at once?
  • Are updates staged so critical systems can be held back?
  • How quickly could you stop and roll back a bad update?

Mappings: STRIDE D, T · CAPEC-186 · CWE-494 · ATT&CK T1195.002 · EMB3D TID-217 · MDS2 CSUP, DTBK · IEC 80001-1

CRI-CD-6 Downtime copies that go down too

† Wrong or delayed treatment

Threat. Read-only downtime viewers, medication lists and printed reports depend on the same network, directory or storage as the main record. When the outage comes they are encrypted or stale, and clinicians lose allergies, drug charts and care plans exactly when they need them.

Principle. Downtime copies are independent of the systems whose failure they cover.

Design measures:

  1. Keep downtime copies on standalone devices per ward, refreshed often and not joined to the main directory.
  2. Print or cache critical summaries such as medication charts and allergies on a schedule.
  3. Test that downtime copies open with the network, directory and main storage all unavailable.

Card prompts:

  • What do downtime viewers and printed reports depend on?
  • Would downtime copies survive the same outage as the record?
  • How current are the downtime copies at any moment?

Mappings: STRIDE D · LINDDUN DD · CWE-1357 · ATT&CK T1486 · MDS2 DTBK, STCF · IEC 80001-1

CRI-CD-5 Incident communications on compromised systems

† Wrong or delayed treatment

Threat. The incident plan relies on email, VoIP phones, paging and the intranet to call staff in and coordinate. Those same systems are down or untrusted, so command cannot reach staff, the ambulance service or the public, and attackers may read the response.

Principle. The hospital can command its response with systems that do not share the fate of the ones under attack.

Design measures:

  1. Provide out-of-band communications for incident command, such as separate phones, radios or a hosted service.
  2. Keep printed contact lists and call-in cascades that work without the directory.
  3. Assume email and chat are being read during an incident and move sensitive decisions off them.

Card prompts:

  • How would incident command reach staff with email and phones down?
  • Which communication channels share fate with the systems under attack?
  • Could attackers be reading the response?

Mappings: STRIDE D, I · ATT&CK T1489 · IEC 80001-1

CRI-CD-4 No planned restore order

Threat. Nobody has worked out which systems must come back first and what they depend on. Teams restore systems that cannot run without the directory, DNS, integration engine or certificates, and clinical priorities wait behind whatever IT reaches first.

Principle. The restore order follows clinical priority and real technical dependencies, both written down and tested.

Design measures:

  1. Map dependencies of each clinical system, including identity, DNS, time, integration and licences.
  2. Agree a restore order with clinical leads and keep it with the backups, offline.
  3. Rehearse restoring the top tier of clinical services from bare infrastructure.

Card prompts:

  • Which systems must be restored first for clinical care?
  • What technical dependencies does each priority system have?
  • When was the restore order last tested?

Mappings: STRIDE D · ATT&CK T1490 · MDS2 DTBK · IEC 80001-1

CRI-CD-3 Extortion deadlines rush the recovery

† Wrong or delayed treatment

Threat. Attackers set publication deadlines and contact staff, patients and the press while the hospital is still restoring. Under that pressure leaders skip validation, restore from unchecked backups or reconnect early, and the attackers’ access or damaged data comes back with the services.

Principle. Recovery steps are decided on clinical and technical evidence, not on the extortion clock.

Design measures:

  1. Agree in advance who decides on reconnection and what evidence they need, independent of any ransom deadline.
  2. Prepare holding statements and patient lines so publication threats do not drive technical decisions.
  3. Rebuild from known-good images and verified backups even when that is slower than restoring in place.

Card prompts:

  • Who decides on reconnection, and on what evidence?
  • How will publication threats be handled without driving technical choices?
  • Will you rebuild from known-good images even if it is slower?

Mappings: STRIDE T, D · ATT&CK T1657, T1486 · MDS2 DTBK · IEC 80001-1

CRI-CD-2 Payments and claims stop flowing

Threat. Claims, eligibility checks and pharmacy payments run through a single clearing service or payer platform. When it is attacked, providers cannot verify cover or get paid, pharmacies cannot dispense on account, and smaller practices run out of cash within weeks.

Principle. Clinical care continues when payment and eligibility services do not, and providers can survive a long payment outage.

Design measures:

  1. Agree with payers how care is authorised and paid when eligibility services are down.
  2. Keep a second route to submit claims and check cover, tested at least yearly.
  3. Plan financial reserves or emergency funding for a payment outage of several weeks.

Card prompts:

  • Which payment or eligibility service would stop dispensing or billing?
  • How long could smaller providers survive without payments?
  • Can care continue when cover cannot be checked?

Mappings: STRIDE D · CWE-1357 · ATT&CK T1486

Seen in the wild

Mappings

Continuity and Downtime: the mappings of each entry to STRIDE, LINDDUN, CAPEC, CWE, ATT&CK, EMB3D, MDS2 and standards.

Across the 13 entries, the STRIDE counts are Denial of service 12, Tampering 5, Repudiation 1, Information disclosure 1 (an entry can carry more than one). 4 map to CAPEC 3.9, 8 to CWE 5.0, 13 to ATT&CK v20.0, 1 to MITRE EMB3D and 1 to LINDDUN. The MDS2 capabilities a buyer should check first are DTBK (10), MLDP (1), IGAU (1). 1 carry the red † for direct harm and 10 the amber † for wrong or delayed treatment. A blank means nothing fitted well; a loose tag would mislead.

← Identity and Access · Hospitals and medical devices overview · Structural hazards →

© 2026 Jonathan Brett Crawley. Licensed under CC BY-NC-ND 4.0 with additional permissions: see the licence on the hospitals and medical devices overview.