FDA Deficiency: Missing SPDF Documentation

What FDA reviewer language looks like

Paraphrased patterns from real deficiency letters. Not verbatim FDA quotes.

• Pattern 1

  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.

• Pattern 2

  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.

• Pattern 3

  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.

Why this happens

• Cybersecurity activities are run by a separate team in a separate tool stack from design controls, so there is no integrated DHF.
• The SPDF exists as a policy document but no evidence is generated showing it was followed for this specific submission.
• IEC 81001-5-1 is referenced in the cybersecurity narrative but not adopted in the QMS, so there are no audit records to back the reference.
• Cybersecurity requirements are not given requirement IDs in the same system that holds product requirements, breaking traceability.

How to fix it

• Adopt and reference a specific framework — IEC 81001-5-1, AAMI TIR57 plus AAMI SW96, NIST SSDF — and demonstrate alignment in writing.
• Integrate cybersecurity requirements into the same requirements management system as product requirements, with shared IDs and traceability.
• Provide DHF excerpts showing cybersecurity reviews at each design phase gate, with sign-off records.
• Map your SPDF activities to FDA 2026's expectations and provide a one-page crosswalk in the submission.

SPDF is a QMS commitment, not a document

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.

The crosswalk that almost always closes the deficiency

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.

Where IEC 81001-5-1 fits versus IEC 62304

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.

Standards involved

• SPDFSecure Product Development Framework
• IEC 81001-5-1IEC 81001-5-1:2021 - Health Software and Health IT Systems Safety, Effectiveness and Security
• FDA 2026FDA Premarket Cybersecurity Guidance (Feb 3, 2026)
• ANSI/AAMI SW96ANSI/AAMI SW96:2023 - Standard for Medical Device Security - Security Risk Management

Already responding to this deficiency?

Our deficiency response engagement rebuilds the underlying artifact and produces a reviewer-ready response narrative.