On this page
Published: · Updated:
Key Takeaways
- Section 524B requires a postmarket vulnerability plan, including coordinated disclosure; incident response procedures support that plan.
- 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.
For cyber devices in covered marketing submissions, Section 524B(b)(1) requires a postmarket vulnerability and exploit management plan including coordinated vulnerability disclosure. Incident response procedures can support that plan within integrated documentation; a separate standalone IR document is not prescribed. Define owners, risk-based escalation, and links to complaint handling and applicable reporting.
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 connects vulnerability detection to clinically safe remediation. Section 524B(b)(1) requires a plan to monitor, identify, and address postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure. Section 524B(b)(2) requires cybersecure processes and updates and patches. The February 3, 2026 guidance recommends supporting documentation; it does not prescribe a standalone incident response document or universal response deadlines.
Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B); CISA Cybersecurity Advisories (including ICS medical advisories).
What the FDA Requires in a Medical Device Incident Response Plan
Section 524B Sets the Statutory Floor
Section 524B(b)(2) 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
Rehearsal evidence can strengthen the plan but is not a universal submission requirement. 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 and optional 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: Recommended 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 Parts 803 and 806, 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?.
A potential documentation gap 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 gap is poor coordination between incident response and CVD procedures. They may be integrated or separate documents, but should explain researcher intake, triage, internal escalation, and public disclosure responsibilities.
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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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.
Related reading: Ransomware and Medical Devices: What the FDA Expects in 2026.
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?
Under 21 CFR 803.50, manufacturers report information reasonably suggesting that a device may have caused or contributed to death or serious injury, or malfunctioned and would be likely to cause or contribute to death or serious injury if the malfunction recurred. Not every cybersecurity incident or hypothetical harm is reportable. Document the assessment, owner, and applicable 30-calendar-day or 5-workday reporting pathway.
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 and optional 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 a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. 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.
Sources & references
Primary sources cited in this article. Links open in a new tab.
- FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026)- U.S. FDA
- FDA eSTAR Program- U.S. FDA
- FDA Cybersecurity in Medical Devices FAQs (Section 524B)- U.S. FDA
- CISA Cybersecurity Advisories (including ICS medical advisories)- CISA