This is a ready-to-use cybersecurity management plan for the device constituent of a combination product. It is written for the case that generic device cybersecurity material does not cover well: a connected drug-delivery device, an on-body biologic delivery system, or a companion app that is part of a drug or biologic application rather than a standalone device submission. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. This plan is educational structure to adapt, not legal or regulatory advice; verify every cited regulation and guidance against its current published version before you rely on it, and route the completed plan through your normal document control and change-control process.
Document control header
| Field | Entry |
|---|---|
| Plan title | Combination Product Software Cybersecurity Management Plan |
| Document number | <<FILL: PLAN-ID, e.g. PLAN-SEC-004>> |
| Product / device constituent | <<FILL: product name and the device constituent it refers to>> |
| Plan owner | <<FILL: role, e.g. Product Security Lead>> |
| Lead FDA review division | <<FILL: division name, confirmed at pre-submission meeting>> |
| Combination product type | <<FILL: drug-led / biologic-led / device-led, per the PMOA determination>> |
1. Purpose
This plan defines how <<FILL: COMPANY NAME>> manages cybersecurity for the device constituent of <<FILL: PRODUCT NAME>> across the total product lifecycle: premarket scoping and determination, the Secure Product Development Framework activities carried during design and development, the content that goes into the marketing application, and the postmarket vulnerability program that runs after clearance or approval. It exists because a combination product’s device constituent carries the same cybersecurity obligations as a standalone device, but the submission, the review division, and the surrounding quality system are organized around the drug or biologic.
2. Scope
This plan covers the device constituent’s software, firmware, and programmable logic, and any companion application or connected service that is part of the authorized product, whether reviewed under a BLA, an NDA alongside device-constituent information, an IND, or a device-led pathway. It does not replace the overall combination-product quality plan; it is the cybersecurity-specific plan referenced from that plan and from the Documentation Level evaluation.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| Plan owner / Product Security Lead | Owns this plan, the threat model, the SBOM process, and postmarket vulnerability triage |
| Combination Product Lead (OCP liaison) | Confirms the lead review division, routes the cybersecurity package into the correct submission, coordinates the CDER / CBER / CDRH consult |
| Software Engineering | Implements the SPDF design and development activities, maintains the SBOM generation pipeline |
| Risk Management / SME | Runs ISO 14971 safety risk management and links it to the security risk assessment |
| Quality Assurance (drug/biologic side) | Confirms the cybersecurity program interfaces correctly with the product’s CAPA, deviation, and change-control procedures |
| Regulatory Affairs | Owns the Documentation Level and cyber device determinations, the submission narrative, and FDA interactions |
4. Scoping determinations
Complete and reference the following before building the rest of this plan, since each one changes what the plan must contain:
- Cyber device determination (does the device constituent include software, connect to the internet directly or indirectly, and carry technological characteristics that could be vulnerable; if all three, section 524B applies in full).
- Documentation Level determination (Basic or Enhanced; a combination-product constituent defaults to Enhanced unless a documented rationale for Basic is submitted).
- IEC 62304 software safety classification (A, B, or C for each software item).
- Lead review division confirmation, obtained in writing from the Office of Combination Products coordination or the relevant pre-submission meeting minutes.
5. Secure Product Development Framework activities
| SPDF activity | What this plan commits to | Cadence |
|---|---|---|
| Threat modeling | STRIDE-based data flow analysis covering network, physical, update, and supply-chain attack surfaces | At each major design change and at least annually |
| Security architecture review | Independent review of trust boundaries and segmentation | At design freeze and at each Enhanced-triggering change |
| Software bill of materials | Machine-readable SBOM (<<FILL: SPDX or CycloneDX>>) generated from the build, reconciled against the SOUP inventory | Every release |
| Security testing | Software composition analysis, static and dynamic analysis, and independent penetration testing | Before each marketing submission and before each major release |
| Security risk assessment | AAMI TIR57-aligned assessment, cross-checked against the ISO 14971 safety risk file for crossover hazards | Updated with each threat-model and SBOM update |
| Labeling and transfer of responsibility | Network requirements, update mechanism, end-of-support plan, and operator responsibilities documented in labeling | Reviewed at each submission |
6. Postmarket vulnerability program
This plan commits to the postmarket program detailed in <<FILL: reference to the postmarket cybersecurity vulnerability management SOP>>: a coordinated vulnerability disclosure channel, a triage process that classifies each vulnerability as controlled or uncontrolled risk, and a remediation and reporting path under 21 CFR 806.10. Because the device constituent’s patient-harm pathway is the same product the drug or biologic quality system already governs, every uncontrolled-risk finding is also entered into <<FILL: reference to the product's CAPA/deviation system>> so the investigation and corrective action run once, not twice.
7. Acceptance criteria
- The cyber device, Documentation Level, and IEC 62304 classification determinations are documented, current, and consistent with one another and with the risk files.
- The lead review division is confirmed in writing before the cybersecurity package is built.
- The threat model, SBOM, and security risk assessment are each current as of the most recent release and reconciled against each other.
- The postmarket vulnerability program has a working coordinated-disclosure channel and a documented controlled/uncontrolled triage decision for every open finding.
- Every uncontrolled-risk vulnerability affecting the device constituent has a corresponding entry in the product’s drug/biologic-side CAPA or deviation system.
8. References
Section 524B, Federal Food, Drug, and Cosmetic Act. 21 CFR 3.2(e) (combination product definition) and 21 CFR 4.2 (cGMP requirements for combination products). FDA guidance, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (current version; confirm the version in force). FDA guidance, Postmarket Management of Cybersecurity in Medical Devices (final, 2016). FDA guidance, Content of Premarket Submissions for Device Software Functions (final, June 2023). 21 CFR part 806 (corrections and removals). AAMI TIR57, Principles for medical device security, Risk management.
Confirm the current title and version of each guidance before you cite it; FDA has reissued the premarket cybersecurity guidance more than once as the statute and the quality-system rules moved.
9. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
10. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author | <<FILL>> | ||
| Product Security review | <<FILL>> | ||
| Regulatory Affairs review | <<FILL>> | ||
| Quality Head approval | <<FILL>> |
Filled specimen
The following shows the scoping section and SPDF table completed for an example connected autoinjector that is the device constituent of a biologic-led combination product, so you can see the level of specificity expected.
| Field | Entry |
|---|---|
| Product / device constituent | BioFlex Injector System, connected autoinjector device constituent |
| Lead FDA review division | CBER, Office of Therapeutic Products, confirmed at Type B pre-submission meeting 14 May 2026 |
| Combination product type | Biologic-led, confirmed via PMOA determination record PMOA-2026-0031 |
Scoping determinations: cyber device, yes (Bluetooth pairing to a companion app that reaches a cloud dosing log); Documentation Level, Enhanced (combination-product default, no Basic rationale submitted); IEC 62304 classification, Class C for the dose-computation module, Class B for the companion app’s reminder logic.
SPDF activities: threat model last updated with the Bluetooth stack revision in Q2 2026; SBOM in CycloneDX format regenerated at every build and reconciled against the SOUP inventory monthly; penetration test completed by an independent third party six weeks before the BLA supplement was filed, with two medium findings remediated and documented before submission.
This specimen shows the pattern a reviewer expects: every scoping determination traces to a dated source (a meeting, a record, a test report), and the SPDF table is a status report, not a list of intentions.
Common inspection findings this plan prevents
- A cybersecurity management plan that exists for the device-constituent engineering team but was never shown to, or referenced by, the drug or biologic quality system that owns CAPA and deviations.
- No documented confirmation of which FDA review division leads the combination product, discovered only when the submission bounces back with a routing question.
- A threat model, SBOM, and security risk assessment that are each current on their own but were never reconciled against each other at the same point in time.
- An uncontrolled-risk vulnerability handled entirely inside a security team’s own tracker with no linkage to the product’s CAPA system.
How to adapt this plan
- Set your document number and confirm the combination product type and lead review division in the header before drafting the rest of the plan.
- Complete the four scoping determinations in section 4 first; they decide the depth of everything that follows.
- Point section 6 at your actual postmarket vulnerability SOP and your actual CAPA or deviation procedure rather than leaving the placeholders generic.
- Revisit the SPDF cadence table at each major design change, not only on a calendar schedule.