FDA Cybersecurity Deficiency Response Checklist

⚡ Free Resource · Updated 2026

A step-by-step, 11-stage checklist for organizing and resolving your FDA cybersecurity deficiency for 510(k), PMA, De Novo, and HDE submissions. Aligned with the FDA’s February 2026 final guidance and Section 524B of the FD&C Act.

Talk to a Deficiency Expert

Our Response Services →

📥 Download the printable PDF checklist

Which Letter Did the FDA Send You?

The first thing to do is identify exactly which type of letter the FDA sent - your response strategy, timeline, and submission mechanics differ for each.

• Additional Information (AI) Letter / AINN (Additional Information Needed Notification). The most common cybersecurity finding. The FDA review clock pauses until you respond. You have 180 days to submit a complete response or the submission is withdrawn. Respond as a supplement to the original submission, not a new 510(k).
• Major Deficiency Letter (PMA / De Novo). Substantive scientific or technical issues. Often paired with a formal meeting request. Same 180-day clock; treat every item as a hold on clearance until resolved.
• Hold Letter. Issued when the FDA needs information before substantive review can continue (PMA path). Clock pauses; you must address every hold item before review resumes.
• Refuse to Accept (RTA) Letter - 510(k). Issued in the first 15 calendar days of review when the submission fails the acceptance checklist (often a missing SBOM, threat model, or 524B element). You have 180 days to fix and resubmit, but the submission has not yet entered substantive review - fix the gap and reupload via eSTAR.
• Refuse to Accept (RTA) Letter - De Novo. Same mechanic as 510(k) RTA but uses the De Novo acceptance checklist.

If your letter cites Section 524B, AAMI TIR57, AAMI SW96, or the FDA February 2026 Final Premarket Cybersecurity Guidance, the rest of this checklist applies directly. Not sure which type you received? Send us the letter and we'll triage it free →

How to Use This Checklist

When you receive an FDA cybersecurity deficiency letter (also called an Additional Information request or Major Deficiency), work through each step in order and check off items as you complete them.

This checklist aligns with the FDA’s February 2026 final guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, and Section 524B of the FD&C Act. Not sure where to start? Schedule a no-cost discovery call →

Standards referenced in this checklist:

• ISO 14971 (safety risk management)
• AAMI TIR57 / ANSI/AAMI SW96:2023 (security risk management)
• ANSI/AAMI SW96 (medical device security risk management)
• IEC 62304 (medical device software lifecycle)
• IEC 81001-5-1 (health software security activities)
• IEC 62443-4-1 (secure product development)
• ISO 13485 (medical device QMS)
• UL 2900 (software cybersecurity for network-connectable products)
• NIST SP 800-115 (technical security testing)

Also see our companion guide: The MedTech Cybersecurity Standards Decoder →

At a glance: 11 actionable steps · 9 standards referenced · 60-90 days typical timeline from receipt to resubmission.

11 Steps to a Complete FDA Cybersecurity Response

Work through each step in order. Every checklist item maps directly to a requirement in the FDA’s February 2026 guidance or Section 524B. If you need help with any step, our team is one call away.

Step 1 · Initial Assessment & Triage

• Read the deficiency letter in full and identify every discrete finding
• Categorize each deficiency by the relevant 524B subsection:
  • 524B(b)(1): Postmarket monitoring, patching plans, and CVD procedures
  • 524B(b)(2): SPDF and processes for reasonable assurance of cybersecurity
  • 524B(b)(3): Software Bill of Materials (SBOM)
• Determine submission type (510(k), PMA, De Novo, HDE, PDP, or BLA)
• Confirm device meets the "cyber device" definition under Section 524B(c)
• Note the FDA reviewer name, division, and submission number
• Record the response deadline or target resubmission date

Step 2 · Threat Modeling

• Perform or update threat modeling per FDA guidance (Section V.A.1)
• Identify all medical device system risks and mitigations
• State assumptions about the environment of use (e.g., hostile network)
• Capture supply chain, manufacturing, deployment, and decommission risks
• Ensure threat model covers the full medical device system end-to-end
• Map each threat to a specific mitigation or risk control measure
• Align with AAMI TIR57 / ANSI/AAMI SW96 or equivalent framework
• Provide rationale for the threat modeling methodology selected

Step 3 · Cybersecurity Risk Assessment

• Perform a security risk assessment separate from the safety risk assessment
• Assess exploitability of identified vulnerabilities (not probabilistic)
• Capture pre- and post-mitigation risk scores and acceptance criteria
• Document residual risk conclusions with clinical justification
• Cross-reference CISA Known Exploited Vulnerabilities Catalog
• Ensure security risks are traced into the safety risk process (ISO 14971)
• Provide traceability between threat model, risk assessment, and SBOM

Step 4 · SBOM (Software Bill of Materials)

