Cyberattack Playbooks for Medical Devices

A medical device cyberattack can hit patient care fast. In one connected-device survey, 24% of hospitals said mortality increased after a cyberattack.

If I had to boil this article down to one point, it’s this: no single document covers the whole job. I’d use the MITRE/FDA playbook for hospital incident response, the MPM CIRP for manufacturer response, JSP2 for hospital team coordination and device lifecycle work, and FDA guidance for the rules vendors are expected to follow.

Here’s the simple breakdown:

• MITRE/FDA Playbook v2.0: best for hospital and regional response
• MPM CIRP: best for medical device manufacturers
• JSP2: best for hospital, IT, and biomed team coordination
• FDA guidance: best for regulatory baseline, vendor duties, SBOMs, and reporting

What stood out to me is that these resources do different jobs:

• Two help you respond during an active event
• Two help you plan, buy, track, and support devices before and after an event
• All four connect back to patient safety, not just IT uptime

If you run a hospital, the takeaway is simple: keep a current device inventory, know your clinical dependencies, set clear escalation paths, and make sure vendors provide records like SBOMs and security documentation.

Tips for Health Care Facilities: Cybersecurity Incident Preparedness and Response

sbb-itb-535baee

Quick Comparison

So if I were setting this up in practice, I wouldn’t pick just one. I’d treat them as a stack: response playbooks for the event itself, and planning documents for everything that has to happen before and after.

1. MITRE / FDA Medical Device Cybersecurity Regional Incident Preparedness and Response Playbook (Version 2.0)

Published by MITRE under FDA contract on November 15, 2022, Version 2.0 is an open, customizable playbook shaped by WannaCry and the ransomware-related downtime that came after it.^[12][14][15] MITRE later revised it using HDO focus groups and regional exercises.^[17]

Primary Audience and Scope

This playbook is built for healthcare delivery organizations (HDOs), including hospitals, integrated delivery networks, and regional health systems, as well as regional partners like public health agencies, emergency management organizations, and other health-sector stakeholders.^[9][11][12] It focuses on medical device security risks that affect device function in hospitals and regional health systems. It is meant to supplement an existing emergency operations plan, not replace it.^[9][13]

Incident Response Depth

The playbook lays out a phased incident response framework that covers preparedness, detection and assessment, triage and containment, communication and coordination, recovery, and post-incident improvement.^{[9][11][13][14][15][16]} It is more operational than technical. In plain terms, it centers on roles, timing, and coordination across teams.

That makes it useful in situations like a ransomware event hitting imaging systems or infusion pumps, where staff may need to make fast calls on patient diversion, backup workflows, and manufacturer guidance for safe restoration.^[9][14][16] The playbook also lines up with NIST SP 800-61r2 phases, so technical teams can work from a structure they already know.^[13][14]

Regulatory and Reporting Alignment

The playbook is not a regulation, but it does help with compliance planning. It directs HDOs to FDA's CyberMed@fda.hhs.gov contact when incident details are limited and encourages documentation that can support formal FDA reporting under 21 CFR Parts 803 and 806.^{[10][15][7][8]}

In practice, that means teams using the playbook are more likely to produce the records, risk assessments, and coordination artifacts they may need if a formal report becomes necessary.^[9][13][7]

U.S. Operating Fit

Version 2.0 also aligns with the Hospital Incident Command System (HICS) by mapping actions to roles such as Incident Commander, Operations, Planning, Logistics, and Public Information Officer.^[9][13] That fit matters. It makes it easier to work a device cyber incident into an All-Hazards Emergency Operations Plan and run tabletop or functional exercises built around a 24- to 72-hour ransomware event affecting critical care devices.^[9][11][14]

This hospital-side response model leads into the manufacturer-focused playbook that follows.

2. Health Industry Cybersecurity Medical Product Manufacturer Cyber Incident Response Playbook (MPM CIRP)

If the MITRE/FDA playbook is aimed at hospital operations, the MPM CIRP looks at the other side of the problem: the manufacturer response. It was published by the Healthcare and Public Health Sector Coordinating Council (HSCC) Joint Cybersecurity Working Group and is built for medical device manufacturers and production operations.^[4][24][25]

Primary Audience and Scope

The MPM CIRP is written for medical device manufacturers, with a clear focus on manufacturing environments and operational technology (OT).^[1][4][19] In plain terms, it speaks to the people who have to keep plants running while handling cyber risk.

That includes CISOs and security operations leaders, OT engineers, plant managers, quality and regulatory affairs teams, legal and compliance staff, and executive leaders in charge of continuity and risk.^[1][18] It also scales well for small and mid-size manufacturers that are building an incident response plan from scratch or tightening up one they already have.^[4][18][21]

Its scope covers incidents that can interrupt or weaken manufacturing operations, such as ransomware on production networks, industrial control system failures, and data integrity attacks on batch records.^[1][18][19]

