Device teams consistently make the same mistake with SPDF (Secure Product Development Framework) cybersecurity documentation: they treat it as a paperwork exercise and assemble artifacts at the end of development instead of generating them as engineering work happens. The result is a submission that looks complete on the surface but falls apart under FDA review because the documents don’t connect to each other. A threat model that doesn’t trace to test results, an SBOM that can’t be read by a machine, a postmarket plan with no patching timeline, these aren’t rare edge cases. They’re the pattern Blue Goat Cyber sees across submissions that come back with deficiency letters.
Blue Goat Cyber has worked through hundreds of FDA submissions, and one finding holds consistently. FDA reviewers often cite lack of traceability rather than single missing artifacts. Deficiency letters come from documents that exist in isolation, never wired together into a coherent story that a reviewer can follow from risk identification through mitigation, testing, and ongoing management. The FDA isn’t looking for a folder of files; it’s looking for evidence that cybersecurity is genuinely built into your product, a standard rooted in the agency’s own framing of cybersecurity as a safety issue.
This article maps every SPDF cybersecurity documentation artifact the FDA expects, shows where each one belongs inside the eSTAR template, identifies the deficiencies reviewers flag most often, and outlines a workflow for keeping documentation current after clearance.
What the Secure Product Development Framework actually demands from documentation
The FDA organizes SPDF evidence into four buckets: Security Risk Management, Security Architecture, Cybersecurity Testing, and Cybersecurity Transparency and Postmarket Management. These aren’t just organizational labels for filing purposes. They tell reviewers a coherent story about how cybersecurity is integrated across the total product lifecycle, from initial design decisions through years of postmarket operation.
The critical requirement is traceability. Every identified risk must link to a mitigation control. Every mitigation must link to a test result. Every test result must link to an ongoing management commitment. When that chain breaks anywhere, reviewers stop and issue an additional information request. The four-bucket structure is the framework you use to verify the chain is intact before you submit.
FDA also expects SPDF processes to be embedded in your Quality Management System, not maintained as a separate cybersecurity silo sitting outside the QMS. Under the Quality Management System Regulation aligned with 21 CFR Part 820, cybersecurity documentation must appear in design history files, SOPs, and quality manuals. Submissions that treat cybersecurity as a standalone deliverable rather than a QMS-integrated process flag immediately. Missing QMS integration evidence is one of the earliest red flags a reviewer encounters.
The complete SPDF cybersecurity documentation artifacts FDA reviewers look for
The Security Risk Management bucket requires a threat modeling analysis that includes attack surfaces, threat actors, risk scenarios, data flow diagrams, and full system context. The DFDs need to show security boundaries between components, trusted and untrusted networks, and external entities like cloud services. A threat model without complete DFDs is one of the most common triggers for additional information requests. The cybersecurity risk assessment and management plan must integrate patient safety risks and cover third-party and off-the-shelf components, not just internally developed software.
The Security Architecture bucket requires documentation of design decisions, architecture views, data flows, security boundaries, and control rationale. Security requirements must be traceable to specific identified threats and specific design controls, not written as general security objectives. Reviewers look for the direct line from a threat scenario to the engineering decision that addresses it.
The Cybersecurity Testing bucket requires a specific set of interconnected deliverables:
- Test plans linked to security requirements and the threat model
- Vulnerability testing results with disposition and remediation tracking
- Penetration testing reports including retest evidence after fixes are applied
- Software testing evidence covering SAST, DAST, fuzzing, and code review results
The Cybersecurity Transparency bucket is where many teams underinvest. The SBOM must be machine-readable in SPDX or CycloneDX format and include the seven NTIA minimum elements for every component: supplier name, component name, version, unique identifier, dependency relationship, SBOM author, and timestamp. A Word document listing components doesn’t satisfy Section 301(q) of the FD&C Act.
The vulnerability monitoring and management plan must specify patching timelines and coordinated disclosure procedures with documented channels and CVSS scoring. The postmarket cybersecurity plan must cover updates, incident response, and lifecycle monitoring. User security information must appear in device labeling.
Mapping SPDF artifacts to your eSTAR submission
The eSTAR cybersecurity section became mandatory for 510(k) submissions on October 1, 2023, and for De Novo submissions on October 1, 2025. The template uses color-coding to flag incomplete sections: reviewers see the same gaps you see when you open the file. Unresolved red fields translate directly into additional information requests, which means a pre-submission review of your eSTAR file is not optional. The FDA’s premarket cybersecurity guidance further details these expectations: FDA premarket cybersecurity guidance. For a practical checklist aligned to 524B and eSTAR, refer to our 524B eSTAR Checklist.
The Security Risk Management Report and threat model go into the Threat/Risk Management section. The SBOM and vulnerability management plan attach in the Cybersecurity section. Open anomalies and residual risk documentation feed the Risk Analysis section. For each artifact you attach, the document title in eSTAR must match the title in the document itself exactly, reviewers cross-reference them by name, and inconsistent naming creates unnecessary confusion that invites follow-up questions.
Build a traceability matrix that links every identified risk to a mitigation control, a test result, and a postmarket monitoring commitment. This matrix is the single most useful tool for catching broken chains before submission. Reuse validated artifacts across sections rather than creating duplicate documents that can drift out of sync as the project evolves. A threat model that appears in two places with slightly different content raises questions you don’t want to answer under reviewer scrutiny. For an in-depth checklist of required artifacts and where they belong, see our SPDF and FDA Cybersecurity Requirements.
Before you submit, run an internal mock review focused specifically on SBOM completeness and threat-to-control mappings. Assign someone outside the core documentation team to conduct it, the gaps invisible to the team building the artifacts are obvious to someone reviewing them with fresh eyes.
eSTAR naming conventions
Use a consistent filename convention that mirrors eSTAR section labels. For example: CYB-ThreatModel-v1.2.pdf, CYB-SBOM-v2.0.spdx, CYB-PenTest-Report-v1.0.pdf. When the document title, the filename, and the eSTAR attachment label all match, reviewers can cross-reference without ambiguity. Inconsistencies, even minor ones, slow the review and can generate information requests that have nothing to do with the substance of your cybersecurity program.
Common SPDF documentation deficiencies that delay clearance
Incomplete SPDF-QMS integration is the most persistent problem. It shows up as cybersecurity documentation that exists entirely outside the design history file. FDA reviewers check for evidence that cybersecurity processes are embedded in design controls and lifecycle documentation from the start. When the design history file doesn’t reference cybersecurity activities, the submission signals that security was added after development rather than built in.
Superficial threat models follow closely. Missing data flow diagrams, no end-to-end connection analysis, and no treatment of known vulnerabilities as design hazards all generate deficiency findings. Because the threat model is the foundation document for the entire SPDF submission package, a thin one undermines every downstream artifact built from it.
Non-compliant SBOMs generate deficiencies at a high rate because the NTIA minimum element requirement is specific and unambiguous. Absent elements, outdated component lists, and non-machine-readable formats all violate Section 301(q). Per FDA communications on FD&C Act Section 524B implementation, starting October 1, 2025, incomplete SBOMs can trigger refuse-to-accept notifications, pushing the entire submission back before it reaches substantive review.
Testing documentation that isn’t traced to risk mitigations is a surprisingly common problem. A penetration testing report sitting in a submission without explicit connection to the specific risk mitigations it validates provides limited value to a reviewer. Every test result needs a clear path back to the risk it addresses and forward to the postmarket management commitment that maintains the control.
Finally, weak postmarket plans consistently draw findings. A plan with no defined patching schedule, no coordinated disclosure process, and no incident response criteria fails the requirement. The FDA’s expectation is that critical vulnerabilities get addressed as soon as possible, with documented plans and justifications. Describing intentions without specifying processes and timelines doesn’t satisfy the standard.
Building your SPDF documentation package with a phased workflow
The design and architecture phase is when you produce the threat model, risk assessment, security requirements, and security architecture documentation. These must be live working documents, not post-hoc reconstructions written after the design is already finalized. Documentation written to describe decisions already made is harder to keep accurate and harder to defend when a reviewer asks how specific design choices were informed by specific threat scenarios.
The implementation and verification phase generates test plans, SAST and DAST results, penetration testing reports, and traceability matrices as direct outputs of development activities. The testing evidence should be a byproduct of engineering work, not a separate effort launched after development closes. When testing is integrated into the development cycle, the documentation captures actual results rather than retrospective summaries.
The release and maintenance phase finalizes the SBOM, completes the vulnerability management plan, and locks the postmarket cybersecurity plan before submission. Use Word or searchable PDF formats aligned to eSTAR terminology and match document titles exactly to what the submission template references. Standardize templates across submissions so reviewers encounter a consistent documentation structure. Familiarity with your format builds reviewer confidence and reduces questions about organizational decisions unrelated to the substance of the submission.
Store all SPDF cybersecurity documentation artifacts in a shared system with version control tied to design history file milestones, consistent with FDA QMS guidance under 21 CFR Part 820 and IEC 81001-5-1. Integrate document generation into phase gate reviews so documentation status is visible at every development checkpoint, not just at submission time.
Maintaining SPDF documentation after market clearance
Clearance is not the end of the SPDF documentation obligation. Threat models, SBOMs, security architecture views, and vulnerability management plans must be version-controlled to reflect new attack vectors, software updates, and emerging threats throughout the device’s commercial life. For Class III devices and 510(k) changes, all cybersecurity modifications must be documented annually, even those not formally reported to the FDA. Every versioning event must trace back to the original design history file and forward to updated QMS records.
Active vulnerability monitoring requires tracking CISA’s Known Exploited Vulnerabilities Catalog, ICS-CERT advisories, and H-ISAC threat feeds. Regular patches should deploy on a justified schedule. Critical vulnerabilities require out-of-cycle patches addressed as soon as possible, with documentation supporting the timeline decision.
Maintain a formal coordinated vulnerability disclosure process with documented channels, CVSS scoring, and communication timelines for external researchers. The process needs to be written down, not improvised when a researcher makes contact. Report cybersecurity incidents under MDR rules and 21 CFR Part 806 when they contribute to death, serious injury, or device malfunction with safety implications. Routine patches applied before harm occurs are generally exempt, but the threshold analysis must be documented. The postmarket phase is where many manufacturers lose the documentation discipline they applied during premarket development, and FDA inspections under Compliance Program 7382.850 are designed to surface exactly that gap.
Get the SPDF cybersecurity documentation right the first time
SPDF cybersecurity documentation isn’t paperwork. It’s structured evidence that proves cybersecurity is built into your product and maintained throughout its lifecycle. A submission with complete, traceable, interconnected artifacts tells a reviewer a coherent story. A submission with disconnected documents signals gaps in the program, not just the paperwork.
The actionable path is clear: organize artifacts into the four FDA buckets, map them to eSTAR using consistent IDs and traceability matrices, address the common deficiency patterns before submission, and maintain version-controlled documentation through the product’s full lifecycle. None of those steps are optional, and none are quick if you start them at the end of development.
If you’d rather not learn through rejection, Blue Goat Cyber builds this documentation as part of your submission package. The team has guided hundreds of FDA submissions, responded to cybersecurity deficiency letters, and developed the templates, workflows, and traceability practices described in this article.
Schedule a no-cost Discovery Session with us today.
Related: Medical Device Cybersecurity: A Complete Lifecycle Guide