• Generate or update SBOM in machine-readable format (SPDX or CycloneDX)
• Provide both machine-readable (JSON/XML) and human-readable versions
• Include NTIA minimum elements (now stewarded by CISA) for each component:
  • Supplier name, component name, version, unique identifiers, dependency relationships, SBOM author, timestamp
  • Known vulnerabilities mapped per component (CVE status)
• List all third-party, open-source, and off-the-shelf (OTS) components
• Include support end dates and known vulnerabilities for each component
• Flag end-of-life components with risk rationale or replacement plan
• Provide a VEX (Vulnerability Exploitability eXchange) document for every component with known CVEs - state whether each CVE is exploitable in your device's deployed configuration (status: not affected, affected, fixed, under investigation) with justification
• Verify SBOM completeness against binary SCA and build system

Step 5 · Security Architecture & Design Controls

• Provide architecture views: global system, multi-patient harm, updateability, security use cases
• Include interface diagrams, trust boundaries, and data flow documentation
• Document authentication and access control mechanisms
• Describe cryptographic implementations (at rest and in transit)
• Detail secure boot and firmware/code integrity verification
• Document event detection, logging, and anomaly detection
• Describe resiliency and recovery mechanisms
• Document firmware and software update mechanisms (Appendix 1.H)

Step 6 · Cybersecurity Testing

• Verify security requirements testing: each input mapped to implementation
• Provide threat mitigation testing per each architecture view
• Perform vulnerability testing per ANSI/ISA 62443-4-1:
  • Abuse/misuse cases and malformed/unexpected inputs
  • Robustness and fuzz testing
  • Attack surface analysis
  • Vulnerability chaining assessment
  • Closed-box known vulnerability scanning
  • Software composition analysis of binary executables
  • Static and dynamic code analysis (SAST), including hardcoded credentials
• Perform penetration testing and include in report:
  • Independence and expertise of testers
  • Scope and duration of testing
  • Methods employed, results, findings, and observations
• Map all findings to threat model with remediation or formal risk acceptance
• Retest after remediations to confirm fixes are effective
• Assess unresolved anomalies for security impact (including CWE categories)

Step 7 · SPDF & Quality Management System Integration

• Document your Secure Product Development Framework (SPDF) per 524B(b)(2)
• Integrate SPDF into the QMSR (21 CFR 820) and ISO 13485 processes
• Ensure traceability from threat model to risk management file
• Connect cybersecurity design controls to your design history file (7.3.10)
• Verify cybersecurity activities are tied to change management (ECO process)
• Document custodial control of source code (escrow or backup for OTS)
• Include plans for replacing third-party components at end-of-support

Step 8 · Postmarket & Vulnerability Management Plan

• Define specific monitoring sources (NVD, ICS-CERT / CISA, vendor advisories)
• Define vulnerability response timelines based on severity and clinical risk
• Include justifications for response timelines and any deviations
• Name responsible roles and escalation paths for vulnerability response
• Document coordinated vulnerability disclosure (CVD) procedures per 524B(b)(1)
• Describe patch delivery and software update mechanisms
• Detail how updates are authenticated and verified on the device
• Describe rollback capabilities if an update fails
• Account for both currently marketed and fielded legacy devices
• Track and report defect density, time-to-patch, and deployment metrics
• Confirm monitoring processes and tooling are operational before market entry. See our postmarket services →

Step 9 · Cybersecurity Labeling & Transparency

• Include cybersecurity information in device labeling per Section 502(f)
• Disclose all communication interfaces and third-party software in labeling
• Provide users with information to securely configure and update the device
• Document known vulnerabilities and risk information for end users
• Include risk transfer information and any user-required security actions

Step 10 · Response Document Preparation

• Draft a point-by-point response to each deficiency item - quote the FDA's exact wording first, then your response
• Write a cover letter that lists every deficiency by number, your one-line resolution, and the section/page where the FDA will find the new evidence
• Cross-reference responses with updated technical documentation
• Include all supporting evidence: test reports, SBOM, SPDF, architecture views
• Include a traceability matrix mapping every deficiency item → response section → updated artifact (file name + version)
• Have a regulatory affairs specialist review the response language
• Verify response format meets FDA eSTAR or eCopy requirements
• Confirm section mapping against current FDA submission template
• Conduct an internal review or dry run before submission

Step 11 · Final Submission & Follow-Up

• Submit response via the appropriate FDA portal (eSTAR for 510(k); CDRH Portal for PMA/De Novo amendments)
• Submit as a submission amendment (responding to an AI letter / hold) - do not file a new 510(k) or supplement unless the FDA explicitly directs you to
• Confirm you are well within the 180-day response clock (Day 1 = date on the AI letter); request an extension in writing if you need more time, before the clock expires
• Retain a complete copy of all submitted materials with version-controlled file names
• Set a follow-up reminder for FDA response (typically 60-90 days)
• Prepare for potential interactive review or follow-up questions - assign a single point of contact who can respond within 5 business days
• Verify postmarket monitoring processes are live before device reaches market
• Document lessons learned for future submissions

