For each third-party CVE, I start with one controlled record that links the affected device to the risk, decision, and result. My first step: check the component version, device build, and attack path before choosing a response.
Here’s what I document:
- Exposure: Which devices are affected, what an attacker needs, and which sources support the findings.
- Patient-safety risk: How an exploit could affect device function or patient care - and whether tested controls reduce that risk.
- Decision: Remediation, temporary mitigation, risk acceptance, monitoring, or escalation, with named owners, approvals, and deadlines.
- Action and closure: Test results, deployment records, remaining exceptions, and triggers for another review.
I keep FDA requirements, guidance, and internal procedures separate. An internal 30-day target is not a universal FDA deadline, and <u>documentation alone does not establish FDA compliance</u>.
Before closing a case, I ask: Could another reviewer follow my evidence and reach the same decision? Supplier tools can help collect records, but they do not replace manufacturer testing, safety review, or regulatory decisions. And closure does not end monitoring.
Third-Party CVE Documentation: From Intake to Monitoring
Case Study: Why FDA Cybersecurity Expectations Are Really QMS Expectations
sbb-itb-535baee
Identify the CVE and Check Device Exposure
Use the intake record to move from component inventory to exposure triage. Open a controlled intake record before deciding applicability or disposition. Assign one cybersecurity reviewer and one engineering reviewer to confirm component presence, configuration, and clinical function.
Set the review deadline using the approved procedure and documented risk factors - not CVSS alone. Shorten the review interval for KEV-listed CVEs, observed exploitation, internet-facing interfaces, unsupported components, or critical clinical functions.
Record CVE Details and Sources
Record the CVE identifier, title, description, exact component version, supplier, and source package or code origin. Include the device model, release, configuration, SBOM reference, and advisory or database sources for the affected model, branch, and release. Tie the record to the specific device build and deployment.
Also record publication and internal discovery dates, component support status, end-of-support date, owners, workflow state (open, under review, or closed), and next review date. Link related supplier communications, complaints, CAPA records, and change records where applicable.[3][1]
Keep dated copies or immutable references to the original supplier advisory, CVE/NVD entry, product security bulletin, SBOM version, and any internal detection output. For each source, record its name, URL or document identifier, retrieval date, analyst, and the exact evidence used.
Record the CVSS version, score, and vector, along with exploitation evidence, CISA KEV status, and the date that status was checked. A CVE can still be exploitable even if it isn't listed in KEV.[8][9]
Check Applicability and Exploit Conditions
Use the SBOM, build manifest, and deployment records gathered above to complete an evidence-linked checklist for each relevant model, software branch, and deployed release - not just the latest SBOM.
Verify component presence against build manifests, package inventories, or installation records. Check whether the vulnerable code is enabled and reachable, and whether the required access, privileges, authentication, features, inputs, or operating modes exist. Mark each condition present, absent, unknown, or not applicable. Link the exact configuration output, network diagram, supplier evidence, or test result supporting each finding.[3][6][7]
| Exposure result | Required basis |
|---|---|
| Not affected | Evidence shows that the vulnerable component or affected code is absent, or that the version falls outside the affected range. |
| Affected but not exploitable | Vulnerable code is present, but verified configuration or architecture prevents the required exploit conditions in this configuration. |
| Affected and exploitable | The vulnerable code and relevant attack path or prerequisites are present. |
| Undetermined | Inventory, configuration, supplier, or testing evidence is incomplete. Keep the investigation open. |
For configuration-dependent findings, record the control, verification method, assessor, date, exact deployment scope, and conditions under which the finding remains valid. Document each assumption with an owner, evidence, and verification method. Segmentation or authentication alone isn't proof - verify the attack path.
Define reassessment triggers, such as feature enablement, network changes, supplier corrections, new exploit evidence, KEV listing, or a failed control. Missing evidence does not prove that the device is unaffected.[2][5]
Carry the exposure result into the patient-safety risk assessment.
Assess Patient-Safety Risk and Choose a Response
Use the exposure result to determine whether the CVE poses a patient-safety risk in this device.
Assess Device Function and Patient-Care Impact
Connect exploitability to patient harm. Identify the clinical functions and essential performance that could be compromised. This is critical because cyberattacks on medical devices directly threaten patient care. Treat CVSS, supplier input, and exploit intelligence as inputs - not the decision itself. FDA’s postmarket guidance recommends assessing exploitability, the severity of potential patient harm, and how well controls work.[6]
Assess confidentiality, integrity, availability, effects on connected systems, and care disruption. In the risk-management file, link each supported cybersecurity failure scenario to a hazardous situation and possible harm. Record the affected patient population, disruption duration, detectability, safeguards, and uncertainty. Keep security and safety assessments separate but linked so technical findings reach the safety review.[4][6]
Check whether controls cover the attack path, depend on device configuration and operating conditions, work during normal operation, and add burdens to clinical care. Cybersecurity and engineering reviewers validate technical findings. Clinical, safety, or human-factors reviewers assess patient harm. Quality confirms traceability, while regulatory affairs handles reporting and field actions. Record reviewer names, approval conditions, and unresolved disagreements.[6]
Use these findings to choose remediation, mitigation, acceptance, monitoring, or escalation.
Set Decision Criteria and Approval Rules
Use preapproved risk-acceptance criteria, not a universal CVSS cutoff. Record the decision, rationale, responsible owner, and deadline. The matrix below sets out the evidence needed for each decision. Approval authority should follow the organization’s controlled procedures.[6]
Assign one disposition based on the safety assessment.
| Disposition | Entry criteria | Required approvers | Controls | Deadline or trigger | Completion evidence |
|---|---|---|---|---|---|
| Remediate | Applicable vulnerability with unacceptable or inadequately controlled risk; patch or replacement is feasible | Engineering, cybersecurity, quality, and regulatory reviewers as required | Segmentation, access restriction, monitoring, or an operational workaround | Approved risk-based deadline; sooner if active exploitation or serious safety impact exists | Validated fix, regression and safety tests, release record, deployment evidence, updated risk file |
| Temporary mitigation | Permanent fix is unavailable, unsafe to deploy immediately, or requires development time; risk can be reduced temporarily | Cybersecurity, engineering, safety/clinical, and quality owners | Disable a feature, restrict ports, isolate the network, strengthen authentication, increase monitoring, or provide a user workaround | Time-limited expiration and periodic review | Control implementation records, effectiveness testing, user instructions, monitoring results, owner and expiration date |
| Residual-risk acceptance | Residual risk meets approved criteria after controls | Designated risk owner and authorized quality/safety or management approver | Maintain validated controls and surveillance | Review at defined intervals or upon triggering events | Signed rationale, residual-risk calculation, control evidence, approval, reassessment date |
| Monitoring | Current evidence does not show an unacceptable impact, but exploitability, exposure, or threat conditions may change | Cybersecurity and product owner; quality oversight as defined | Vulnerability intelligence, logs, supplier updates, and incident monitoring | Defined monitoring frequency and escalation threshold | Monitoring plan, review results, alerts, and documented reassessment |
| Not applicable / not exploitable | Device is not affected or the attack path is blocked | Engineering and cybersecurity; quality review where required | Preserve the operating-condition or configuration control supporting the determination | Reassess after configuration, version, architecture, or threat changes | Evidence package, rationale, reviewer approval, traceability to device versions |
| Escalation | Active exploitation, unacceptable residual risk, unresolved safety impact, inadequate evidence, or missed remediation deadline | Cross-functional safety, quality, regulatory, and management authorities | Immediate containment and customer or field actions as approved | Immediate or procedure-defined response time | Escalation record, containment decision, communications, regulatory assessment, corrective-action plan |
For escalation, follow approved procedures when there is active exploitation, unacceptable residual risk, or unresolved safety impact. Record the trigger, discovery time, affected products, containment decision, decision authority, and next review time. Escalation must produce a decision or action - not an indefinite referral.[6]
Document Risk Acceptance, Mitigation, and Remediation
For each chosen disposition, document the evidence described below and link it to controlled risk, quality, and change records. Follow procedure-based approval levels, deadlines, and escalation rules. Keep supporting evidence, decision-maker authority, the approval date, and the review or expiration date.[2][4][5] Use separate records for acceptance, temporary controls, and remediation.
Approve Risk Acceptance and Test Temporary Controls
Explain why the residual risk meets approved acceptance criteria, and link the evidence showing that controls work. Record the owner, approval conditions, review or expiration date, and reassessment triggers. Acceptance status alone is not evidence.[2][4][5]
Write temporary-control records as deployment instructions. Include the control, affected models and versions, prerequisites, owner, deadline, notifications, rollback steps, monitoring requirements, and exit criteria for removing the control.
Keep the test environment, configuration, test cases, expected and actual results, deviations, and clinical or safety approval. Testing must cover affected workflows, alarms, connectivity, data integrity, timing, availability, interoperability, and essential performance.[2][5]
Plan Remediation and Keep Test Records
Use a controlled change/CAPA record to link supplier dependencies, owners, milestones, exceptions, and escalation thresholds to the CVE. Attach:
- Verification, validation, cybersecurity testing, and safety assessments for the exact build and configuration.
- Rollout scope, notices, rollback provisions, installation confirmations, failed updates, and open exceptions.
- Regulatory reviewers’ documented decisions on FDA reporting, correction, removal, and submission, including the reasons when no FDA action is required.
A supplier fix statement does not replace manufacturer testing or deployment verification.[2][6]
Coordinate Supplier Risk Reviews With Censinet
Use supplier-review workflows with Censinet to collect evidence for remediation records. Coordinate affected-version data, mitigation instructions, patch timelines, and supporting evidence.
Export or link reviewed evidence into manufacturer-controlled records for retention. Platform records help teams coordinate, but they are not proof of FDA compliance and do not replace approved quality records, testing, deployment verification, or safety and regulatory decisions.
Close CVE Records and Prepare for Audits
After the response is complete, close the record only when the approved disposition and required evidence are complete, with a traceable audit trail. Keep using the controlled case record from intake, assessment, and remediation, and preserve its history in controlled records.
Define Closure Evidence for Each Disposition
Keep the disposition visible after closure. Use the same case ID throughout intake, triage, risk assessment, and change control.
| Disposition | Closure evidence and criteria |
|---|---|
| Open | Document pending actions and interim controls. Keep the record open until the required action is complete. |
| Accepted | Retain the risk assessment, residual-risk rationale, approval, and controls, along with the owner and review or expiration date. |
| Mitigated | Include the control specification, configuration, and effectiveness test evidence. Confirm that the control is implemented and verified to reduce risk to the approved level. |
| Remediated | Include the approved change record, deployment evidence, and validation results. Confirm that the fix is approved, deployed to the affected population, and verified. |
| Not applicable | Include device/build and component inventory, SBOM or supplier evidence, technical rationale, and reviewer approval proving no impact. |
An available patch is not a deployed patch. Link closure to the affected population, remaining exposure, approvals, tests, deployment records, and field communications. Include risk assessment and SBOM updates where applicable.
With that evidence in place, check that the record still supports audit replay.
Check Record Traceability and Reassessment Triggers
Run a short audit check: can an independent, qualified reviewer identify the build, reproduce applicability, understand impact, and verify approvals? This process is vital for managing medical device security risks effectively. Make sure the record includes component versions, decision criteria, supplier evidence, testing, deployment exceptions, closure dates, and next review dates.
Define what would reopen the record: new exploitation evidence, revised advisories, control failure, configuration or connectivity changes, supplier support expiration, defective patches, and related incidents. Assign an owner to evaluate each trigger. Closing the record must not end monitoring.
Conclusion: Keep the Complete Decision Trail
For audit readiness, test the record itself - not just the technical fix. Use a standard, access-controlled template to connect identify → verify → assess → decide → act → close → monitor. Each CVE should trace to exposure, patient-safety risk, ownership, its approved disposition, and completion evidence.
Check one existing closed CVE against the audit checklist now. If an independent reviewer cannot reproduce the decision, repair the record before the next audit.
FAQs
How should I handle conflicting supplier and internal CVE findings?
Check the supplier’s advisory against your SBOM, build records, and deployed environment to confirm whether vulnerable code is present and reachable. Ask the supplier for affected versions, attack prerequisites, and exploitation data.
If the facts are still unclear, assume exposure and escalate. Mark a finding as unaffected only when documented evidence shows that the vulnerable code or required attack path is absent. Record a clear, audit-ready rationale for your final decision.
When does a third-party CVE require FDA reporting?
Most cybersecurity patches do not require FDA reporting under 21 CFR Part 806.10 if they introduce no new risks and cause no patient harm. If a patch addresses an uncontrolled safety risk that could cause death or serious injury, reporting is required within 10 working days of initiating action.
For major cases, document the reporting assessment, including the applicable pathway, facts considered, deadlines, and final approval. This keeps the record ready for an audit.
How long should I retain closed CVE records?
Under the FDA’s Total Product Lifecycle framework, retain closed CVE records for the device’s lifetime, plus a defined period, so they’re available for audits.
Store intake records and internal risk documentation in an accessible system of record within your quality system and risk management file. Keep a clear trail from the first vulnerability report through remediation and closure. This documentation supports regulatory reviews, audits, and lessons learned.
