A four-stage response framework shows how HTM, IT security, clinical leaders, and executives can coordinate when a cyber incident affects medical devices.
By Tamra Durfee, senior virtual chief information security officer
Recent high profile cyber attacks on medical devices and manufacturers including Stryker, Medtronic, and Contec Medical Systems among others have placed a spotlight on medical device security risks. When I speak with healthcare CISOs and other security leaders about how to deal with this, inevitably, the conversation turns towards incident response plans.
One reason for this is because traditionally these plans focus on isolating networking equipment and impacted workstations, not quarantining lifesaving medical equipment. As the stakes of a healthcare cyber attack rise, healthcare institutions need to integrate their incidence response (IR) plans to satisfy the needs of both IT security and clinical leaders.
Closing that gap between those two teams starts with who’s in the room when a device incident happens.
QUICK STAT: Health-ISAC found that medical devices were impacted in nearly 10% of health-related ransomware cases in 2025.
When an Incident is Identified, the Response Team Assembles
The incident responses I have been a part of are often a mixture of chaos and calm. More thoughtful preparation typically means calmer, better and faster decision making. When an incident is identified, the response team assembles. A common response team is composed of four roles:
- Healthcare Technology Management (HTM) – asset identity, location, service status, and validation of return to service.
- IT security – detection, segmentation, forensic scope, and the network controls that substitute for taking a device down.
- Clinical leadership – whether the device comes out of service, what replaces it, and the downtime procedure for the unit affected.
- Executive sponsor – regulatory notification, patient and board communication, and the authority to spend during the event.
Going into the first meeting, it is essential that each person understands their areas of responsibility and what decisions they are entitled to make. When authority is vague, it can lead to tension and delays that cost money and risk patient/staff safety.
What Does Response Team Readiness Look Like?
A well-rehearsed response team has thought through critical questions such as whether patients need to be moved to another facility. If the incident is limited to administrative areas, perhaps not, but the team will have drilled the decision tree down to a simple if this happens, then do this rule. You want a read-and-react decision, not one debated.
Similarly, the IT security team would know to avoid the natural inclination to isolate and contain everything, out of consideration for their clinical partners.
Choices about what to isolate or shut down must be collaborative. The process for resolving conflicting opinions must be established (or agreed upon) in advance.
Device incidents resolve in four stages, and they run in sequence whether or not anyone has assigned them. Each stage has a different owner, and the time you lose is almost always lost in the handoff between owners.
QUICK STAT: 99% of healthcare organizations are managing Internet of Medical Things (IoMT) devices with known exploited vulnerabilities (KEVs), per Claroty’s analysis of 2.25 million IoMT devices across 351 organizations.
Stage 1: Detection and Triage
Medical device incidents often start with a network alert or unusual device activity. IT security can detect the issue, but HTM must quickly confirm the device, location, owner, and patient-care impact. This requires a strong working relationship between IT security and HTM before an incident occurs; working together for the first time during an active response is a disaster waiting to happen. Triage slows when inventory is incomplete, or clinical status is unclear. The control is a current device inventory with owner, location, connectivity, and clinical service status documented before an incident occurs.
This is a bad time to be thinking about asset hygiene. Before incidents occur, IT security and HTM should be teaming up to ensure that devices that are not being used are taken offline, that working devices have the latest firmware and security updates, and that inventories are accurate.
Stage 2: Containment Without Clinical Disruption
Containment usually means segmentation or revoked access, not powering down the device. IT security executes the action, but clinical leadership must approve anything that affects availability. Risk increases when a device supporting patient care is taken offline before an alternative is ready. The control is a pre-approved containment tier for devices in clinical use, so response becomes a quick confirmation rather than a negotiation.
In this stage, the value of tabletop “fire drills” shows up immediately because they can identify conflicts that can be resolved before an incident happens. It is normal for different department heads to have different priorities or professional disagreements, but you can’t afford delay-inducing differences of opinion in the heat of the moment.
QUICK STAT: 96% of hospitals report running end-of-life operating systems or software with known vulnerabilities, according to Oliver Wyman.
Stage 3: Eradication and Vendor Coordination
Eradication depends on the manufacturer for validated firmware, patch timelines, and return-to-service approval. Delays happen when there is no named vendor contact, support spins in a general queue, or contract terms do not define response expectations. Be sure your vendor contracts name escalation contacts with a 24/7 SLA. Navigating a large manufacturer call tree at 2 am during an active incident only to get passed from person to person is unacceptable.
Stage 4: Notification, Recovery, and Lessons
Recovery means restoring the device to its validated baseline and addressing any required notifications to regulators, the manufacturer, or affected patients. This stage is a success when the lessons learned result in operational change. This could be improved vendor coordination and inter-departmental communication, or even commitments to rehearse and update IR plans. My view is that we fail patients if the same issues occur again.
Just as continuous improvement is good for products, it is good for IR plans.
Your IR plan has to account for as many variables as it can. Some are people-oriented; others are related to technology. The stress during a real incident makes it nearly impossible to think about everything. This is why simulating an incident to work the bugs out is such an enormous success factor.
But rehearsal only works if the data behind it is accurate, which is its own kind of inventory management.
Three IR Plan Testing Types
The best IT organizations are great at all kinds of inventory management. They keep data fresh, relevant, and accurate, whether it’s software licenses, digital certificates, or access controls. The same is true with IR planning. You have to know where all your patient monitors are, that your decision trees are accurate, and so on.
The majority of IR response success happens before an incident, including audits, rehearsals, and ensuring your security infrastructure is optimized to identify vulnerabilities in an era of AI-based attacks. We advise three types of preparation programs:
- IR Program – a device-inclusive plan with named escalation paths, monthly maturity scoring, and mobile access when your own systems are down.
- Tabletop exercise – run with HTM and clinical staff in the room, not just IT, because the decisions that stall a device incident are theirs.
- Vulnerability threat management – visibility into which connected devices carry KEVs, so the Stage 1 triage question is already answered.
Put those three together and the payoff shows up in the numbers. Anecdotally, we have found that organizations that are prepared and tested can see a 50-75% reduction in downtime costs, with recovery that runs two to four times faster.
Success is the result of a plan that’s been tested before it’s needed.
About the author: Tamra Durfee is a senior virtual chief information security officer at Fortified Health Security.
