On this page
Published: · Updated:
Key Takeaways
- The medical device incident response plan is a Section 524B requirement, not a postmarket-only artifact.
- The plan must connect to coordinated vulnerability disclosure, complaint handling, and MDR reporting.
- The FDA expects named roles, decision criteria, severity tiers, and customer communication paths.
- Tabletop exercise evidence and lessons-learned records strengthen the submission package.
- Misalignment between the IR plan and the postmarket cybersecurity management plan is a common deficiency trigger.
Section 524B requires a premarket description of how you will identify and respond to cybersecurity vulnerabilities and incidents, so the incident response plan is submission content, not a postmarket afterthought. Reviewers look for named owners, severity and escalation criteria, disclosure timelines, and explicit links to CAPA, complaint handling, and your coordinated vulnerability disclosure policy.
The FDA does not treat incident response as a postmarket afterthought. Under Section 524B of the FD&C Act, the cybersecurity content of a premarket submission must describe how the manufacturer will identify and respond to cybersecurity vulnerabilities and incidents across the device lifecycle. Reviewers look for a real plan with owners, decision criteria, and links to QMS records, not a paragraph in the cybersecurity management plan. This post walks through what the FDA expects in 2026, the documents that satisfy it, and the common reasons incident response sections draw deficiency letters.
Why this matters
A medical device incident response plan is the bridge between a known vulnerability and a clinically safe outcome. The FDA's February 3, 2026 final premarket cybersecurity guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," names incident response as a required element of the postmarket cybersecurity management plan that ships with every premarket submission for a cyber device. The guidance ties the plan to Section 524B(b)(2)(B), to coordinated vulnerability disclosure obligations, and to 21 CFR Part 820 quality system requirements for complaint handling and CAPA. Independent sources reinforce the stakes: CISA's published medical advisories under ICS-CERT routinely identify medical device vulnerabilities that require coordinated response between the manufacturer, the FDA, and healthcare delivery organizations. Without a named owner, a defined severity ladder, and rehearsed customer communications, manufacturers cannot meet the timelines that reviewers, customers, and CISA expect.
What the FDA Requires in a Medical Device Incident Response Plan
Section 524B Sets the Statutory Floor
Section 524B(b)(2)(B) of the FD&C Act requires a cyber device manufacturer to design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure, and to make available updates and patches to address vulnerabilities, including those that could lead to uncontrolled risks. Incident response is the operational expression of that obligation. The Feb 3, 2026 guidance turns the statute into specific submission content: a written plan, named owners, severity criteria, escalation paths, and a defined relationship to the manufacturer's CVD program.
The Plan Must Be Operational, Not Aspirational
Reviewers look for evidence that the plan is rehearsed. That means tabletop exercise records, sign-offs from clinical engineering or medical affairs, and traceable links between the IR plan, the threat model, and the postmarket monitoring program.
The FDA expects the IR plan to describe what the manufacturer will do, who will do it, the trigger criteria, and the maximum time to each action, not just to assert that incidents will be handled.
How the IR Plan Sits Inside the SPDF and Submission
Where It Lives in the Submission
The incident response plan is part of the postmarket cybersecurity management plan in the premarket submission. In eSTAR for a 510(k), it sits inside the cybersecurity content set and is cross-referenced from the cybersecurity management plan, the security risk assessment, and the labeling. The SPDF references the IR plan as the runtime control that closes the loop between detected vulnerabilities and deployed patches.
How It Connects to Other Postmarket Artifacts
The plan is one node in a network of postmarket artifacts. It receives input from the coordinated vulnerability disclosure policy, SBOM/VEX monitoring, customer support channels, and external feeds like CISA ICS advisories and the NVD. It feeds output into CAPA, MDR reporting under 21 CFR Part 803, customer security advisories, and software updates. A plan that does not reference these connection points reads as a draft rather than an operational document.
Who Owns Each Phase of Incident Response
Named Roles, Not Job Titles in the Abstract
The FDA expects named roles with defined authority. A typical structure assigns a cybersecurity incident commander (often the product security lead or CISO designee), a clinical safety lead (medical affairs or clinical engineering), a regulatory lead (regulatory affairs), a customer communications lead (support or marketing), and an engineering remediation lead. The plan documents who can declare an incident, who can authorize a customer advisory, and who signs off on a patch release.
Decision Authority at Each Severity Tier
Severity tiers drive the response. A common four-tier ladder (informational, low, high, critical) maps to time-to-triage, time-to-containment, and time-to-customer-communication. The plan states who has authority to escalate or de-escalate a tier and the criteria for each transition. Reviewers look for objective criteria (CVSS base score thresholds, exploit availability, patient-safety impact) rather than subjective language.
What Goes in the Plan: Required Sections
A defensible medical device incident response plan addresses the elements below. Each one should be a named section with owners, inputs, outputs, and time bounds.
| Section | Purpose | Typical inputs |
|---|---|---|
| Scope and applicability | Devices, versions, deployment contexts covered | Product registry, SBOM index |
| Detection and intake | How incidents are reported and triaged | CVD intake, customer support, KEV alerts |
| Severity classification | Tier criteria and decision matrix | CVSS, exploit telemetry, clinical impact |
| Containment and remediation | Immediate actions and patch pathway | Engineering runbooks, SPDF |
| Evidence preservation | Forensic capture of affected device storage before remediation | Hardware and software write blockers, chain-of-custody log |
| Customer communication | Advisories, timelines, channels | Labeling commitments, regulatory review |
| Regulatory reporting | MDR, CISA coordination, FDA notification | 21 CFR Part 803, CVD policy |
| Post-incident review | Lessons learned and CAPA | Tabletop records, incident timeline |
The Feb 3, 2026 guidance frames these activities as ongoing risk management under the device's total product lifecycle, not one-time submission content.
Common Deficiency Letter Patterns on Incident Response
Generic Plans Without Device-Specific Triggers
See also: 510(k) Cleared, No Postmarket Cybersecurity: Legal?, Documenting Update Cadence for an FDA Submission, and Does FDA 524B Apply to Legacy Medical Devices?.
The most frequent deficiency pattern is a generic enterprise IR plan attached to the submission without device-specific triggers. Reviewers flag plans that do not name the device, do not reference the threat model, and do not describe how a vulnerability in a specific software component would move through the process.
Missing Coordinated Vulnerability Disclosure Linkage
A second common pattern is an IR plan that does not connect to the CVD program. The two are separate documents but they share an intake channel and a notification pathway. Reviewers expect the IR plan to describe how externally reported vulnerabilities enter the process and how the CVD policy governs public disclosure timing.
No Evidence of Rehearsal
A third pattern is the absence of rehearsal evidence. Tabletop exercises are not required by name, but reviewers look for any indication that the plan has been exercised. Sign-off pages, exercise summaries, or references to lessons-learned reports satisfy this expectation.
Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.
How Blue Goat Approaches Incident Response Plans
We build incident response plans as runnable runbooks tied to the device's threat model, SBOM, and postmarket monitoring program, not as standalone policy documents. Each plan names owners, defines severity tiers with objective criteria, and references the customer communications, MDR reporting, and CVD pathways the manufacturer already operates. Our team holds CISSP, OSCP, and prior military red-team credentials, and our submission work is grounded in Section 524B, the FDA's February 3, 2026 final premarket cybersecurity guidance, AAMI SW96:2023, and the postmarket sections of the manufacturer's 21 CFR Part 820 QMS. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our FDA postmarket cybersecurity services or review the postmarket cybersecurity readiness plan for the broader operating model.
After clearance, our postmarket cybersecurity services cover vulnerability monitoring, patch planning, and incident response for devices in the field.
FAQ
Is a medical device incident response plan required in a 510(k) submission?
Yes, for any device that meets the Section 524B definition of a cyber device. The plan sits inside the postmarket cybersecurity management plan content set in the eSTAR submission. The Feb 3, 2026 final premarket cybersecurity guidance treats incident response as one of the required operational processes the manufacturer commits to before clearance.
How is the incident response plan different from the CVD policy?
The coordinated vulnerability disclosure policy governs how external researchers report vulnerabilities and how the manufacturer communicates about them publicly. The incident response plan governs internal detection, triage, containment, and remediation. The two share an intake channel and notification pathway but answer different questions.
Does the FDA expect tabletop exercises?
The Feb 3, 2026 guidance does not require tabletop exercises by name. In practice, reviewers look for evidence that the IR plan has been exercised. Tabletop records, sign-offs, and lessons-learned summaries are the most efficient way to demonstrate that the plan is operational rather than aspirational.
How does the IR plan interact with MDR reporting?
A cybersecurity incident that results in or could result in serious injury or death triggers MDR reporting obligations under 21 CFR Part 803. The IR plan describes the decision criteria for opening an MDR, the owner, and the timeline. Misalignment between the IR plan and the manufacturer's complaint handling SOP is a common deficiency.
What severity model should we use?
Most manufacturers use CVSS base score thresholds combined with exploit availability and patient-safety impact. The model itself matters less than the consistency. Reviewers expect the same severity definitions to appear in the IR plan, the CVD policy, the SBOM/VEX monitoring program, and the customer advisory templates.
Ready to make your incident response plan submission-ready?
If you are preparing a 510(k), De Novo, or PMA submission and need an incident response plan that reads as operational and lines up with your CVD policy, postmarket monitoring, and complaint handling, we can help. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber. Christian has led FDA premarket and postmarket cybersecurity programs across Class II and Class III devices and previously commanded military red-team operations. Read more at christian-espinosa.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.