Incident Response Depth

The MPM CIRP follows the full incident response lifecycle, moving from Preparedness through Detection, Investigation, and Analysis; Containment; Eradication; and Recovery and Post-Incident Activity.^[1][19] This is hands-on guidance, not theory.

In the Preparedness phase, the playbook calls for setting up a Cyber Incident Response Team (CIRT), documenting business-critical networks and systems, and defining severity classification criteria so teams can triage events the same way every time.^[1] That matters on the plant floor. A clear severity model can help teams decide whether a manufacturing line needs to stop at once or whether it can stay under close watch during containment.^[1][18]

Recovery goes beyond bringing systems back online. It includes validating product integrity and batch quality before shipments restart, then updating controls based on what the incident exposed.^[1][18][19] So recovery here is not just an IT task. It is also a product-quality call.

Regulatory and Reporting Alignment

The MPM CIRP builds regulatory duties right into the response flow. Legal and compliance leads help the CIRT track which incidents trigger FDA field alert reports, HHS or CISA notifications, or contract-based reporting to major U.S. health systems.^[1][4][18]

FDA's participation in HSCC joint cybersecurity work gives the playbook weight across the sector, even though it is not a regulation.^[5][23][24]

Operational Fit for U.S. Healthcare

Because this playbook is built around production environments, it is most useful in OT-heavy facilities. Manufacturing plants often run IT and OT side by side, and many general IR frameworks do not deal well with that mix.^[4][18][19] That is where the playbook stands out. Its CIRT guidance, network documentation, and severity classification are easy to plug into an existing IR plan.^[1][19]

The main challenge shows up in downstream coordination. Since the playbook is centered on the manufacturer, using it for joint response with U.S. HDOs, distributors, and group purchasing organizations can take extra internal mapping - especially when disruptions hit multiple states and health systems at the same time.^[4][18] A practical fix is to run joint tabletop exercises with major HDO customers using the MPM CIRP phases before a live incident forces the issue.

3. Health Industry Cybersecurity Medical Device and Health IT Joint Security Plan Version Two (JSP2)

JSP2 lays out how hospitals, IT teams, and clinical engineering should work together when connected medical devices are involved in an incident. Unlike the manufacturer-focused playbook, JSP2 is built for the hospital side of the job.

Primary Audience and Scope

JSP2 applies to healthcare organizations that manage connected devices across clinical, IT, and biomedical teams.

Incident Response Depth

JSP2 gives hospitals a seven-step response framework for device malfunctions, cyberattacks, and network failures.^[26] The big strength here is simple: it pushes shared action across departments instead of dumping the whole response on one team.

Operational Fit for U.S. Healthcare

For hospitals in the U.S., JSP2 is most useful when device response needs to line up with broader health IT operations. MPM CIRP covers the manufacturer side. JSP2 covers the healthcare organization side. That split helps hospitals assign clear response roles during connected-device events and ties straight back to the FDA guidance that sets the baseline for both sides.

4. FDA Cybersecurity Guidance for Medical Devices

Primary Audience and Scope

Where JSP2 defines hospital coordination, FDA guidance sets the manufacturer-side baseline that supports it.

FDA cybersecurity guidance is aimed first at medical device manufacturers and FDA reviewers. It covers both premarket submissions and postmarket devices. The scope includes devices with software, including firmware or programmable logic, as well as networked or wireless cyber devices under Section 524B of the FD&C Act. In plain terms, that reaches software-enabled and connected devices like infusion pumps and imaging systems. It also matters a lot to HDOs and hospital security teams, because they depend on manufacturer records - such as software bills of materials (SBOMs) and vulnerability management plans - to bring device cybersecurity into enterprise risk programs. ^{[27][29][30][28][12]}

Incident Response Depth

Its value during an incident is not as a response script, but as the standard for vendor obligations.

FDA guidance is not a step-by-step incident response playbook. Instead, it sets postmarket duties for manufacturers: monitor vulnerabilities, assess exploitability, remediate issues promptly, and communicate patient-safety risks to customers and FDA. Manufacturers of cyber devices must also include a coordinated vulnerability disclosure (CVD) plan in their premarket submissions. For hospitals, this matters in the middle of an incident because it defines what they can fairly expect from a vendor - patches, security advisories, and configuration guidance. It does not tell the hospital exactly how to run its own response. The FDA guidance doesn’t replace the playbooks covered in this article. It supports them by setting the regulatory baseline they sit on. ^[7][29][31]

Regulatory and Reporting Alignment

FDA guidance ties cybersecurity to existing regulatory requirements. For premarket submissions such as 510(k), PMA, De Novo, PDP, and HDE, cyber devices must show compliance with Section 524B requirements. That includes a monitoring plan, update and patch processes, and a complete SBOM. These rules apply to recent submissions, and FDA updated the premarket guidance in 2025. ^{[29][30][32][33]}