How Blue Goat Cyber Approaches FDA Cybersecurity Deficiency Response

Deficiency response is where most submissions stall - or die. We run it as a focused engagement with a fixed timeline and a single objective: a clean response in one round. Here is the model.

• Triage in the first 48 hours. We categorize every deficiency (RTA, AI, Major, Minor), map it to controlling FDA guidance, and identify which findings need remediation vs. explanation vs. new evidence.
• Original submission audit. Before responding we re-read what you shipped. Half of the deficiencies we see are downstream of a traceability gap earlier in the package that will trigger a follow-up if not fixed now.
• Evidence, not narrative. Reviewers want documents (threat model updates, retest reports, updated SBOMs, revised SPDF plans) - not a cover letter arguing the finding away. We produce those documents.
• Q-Sub when it saves a cycle. For ambiguous deficiencies we scope a pre-response Q-Sub so you get FDA alignment before spending 90 days on the wrong fix.
• Response package assembled the way FDA reads it. Each deficiency answered in order, with cross-references and the underlying artifact attached.
• Fixed price, fixed timeline. You get a defined scope and a delivery date that fits inside the 180-day (Major/AI) or 15-day (RTA) response window.

Our FDA Cybersecurity Deficiency Response engagement is the entry point.

Frequently asked questions

How long do we have to respond to an FDA cybersecurity deficiency letter?

For a 510(k) Additional Information (AI) letter you have 180 calendar days from the date on the letter. Miss that window and the submission is withdrawn and you file (and pay) again. Deficiencies inside a De Novo or PMA follow the pathway-specific hold and interactive review clocks, but the practical target is the same: respond within 60 to 90 days to keep the reviewer engaged.

Can we respond partially and defer the rest?

You can, but it is a bad idea. Reviewers treat a partial response as a signal that the manufacturer has not internalized the deficiency, which usually produces a second, broader deficiency letter. Fully answer every item in the letter in one submission, even if some items require you to acknowledge open work with a dated remediation plan.

Should we schedule a Q-Sub before responding?

Only if the letter contains an ambiguous item where the FDA's expectation is genuinely unclear. A Q-Sub adds three to four months to the timeline and is rarely worth it for a routine cybersecurity deficiency where the guidance is prescriptive. Reserve Q-Subs for novel devices, first-in-class cybersecurity questions, or when a reviewer explicitly invites one.

Do we need to redo the pen test if the FDA cites test coverage?

Usually yes, at least partially. A deficiency that cites incomplete pen test scope, missing attack vectors, or shallow testing rarely closes with a narrative response. Rescope with the specific gaps the reviewer named, run the incremental testing, and attach the revised report. Reusing the original report with a cover letter almost never clears the deficiency.

What is the difference between an AI letter, an RTA hold, and a "major deficiency"?

RTA is an acceptance screen that stops the review clock before substantive review starts. An AI letter comes during substantive review and starts a 180-day response window. "Major deficiency" is language reviewers sometimes use inside an AI letter to flag items that would prevent clearance if unresolved. All three require a written response; RTA is the fastest to trigger and the fastest to resolve if the missing artifact exists.

Does responding to a cybersecurity deficiency require a new predicate analysis?

Not usually. Cybersecurity deficiencies typically live in the substantive review of the cybersecurity subform and do not touch substantial equivalence. The exception is when the reviewer questions whether cybersecurity differences between your device and the predicate raise a new safety and effectiveness question. Then predicate analysis becomes part of the response.

Need Expert Help With Your FDA Response?

Blue Goat Cyber focuses exclusively on medical device cybersecurity. Every engagement is structured around FDA clearance - we don’t handle enterprise IT. When you work with us on a deficiency response, you get a team that has written the artifacts, argued the cases, and gotten devices cleared.

• Deficiency Letter Analysis & Response Strategy
• Threat Modeling & SPDF Documentation
• SBOM Generation & Vulnerability Assessment
• Penetration Testing (FDA-Ready Reports)
• Full 524B Submission Support & Review
• Postmarket Cybersecurity Management

This checklist is provided free of charge by Blue Goat Cyber. It is informational and does not constitute legal or regulatory advice.

bluegoatcyber.com · (844) 939-4628

Need help working the checklist on a live FDA letter? Our FDA Cybersecurity Deficiency Response service closes letters on the first resubmission with a fixed-fee, NDA-backed engagement. Send us the letter and we return a free written gap analysis within 24 hours.

See also: Deficiency letter examples & analysis · Deficiency vs RTA vs Hold letter · What triggers FDA cybersecurity deficiencies