Most manufacturers do not fail cybersecurity reviews for lack of activity. They fail because the activities are not governed: threat modeling happened, but no procedure says when, who owns it, or where the outputs land. This umbrella SOP fixes that. It hangs every cybersecurity activity on the design control phases of 21 CFR 820.30, which is exactly where FDA's 2023 premarket guidance says cybersecurity belongs: inside the quality system, not beside it.
The structure matters more than any single section. Planning produces a Cybersecurity Risk Management Plan with named deliverables. Design inputs get threat modeling and risk acceptance criteria. Design outputs get SBOMs, secure code analysis, and vulnerability scanning. Verification gets penetration and resiliency testing plus traceability. Postmarket gets a vulnerability management plan with committed timelines. Each phase feeds a Cybersecurity Risk Management Report that a reviewer can walk end to end.
Adapt the bracketed fields to your organization. And be honest about capacity: this SOP describes a lot of recurring, mechanical work. That is the burden ELTON automates. The SOP is still yours to own.
Describe the medical device cybersecurity program process and documentation for [Organization].
Cybersecurity activities and documentation related to the design, development, verification, validation, and continual postmarket monitoring of medical devices developed by [Organization].
The process governs all cybersecurity activities across the total product lifecycle of a system designed by [Organization], aligned to the design control phases of 21 CFR 820.30. Each phase below names its required activities, inputs, and outputs.
Each product release requires a Cybersecurity Risk Management Plan defining the activities performed across the lifecycle, the roles and responsibilities, and every cybersecurity deliverable. At minimum the plan covers: the list of cybersecurity outputs for the release; roles and responsibilities; risk acceptance criteria; threat modeling and its patient safety risk assessment; SBOM creation; risk assessments of software vulnerabilities, cybersecurity testing results, secure code findings, and unresolved anomalies; cybersecurity testing with at least yearly re-testing; the risk management report; and post release plans for vulnerability management and vulnerability metrics. Inputs include the development plans and the ISO 14971 risk management plan.
A threat model is developed and maintained for each release. It decomposes the architecture and documents interactions between system elements in a set of views: global system level, multi patient harm, updatability and patchability, and security use cases. Threat analysis uses STRIDE per element, documented in the threat model tab of the Cybersecurity Risk Assessment. For existing products, the prior release's threat model is the starting point.
The plan documents overall criteria (for example: no unacceptable individual cybersecurity risks remain at release) and individual criteria. Risks that could affect patient safety use the cross section of CVSS v3 exploitability against worst case severity of harm, each cell marked acceptable, unacceptable, or requiring benefit risk analysis. Risks that cannot affect patient safety use CVSS score bands: 0.0 to 3.9 acceptable, 4.0 to 6.9 benefit risk assessment required, 7.0 to 10 unacceptable.
Threats are assessed twice: an initial pass to prioritize by potential patient safety impact before or during requirements development, and a residual pass once mitigating controls exist. Cybersecurity requirements are developed for each release, either standalone or inside existing requirements documents, and mapped to the security control categories in Appendix 1 of the 2023 guidance.
An SBOM is created for the release, monolithic or split across components, machine readable, in CycloneDX or SPDX, and aligned to the threat model's architectural decomposition. Each component carries the NTIA baseline attributes: author name, timestamp, supplier name, component name, version string, component hash, unique identifier, and relationship. Supplemental level of support and end of support information accompanies the SBOM in human readable form; for devices that outlive component support, the risk transfer to end users must be disclosed.
Source code is inspected for weaknesses: hard coded keys and secrets, deprecated cryptography such as MD5 or SHA1, unsanitized input paths. Analysis runs on a regular cadence (nightly, weekly, or per build) so technical debt stays low, and a final report from the release version lists any findings not remediated or judged false positive. Every finding is risk assessed per [SOP: Cybersecurity Risk Assessment].
SBOM components are scanned for vulnerabilities throughout development, then continuously after release. A Software Vulnerability Report from the final SBOM lists remaining vulnerabilities that are unpatched or accepted, each with its risk assessment.
Testing proves the design controls exist and hold. Four kinds are required: verification and validation of cybersecurity requirements alongside the system's overall verification activities; penetration testing of the final or equivalent system, performed from a systems perspective with integrated systems in scope, producing a report of methodology and observations; vulnerability testing that pairs static and dynamic analysis with exploitation attempts; and resiliency (fuzz) testing. Each testing observation is risk assessed, and so is every unresolved anomaly in the release.
Sources of threat trace to mitigating design controls, organized as control groups in the risk assessment, and controls trace to test cases through the requirements traceability matrix. This is the chain a reviewer walks to confirm each mitigation was implemented and proven effective.
The report records the release's full cybersecurity story: risk evaluation methods, acceptance criteria, summaries of every risk assessment, mitigation activity, and references to the plan, threat model, risk assessments, SBOMs and support information, vulnerability and secure code reports, testing results, and metrics tracking.
The release carries a vulnerability management plan with six activities: threat monitoring and intelligence (NVD, SBOM component disclosures, Health-ISAC, CISA, customer complaints), vulnerability risk assessment against the controlled or uncontrolled line, response planning, communications (60 days for controlled issues; 5 business days plus a 30 day patch schedule for uncontrolled ones), patch development and testing, and patch deployment with verification instructions for users or field personnel. Every fielded release is penetration tested at least annually until it leaves the field. The postmarket half of this program is published separately as its own example SOP.
The point of an umbrella SOP is that nothing depends on heroics. When each phase names its outputs, a premarket submission becomes an assembly job instead of an archaeology dig. That is what a reviewer reads as a mature process, and what an auditor cannot argue with.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.