On the postmarket side, the guidance links cybersecurity vulnerabilities to current Medical Device Reporting (MDR) and correction/removal duties. It also gives a risk-based way to decide when cybersecurity-related changes must be reported and when FDA does not plan to enforce reporting under 21 CFR part 806. A 2026 analysis found 18 FDA safety communications tied to medical device cybersecurity between June 2013 and January 2025, with 94% of identified vulnerabilities rated high-risk. ^[7][31][22]

Operational Fit for U.S. Healthcare

For hospitals, the practical question is not whether FDA guidance is a playbook, but what it obligates vendors to provide during response.

For U.S. hospitals, the guidance sets a clear vendor baseline, but turning that into day-to-day action takes coordination. SBOM data has to move into asset and vulnerability management workflows, and patch timing has to match clinical maintenance windows. That sounds simple on paper. In a live hospital setting, it rarely is.

Older devices that came before current guidance may not have the logging, authentication, and update controls now expected. When that happens, teams often have to lean on compensating controls like network segmentation. Risk management platforms can help by centralizing vendor records, benchmarking, and fleet-wide response. The guidance sets the regulatory floor. Making it work in practice takes close coordination across clinical engineering, IT security, procurement, and legal, along with clear alignment between what manufacturers must deliver and what hospitals need in order to act during an incident. ^{[28][7][31][12]}

Strengths, Limitations, and Risk Management Considerations

These resources work best as a stack: use the playbooks when an incident is happening, and use the planning frameworks to cut risk before trouble starts. The table below shows where each one fits.

In plain English, the two playbooks help teams respond during an active incident. JSP2 and FDA guidance help lower risk before an event and shape what happens after it. Put together, these four resources form a practical response-and-prevention stack for connected-device risk.

The deciding factor is simple: does the hospital, manufacturer, or governance team need help with incident response, planning, or both?

Putting this into day-to-day practice takes more than having the documents on hand. Teams need current device inventories, mapped clinical dependencies, clear escalation paths, and vendor accountability written into procurement and contract terms across clinical engineering, IT security, and procurement. ^{[11][13][29][34]}

Censinet RiskOps™ can bring those efforts into one place by centralizing vendor and device risk assessments, cybersecurity benchmarking, and remediation tracking across medical devices, clinical applications, and supply chains. That gives healthcare organizations a more workable way to apply these frameworks across their connected device environment.

Conclusion

No single playbook fits every medical device cyberattack. The best move is to use them together, with the MITRE/FDA playbook serving as the main response framework. That’s where these frameworks help most: they turn a cyber event into clear roles, faster decisions, and safer recovery.

For HDOs, a current device inventory matters a lot. It should include IP addresses, software versions, and SBOMs so teams can search for weak points without losing time. To turn that planning into something teams can actually use, run tabletop exercises. They help test outage scenarios, reveal hidden dependencies, and let people practice response steps before an incident hits.

Effective device management depends on coordination across biomedical engineering, IT, and clinical teams. For day-to-day readiness, require cybersecurity standards and MDS2 documentation during procurement and risk reviews ^[26].

Use the playbooks together, prepare ahead of time, and align procurement with response planning.

FAQs

Which playbook should my hospital use first?

Start with a core incident response framework, such as NIST SP 800-61, then shape it around your clinical workflows, device risk tiers, and downtime protocols.

From there, focus on the playbooks that matter most for your highest-risk scenarios, like ransomware, medical device vulnerabilities, and third-party breaches. Censinet RiskOps™ can help with pre-filled checklists and automated workflows.

How do SBOMs help during a device cyberattack?

A Software Bill of Materials (SBOM) is a machine-readable inventory of the software components inside a medical device. When a cyberattack hits, it gives security teams a fast way to see which devices are tied to a known vulnerability.

That makes incident response much faster. Teams can match the SBOM against vulnerability databases, figure out which issues need attention first, and put compensating controls in place. That might mean isolating vulnerable devices or turning off specific features while they work on a fix.

What should hospitals do before an incident happens?

Before an incident, hospitals need to be ready. That starts with a complete asset inventory that lists each device’s clinical role, how critical it is, and how it connects to the network.

They should also:

• assign clear roles across IT, clinical engineering, and leadership
• check response playbooks, downtime procedures, and communication templates
• run regular exercises, line up plans with business continuity, and keep CMMS baselines and device instructions up to date

Related Blog Posts

• How Playbooks Improve Healthcare Cybersecurity Response
• FDA Cybersecurity Guidance: Impact on Incident Response Plans
• Checklist for FDA-Compliant Medical Device Incident Response
• Medical Device Supply Chain: Lessons from Past Incidents