Section 524B(b) made the postmarket vulnerability plan a premarket question. FDA wants to see, before clearance, how you will monitor for vulnerabilities, decide which ones matter, and get patches into the field. And the 2016 postmarket guidance already defined the fork every one of those decisions runs through: controlled or uncontrolled risk.
This example SOP is the shape of the answer. It commits to named sources (NVD, SBOM disclosures, Health-ISAC, CISA, customer complaints), to clocks (internal notification within one business day, customer communication within 5 business days for uncontrolled issues and 60 days for controlled ones), and to annual penetration testing of every fielded configuration. The clocks are what auditors check first. A plan without timeframes reads as no plan.
Bracketed fields are placeholders to adapt to your organization. Most of the monitoring and assessment described here is work we automate with ELTON, but the SOP has to exist either way. It is your commitment; tooling is just how you keep it.
[Organization] shall maintain a vulnerability management plan for each product release. The process covers risk assessment of potential vulnerabilities in the system, response planning when vulnerabilities are identified, and communication with customers, regulatory agencies, and vulnerability monitoring groups.
[Organization] follows a shared responsibility model for the system as deployed in a customer's environment. Customers are responsible for monitoring the systems on which [Organization] software runs (Windows based PCs, for example) for incidents such as malware detection or network intrusion, and for notifying [Organization] of suspected incidents.
The process includes six activities at minimum: threat monitoring and intelligence, vulnerability risk assessment, response planning, communications planning, patch development and testing, and patch deployment.
[Organization], with its development partners, continuously monitors threat intelligence sources including, at minimum:
A [monthly / quarterly / yearly] review of software and systems design documentation assesses needed updates, cybersecurity included, and feeds the same process. So does annual cybersecurity testing (penetration testing at minimum) of every product configuration currently deployed. On detection of a vulnerability in a system component, the [Cybersecurity Team] notifies product management within [1 business day] and initiates the assessment.
Each vulnerability gets a clinical and cybersecurity risk assessment based on the report in hand (a CVE, a researcher report, a complaint) and on the threat model, architectural views, and risk assessments created during design. [SOP: Cybersecurity Risk Assessment] governs the method, and each assessment is documented as a separate risk assessment using [TMP: Cybersecurity Risk Assessment].
If the vulnerability is controlled (acceptable), patching may ride the normal release schedule, though a high visibility or high criticality issue may still warrant customer and regulator communication regardless of patient safety impact. If it is uncontrolled (unacceptable, and a benefit risk assessment cannot justify acceptance), the expedited response, communication, and patch process below applies.
Response planning produces a customer communication describing the vulnerability, its impact on the system, available mitigating controls, and the timeframe for a remediating patch.
Every vulnerability that could affect the product, controlled or not, gets candidate mitigations. These can be temporary actions (disconnecting the device from the network) or design controls that prevent exploitation outright (an on device firewall blocking inbound connections to a vulnerable HTTP server). Permanent design controls are documented in the vulnerability risk assessment. Temporary controls are not.
Where mitigations available to the device owner, customer, or user cannot sufficiently control the risk, [Organization] creates a [Development Plan] for a software patch. The plan includes review and update of related cybersecurity documentation: the threat model and architectural views, cybersecurity risk assessments, SBOMs, and the Cybersecurity Risk Management Report. The [Cybersecurity Team] determines whether the severity of the vulnerability or the scope of change requires penetration testing before the patch ships.
For systems updated by end users, instructions cover four things: identify the software version obtained, verify the download is authentic, apply the patch, and verify the installed version afterward. For systems updated by [Organization] personnel, internal instructions cover retrieving the update from version control, verifying authenticity before deployment, installing, and confirming the correct version is running.
Penetration testing of each fielded release happens at least annually, documented as a penetration test report identical to the one required at release. When a release no longer exists in the field, its re-testing obligation ends.
Two details make this SOP defensible: the clocks and the loop. Committed timeframes turn good intentions into something an auditor can verify. And annual re-testing means the plan keeps generating inputs instead of going quiet the day the product ships.
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.