The Cybersecurity Management Plan is the smallest deliverable in a premarket submission that determines how reviewers read every other deliverable. It is the governance document that tells the FDA who owns cybersecurity, how it is integrated into the Quality Management System (QMS) and the Secure Product Development Framework (SPDF), and how the company will run cybersecurity across the device's full lifecycle. This guide walks the contents reviewers expect under the FDA's February 3, 2026 final guidance and what triggers a deficiency.
Last updated: June 2026 · Aligned to the FDA's February 2026 final guidance, Section 524B of the FD&C Act, and AAMI SW96:2023.
TL;DR — what the Cybersecurity Management Plan must do
- Define scope — which device(s), which interfaces, which software, which third-party platforms.
- Name owners — cybersecurity lead, design owner, postmarket owner, executive sponsor.
- Integrate with the QMS — point to the SOPs that govern security work, not duplicate them.
- Anchor the SPDF — show that cybersecurity activities are tied to design controls and the software lifecycle (IEC 62304, IEC 81001-5-1, NIST SSDF).
- Reference the recognized standards stack — AAMI SW96:2023, TIR57:2016 (R2023), TIR97:2019, IEC 81001-5-1, NIST SSDF.
- Commit to a CVD policy — Section 524B(b)(2).
- Commit to a Vulnerability Management Plan — TIR97-aligned triage and remediation SLAs.
- Define measures and metrics — what you track and how often you report.
- State the postmarket commitments — patch/update SLA evidence per Section 524B(b)(1), monitoring, EoSL.
This document is not the SPDF itself, not the threat model, and not the test plan. It is the governance overlay that ties all of those together. For the SPDF as a framework see our SPDF Playbook; for the full eSTAR slot layout see our eSTAR v7.0 mapping guide.
Why the Management Plan exists in eSTAR v7.0
The FDA's Feb 3, 2026 final guidance organizes premarket cybersecurity content around a recognizable structure. eSTAR v7.0 exposes that structure as 8 Cybersecurity attachment slots. Slot 1 is the Management Plan. It is filed first because reviewers use it as the map they read the other slots against. A well-written Management Plan reduces the friction reviewers feel reading every later attachment.
"The cybersecurity management plan should describe the processes and procedures used to identify, assess, and mitigate cybersecurity risks throughout the total product lifecycle, including integration with the quality management system."
In recognized-standards terms, the Management Plan documents the organizational layer of AAMI SW96:2023 §4–§5 and IEC 81001-5-1 §4.
What goes in the Cybersecurity Management Plan
1. Scope and applicability
State the device(s) covered, the software components in scope, the interfaces, the deployment models (on-premise, cloud, hybrid), and the connected ecosystem (mobile companion, clinician console, HL7/FHIR integration). For combination products, declare which parts are covered.
Reviewers look for an unambiguous scope statement. "Cybersecurity is integrated across the company" is not a scope statement.
2. Governance, roles, and responsibilities
Name the cybersecurity lead (with credentials), the design owner, the postmarket security owner, the regulatory liaison, and the executive sponsor. List the cross-functional bodies (security council, change control board) that govern cybersecurity decisions. Provide a RACI for the major cybersecurity activities — risk management, threat modeling, testing, vulnerability handling, incident response.
Reviewers expect a named individual accountable for cybersecurity — not a department, not a vendor. If the named individual is a consultant, name the consultant and the internal escalation owner.
3. Integration with the Quality Management System
Reference the SOPs that govern security activities. Do not paste the SOPs. Typical references include:
- Design control SOP (21 CFR 820.30 / ISO 13485 §7.3) with security activities mapped to design inputs, outputs, verification, and validation
- Risk management SOP (ISO 14971) with the security risk extension (AAMI SW96:2023)
- Software lifecycle SOP (IEC 62304) with security activities (IEC 81001-5-1) mapped in
- Change control SOP that covers cybersecurity-impacting changes
- CAPA SOP for cybersecurity findings
- Supplier control SOP for third-party software and component suppliers
If the QMSR transition has been completed, reference ISO 13485:2016 sections directly.
4. Secure Product Development Framework anchor
Show that cybersecurity activities are embedded in the SPDF, not bolted on. Describe the SPDF phases (concept → design → implementation+verification → release → monitor → patch → end-of-support) and list the cybersecurity activity that lives in each phase. Reference IEC 81001-5-1 §5–§9 and NIST SP 800-218 (SSDF) practices PO, PS, PW, RV.
5. Recognized standards stack used
State which recognized consensus standards the program uses and the recognition number where applicable. The expected baseline:
- AAMI SW96:2023 — security risk management (FDA-recognized, recognition number 13-122)
- AAMI TIR57:2016 (R2023) — implementation guide under SW96
- AAMI TIR97:2019 — postmarket security risk management
- IEC 62304 — software lifecycle
- IEC 81001-5-1 — security activities in the software lifecycle
- NIST SP 800-218 — SSDF
- NTIA minimum elements + CycloneDX or SPDX — SBOM format
For depth on the standards stack see our MedTech Cybersecurity Standards Decoder.
6. Coordinated Vulnerability Disclosure (CVD) policy
Section 524B(b)(2) requires a CVD policy. The Management Plan references it; the policy itself is its own deliverable in the submission. The plan should state the intake channel (typically security@<company>), the public disclosure URL, the SLA targets (acknowledge / triage / fix / disclose), the alignment to ISO/IEC 29147 and 30111, and the link to the VMP. See our VDP & CVD workflows guide.
7. Vulnerability Management Plan (VMP)
The Management Plan references the VMP. The VMP describes how CVEs are ingested (NVD, GitHub Advisory DB, vendor advisories, CISA KEV, EPSS), triaged against the SBOM (Slot 5), prioritized (CVSS + exploitability + clinical impact), remediated (patch, mitigate, accept), and communicated to operators. It must align to AAMI TIR97:2019.
8. Measures and metrics
State the metrics the program reports and the cadence. Typical metrics include time-from-CVE-disclosure-to-triage-completion, time-from-triage-to-fix, mean time to patch deployment, percentage of components with known unresolved CVEs, percentage of CVD reports acknowledged within SLA, postmarket incident count and severity distribution. These metrics are also part of eSTAR v7.0 Slot 8 (Metrics).
9. Postmarket commitments
State the postmarket commitments the manufacturer is making, including:
- Patchability evidence under Section 524B(b)(1) — that the device can be updated "in a reasonably and reliably timely manner"
- Monitoring — the feeds watched, the cadence, the escalation criteria
- End-of-support / end-of-life policy — the policy by which components and the device itself are retired, and how operators are notified
- Incident response — how a cyber incident is detected, contained, communicated, and remediated, including the FDA-reporting threshold
How it sits in eSTAR v7.0
The Management Plan lives in Slot 1. The CVD policy and the VMP also live in Slot 1 as separate attachments referenced by the Management Plan. The plan itself points outward at all other slots — reviewers should be able to read the Management Plan and know exactly where every other deliverable will be filed and which standard it conforms to.
| eSTAR v7.0 slot | What the Management Plan references |
|---|---|
| Slot 1 — Management Plan | Itself, CVD policy, VMP |
| Slot 2 — Risk Management | The security risk file (SW96) |
| Slot 3 — Threat Model | Methodology, scope, and ownership |
| Slot 4 — Risk Assessment | Scoring approach, patient-harm mapping |
| Slot 5 — SBOM | Format (CycloneDX/SPDX), maintenance cadence |
| Slot 6 — Controls | Control catalog used and how it maps to threats |
| Slot 7 — Testing | Test families covered (SAST, DAST, SCA, fuzz, pen test) |
| Slot 8 — Metrics | The KPIs the program reports and how often |
For the full mapping see eSTAR v7.0 Cybersecurity Attachments → 2026 guidance.
Common deficiency patterns reviewers cite
Across the deficiency letters we have reviewed since the 2023 final guidance, the four most common Management Plan deficiencies are:
- No named accountable individual. "Provide the name and qualifications of the individual responsible for the cybersecurity program."
- No QMS integration. A plan that names security activities but does not point at SOPs reviewers can audit.
- Missing postmarket commitments. No explicit patchability evidence commitment under Section 524B(b)(1).
- Missing CVD intake channel. No public security intake (e.g.
security@<company>) and no public disclosure URL.
Any one of these triggers an Additional Information (AI) request on a 510(k) or a Major Deficiency on a PMA / De Novo.
How Blue Goat Cyber writes Management Plans
Our Management Plans are short, mapped, and auditable. They name the accountable owner (CISSP / OSCP credentials documented), reference your existing SOPs by section number, anchor the SPDF to IEC 81001-5-1, point at the recognized standards stack with current recognition numbers, embed the CVD policy and VMP commitments with measurable SLAs, and tie every later eSTAR slot back to a single owner. We deliver the plan formatted for direct eSTAR Slot 1 upload alongside the CVD policy and VMP attachments.
If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our cybersecurity submission services.
FAQ
Is the Cybersecurity Management Plan the same as the SPDF?
No. The SPDF is a framework that describes how cybersecurity activities are embedded across the software lifecycle. The Management Plan is the governance document that names the owners, references the SOPs, lists the standards used, and commits to postmarket activities. The Management Plan points at the SPDF; it does not replace it.
How long should the Management Plan be?
The plans reviewers credit are typically 15–30 pages. Longer plans are usually padded; shorter plans are usually missing either the QMS integration or the postmarket commitments.
Can we reuse one Management Plan across multiple products?
Yes, with a per-product scope appendix. Many companies maintain a single program-level Management Plan and file it with each submission alongside a one-to-three-page product scope appendix that names the device, the interfaces in scope, and any product-specific deviations.
Does the Management Plan need to be signed?
The FDA does not require a signature page, but reviewers expect a clear document control record — version, date, author, approver — consistent with the QMS. Practically, plans approved through the QMS document-control process carry the approval evidence already.
Where does the Management Plan reference the standards we use?
Inside a dedicated "Standards and frameworks" section, with the recognition number for each FDA-recognized standard and the version cited. State which version is in use (e.g. "AAMI SW96:2023" not "AAMI SW96") so reviewers can confirm the consensus standard recognition is current.
Related reading
- eSTAR v7.0 Cybersecurity Attachments mapping guide
- The SPDF Playbook
- The MedTech Cybersecurity Standards Decoder
- Vulnerability Disclosure Programs (VDP & CVD)
- FDA Cybersecurity Guidance Summary: 2026 Final Rule
- FDA Cybersecurity Testing Requirements Taxonomy
- Security Control Categories the FDA Expects
Sources & references
Primary sources cited in this article. Links open in a new tab.
- February 2026 final guidance- U.S. FDA