Section 524B and FDA 2026 require manufacturers to demonstrate a Secure Product Development Framework (SPDF) - the cybersecurity equivalent of design controls. A 'missing SPDF documentation' deficiency means the reviewer cannot find evidence that cybersecurity activities are governed by your QMS, integrated with the design control timeline, and traceable across requirements, risk, verification, and post-market.
Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.
The submission does not adequately describe the manufacturer's Secure Product Development Framework. Provide documentation showing how cybersecurity activities are integrated with the design control process and the device's quality management system.
It is not clear how cybersecurity requirements are derived, traced, and verified within the design history file. Provide traceability between cybersecurity requirements, controls, verification activities, and the corresponding design control records.
The submission references a Secure Product Development Framework but does not identify the standard or framework on which it is based. Identify the framework (e.g., IEC 81001-5-1, NIST SSDF) and describe the alignment.
The deficiency wording often makes SPDF sound like a single artifact you can append. It is not. SPDF is the claim that your QMS treats cybersecurity as a first-class engineering discipline - with policies, procedures, training, design reviews, and audit records - over the entire product lifecycle. The submission only needs to demonstrate the framework, but the framework has to actually exist in the QMS for the demonstration to hold up to a future inspection. Manufacturers who write an SPDF narrative without backing QMS procedures often clear the submission deficiency only to face larger findings during post-market inspection.
A one-page table mapping FDA 2026 expectations (each major section) to the corresponding SPDF activity, the QMS procedure that governs it, and the artifact in the DHF that evidences it for this submission, is the single most effective way to close an SPDF deficiency. It tells the reviewer exactly where to look for each expectation without re-reading the entire package, and it forces the manufacturer to confirm - internally - that the alignment is real.
Teams that have IEC 62304 in their QMS sometimes assume that satisfies the SPDF expectation. It does not. IEC 62304 governs the software lifecycle for safety; IEC 81001-5-1 governs the security lifecycle for health software, including activities - threat modeling, security risk management, vulnerability handling, secure-by-design requirements - that 62304 does not address. A defensible SPDF narrative names both, explains the relationship (62304 for software safety lifecycle, 81001-5-1 for security activities, AAMI SW96 for medical-device-specific security risk management, AAMI TIR57 as the security risk methodology), and points to the QMS procedures that operationalize each. Submissions that conflate the two, or claim 62304 alone covers SPDF, draw a follow-on deficiency on standard alignment even if the original SPDF section is otherwise solid.
Already responding to this deficiency?
Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.
FDA Cybersecurity Deficiency Response serviceBring us the letter. We will map a clean response and rebuild the underlying artifact to FDA 2026 expectations.
