How should healthcare organisations build cyber resilience when attacks are inevitable?

Healthcare organisations should assume attacks will happen and focus on sustaining operations through them. That means defining recovery priorities, practicing incident response, and maintaining business continuity plans that can keep critical services running while systems are cleaned up and restored. Resilience is not only about preventing breach impact, but about limiting disruption, protecting customers, and reducing the business cost of loss.

Assume outages are part of the design problem

Healthcare resilience starts with accepting that prevention will fail sometimes and that the real test is whether clinical, administrative, and operational services can keep functioning under stress. The practical question is not only how to stop intrusions, but how to keep patient care, scheduling, prescribing, imaging, and lab workflows moving when core systems are degraded or unavailable.

That requires identifying the services that must survive first, then building resilience around them rather than around every system equally. A hospital can tolerate delayed reporting longer than interrupted medication delivery, and it can tolerate manual workarounds in some departments faster than others. The stronger the dependency on digital systems, the more important it is to define which fallback process is acceptable before the incident starts.

Recovery priorities, continuity plans, and recovery time objectives

Recovery planning becomes effective when it is tied to business impact, not just technical infrastructure. Healthcare organisations need a clear order for restoring identity services, EHR access, clinical messaging, imaging, and supporting platforms so that restoration work reflects operational dependency, not whoever calls the loudest during an incident.

Business continuity planning should also cover the period between disruption and full restoration. That means knowing when paper-based or offline procedures are acceptable, who authorises their use, how long they can remain in place, and what conditions require escalation back to emergency operations. The most useful plans are explicit about recovery time objectives, manual fallback thresholds, and the point at which an apparently “working” degraded service becomes clinically unsafe.

Resilience improves when recovery priorities are rehearsed against realistic failure modes, including ransomware, data corruption, cloud service outage, and local network loss. ENISA Threat Landscape is useful here because it frames the kinds of disruptive events healthcare and other critical sectors actually need to plan for, not just the ones that look clean on paper.

Operational resilience depends on practice, not documentation

Incident response plans only build resilience when people have exercised them under pressure. Tabletop discussions are useful for decision-making, but healthcare organisations also need drills that test communications, escalation paths, access recovery, and the switch to continuity procedures in the middle of a realistic workload. If staff cannot execute the plan without searching for it, the plan is not yet a control.

That practice should include technical restoration and operational handoff. It is not enough to restore servers if clinicians still cannot trust data integrity, or if the help desk cannot safely re-establish access, or if leaders cannot tell which systems are clean enough to reconnect. A resilient response process separates containment, verification, and restoration so that the organisation does not rush a compromised service back into production prematurely.

Practical readiness also includes maintaining visibility into known exploit paths and product weaknesses that can turn an incident into a prolonged outage. CISA Known Exploited Vulnerabilities Catalog helps teams prioritise remediation on vulnerabilities that are already being abused, which matters because a healthcare environment can be resilient on paper and still fall over quickly if exposed systems remain vulnerable.

Risk and Threat Considerations

Healthcare organisations face a dual risk: disruption to patient care and compounding exposure during recovery. Attackers often exploit the fact that clinical operations cannot simply stop, so prolonged downtime, hurried restoration, and fallback procedures can create new operational and security weaknesses at the same time.

Failure mechanism: The common failure is not a single breach, but a chain of service loss, partial restoration, and unsafe trust in systems that have not yet been fully validated. If recovery priorities are unclear or continuity procedures are untested, teams may restore the wrong services first, reintroduce compromised systems too early, or rely on manual workarounds longer than they are safe.

Impact: The result can be delayed care, cancelled procedures, lost clinical confidence, regulatory exposure, and higher recovery cost. In severe cases, an organisation can regain system availability before it regains operational safety, which is a dangerous form of false recovery.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	RC.RP-01 — Response Plan Execution	Healthcare resilience hinges on executing recovery and continuity plans during attacks.
	RC.IM-01 — Improvements Are Incorporated	Repeated incident learning is needed to improve continuity and restoration after disruptions.
	RC.CO-03 — Public Updates Are Coordinated	Healthcare incidents require coordinated communications during service disruption and recovery.
Recommendation — Exercise and maintain recovery plans so critical services can be restored in the required order. Update response and recovery procedures after each exercise or incident. Coordinate recovery communications so staff and stakeholders receive consistent status updates.
ISO/IEC 27001:2022	A.5.29 — Information security during disruption	The question is about sustaining operations while systems are impaired.
	A.5.30 — ICT readiness for business continuity	Resilience depends on continuity planning, restoration sequencing, and testable recovery readiness.
Recommendation — Define security controls that remain effective while continuity procedures are in use. Maintain and test ICT continuity arrangements for critical healthcare services.

Practitioner Guidance

What to prioritise: Start with the workflows that directly affect patient safety and revenue continuity, not the systems that are easiest to restore. Define a short list of critical services, set recovery order explicitly, and make the fallback path for each one visible to clinical and operational leaders.

What to verify: Test whether the continuity plan actually works when key dependencies are unavailable, including authentication services, network segmentation, communications, and data validation. A good exercise proves that people can move to the fallback mode, operate in it, and exit it without guesswork.

What practitioners underestimate: The hardest part is often not restoration, but deciding when a service is trustworthy enough to use again. Recovery should be treated as a controlled re-entry into production, with validation steps that are stricter for systems supporting clinical decisions, medication, or identity-dependent access.

Practitioner takeaway: The most resilient healthcare organisations do not promise uninterrupted systems, they build a recoverable operating model that can keep care moving while trust in systems is re-established.