On this page
Published: · Updated:
Key Takeaways
- Cybersecurity nonconformities (vulnerabilities, exploited CVEs, failed controls, FDA deficiencies) must be processed through the same CAPA system as any other quality issue under QMSR.
- Not every CVE triggers a CAPA. The trigger is risk-based: exploitability in the device's [threat model](/services/medical-device-threat-modeling "FDA-aligned threat modeling services"), patient safety impact, and recurrence pattern.
- Cyber CAPA root cause has to address the failed control or process, not just the vulnerable component.
- Effectiveness verification on a cyber CAPA uses appropriate effectiveness tests and updates affected records; VEX is optional.
- A CAPA record is the audit artifact that proves Section 524B postmarket vulnerability handling is real and not just a policy document.
Evaluate cybersecurity findings through documented quality and risk procedures. Initiate CAPA when the assessment identifies a nonconformity or systemic process failure requiring corrective or preventive action, not automatically for every CVE, incident, or FDA question. Document investigation, actions, effectiveness, and affected records under the applicable QMSR and ISO 13485:2016 procedures.
Cybersecurity findings need documented risk and quality assessment. Not every finding is a nonconformity, and not every nonconformity requires a separate CAPA. Apply defined escalation criteria, preserve the disposition in controlled records, and link engineering corrections to CAPA where warranted.
Why this matters
The QMSR requires analysis of relevant quality data and appropriate corrective and preventive action. Section 524B(b)(1) requires a postmarket monitoring and coordinated vulnerability disclosure plan for applicable cyber-device submissions. Integrate vulnerability handling with quality procedures, while recording a risk-based decision on whether CAPA is needed.
Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); 21 CFR Part 820, Quality Management System Regulation (eCFR); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B).
What CAPA Is in a Medical Device Cybersecurity Context
The QMSR Definition
CAPA is a structured process for investigating, correcting, and preventing recurrence of quality problems. The QMSR requires procedures for analyzing nonconforming product, identifying actions needed to correct and prevent recurrence, verifying or validating the actions, implementing changes, and documenting the activities and results. The same process applies whether the nonconformity is a mechanical defect, a labeling error, or an exploitable cybersecurity vulnerability.
Why Cybersecurity Findings Belong Here
A vulnerability on a fielded device should be assessed for applicability, risk, nonconformity, and systemic failure. A patch may be a correction without requiring a separate CAPA. Where CAPA is warranted, a ticket alone is insufficient unless it forms part of controlled, complete quality records.
Corrective Action vs Preventive Action
Corrective action deals with a problem that already happened: an exploitable vulnerability in a fielded device, a failed security control, or an FDA deficiency. You find the root cause and remove it. Preventive action deals with a problem that has not happened yet. Trend data, threat intelligence, a new attack technique against a similar product, or an internal audit shows a weakness, and you change the design or process before it turns into a nonconformity. Updating a component before a known vulnerability becomes exploitable in your configuration, or adding a threat model review when a new interface is planned, are typical preventive actions. Both live in the same CAPA system under 21 CFR Part 820 and ISO 13485.
What Cybersecurity Events Trigger a CAPA
Not every CVE on the SBOM is a CAPA. The trigger is risk-based, scoped to the device's threat model.
| Event | CAPA trigger threshold |
|---|---|
| New CVE on an SBOM component | Assess applicability, risk, and whether a nonconformity or systemic failure warrants CAPA |
| Penetration test finding | Assess device risk, recurrence, and process failure against documented CAPA criteria |
| Field-reported security incident | Investigate and assess risk, nonconformity, and systemic failure; CAPA is not automatic |
| FDA cybersecurity deficiency letter | Assess the underlying documentation or process gap; an FDA question is not automatically a nonconformity |
| Failed security regression test | Triggers CAPA if the failure indicates a process gap, not a one-off test defect |
| Coordinated vulnerability disclosure (CVD) intake | Assess the validated issue against documented risk and quality escalation criteria |
| Exceeded VEX backlog SLA | Assess whether missed internal targets reveal a systemic process failure |
The decision rule is documented in the manufacturer's CAPA procedure or a referenced cybersecurity SOP. "We patched it" is not a substitute for the rule.
Root Cause Analysis for a Security Control Failure
The Two Layers
Cyber root cause analysis has to address two layers: the component layer (what made the vulnerability exploitable on this device) and the process layer (what part of the security program let the issue reach production or persist in the field). Stopping at the component layer can leave a CAPA incomplete on cyber findings.
Example
A device ships with an authentication bypass via a third-party dependency. The component-layer root cause is "library X version Y contained CVE-XXXX-XXXX." The process-layer root cause is "SBOM scanning ran only at release time, not on every dependency update, and the VEX triage SLA was not enforced." The CAPA must address both, or the same class of vulnerability will recur.
Standards That Inform the Method
ISO 14971:2019 for risk-based investigation, AAMI TIR57:2016/(R)2023 for security risk management, IEC 81001-5-1:2021 for security activities in the software lifecycle, and AAMI SW96:2023 for security risk management of medical device software all inform how a credible cyber root cause analysis is performed.
Correction, Prevention, and Effectiveness Verification
Correction
The patch, configuration change, or compensating control that eliminates the immediate nonconformity. Includes the release path (regular update, expedited patch, field correction) and the customer communication plan if the device is already deployed.
Prevention
The change to the security program that prevents the same class of issue from recurring. Common cyber prevention actions: tightening SBOM scan cadence, adding a security regression test for the affected control, updating the threat model to capture the missed attack path, revising the secure coding standard, or adding a checkpoint to the design review.
Effectiveness Verification
[RECOMMENDED PRACTICE] Verify corrective-action effectiveness using tests appropriate to the root cause, and update affected controlled records. Refresh the SBOM when components change, and update the threat model and risk assessment as applicable. VEX may communicate the result but is not a required CAPA artifact.
The verification record should link to relevant effectiveness evidence and updated controlled records. Close the CAPA according to approved procedures and effectiveness criteria, not a universal SBOM/VEX checklist.
Setting Up a CAPA Procedure That Handles Cybersecurity
Most manufacturers already have a CAPA procedure. The work is making it handle security events without a parallel process.
See also: Does FDA 524B Apply to Legacy Medical Devices?, FDA Section 524B Subsections Explained, and 510(k) Cleared, No Postmarket Cybersecurity: Legal?.
- Scope. State in the procedure that cybersecurity nonconformities are in scope, and reference the cybersecurity SOP that holds the trigger table above.
- Roles. Name who triages security events, who owns the CAPA, and who signs off on effectiveness. Security engineers investigate; quality owns the record.
- Intake sources. List every place a security event can come from: SBOM monitoring, penetration test reports, CVD intake, field service, complaints, audits, and FDA correspondence.
- Root cause method. Five Whys and fishbone diagrams both work, as long as the template forces an answer at the process layer, not just the component.
- Records and tooling. Link the CAPA record to the security ticket, the SBOM/VEX entry, the threat model revision, and the test evidence. Whatever eQMS or tracker you use, the links are what an inspector follows.
- Training. When a prevention action changes a procedure or coding standard, train the people affected and keep the training record with the CAPA.
How Cyber CAPA Ties to Section 524B Postmarket Obligations
The Statutory Hook
Section 524B(b)(1) requires a plan to "monitor, identify, and address" postmarket cybersecurity vulnerabilities. The the FDA's February 3, 2026 final premarket cybersecurity guidance expects that plan to integrate with QMSR processes rather than run as a parallel security-only workflow. CAPA is the integration point.
What This Looks Like in Practice
The postmarket cybersecurity plan references the CAPA procedure as the mechanism for handling validated vulnerabilities above defined risk thresholds. The CAPA procedure references the postmarket plan, the threat model, and the SBOM/VEX workflow as inputs. Inspections look for both directions of the reference, plus the actual CAPA records that demonstrate the loop ran.
What Reviewers and Inspectors Look For
- A documented decision rule for when a vulnerability triggers a CAPA versus a routine patch.
- CAPA records showing investigation, root cause at both layers, correction, prevention, and effectiveness verification.
- Linkage from the CAPA record to the threat model update, SBOM/VEX refresh, and any customer security advisory.
- Trending of cyber CAPA data into management review under the QMSR's management responsibility requirements.
Talk to us about your postmarket cybersecurity program if your CAPA process is not yet wired to your vulnerability management workflow.
Need help? Our team supports manufacturers with FDA cybersecurity submissions end-to-end. Explore our medical device cybersecurity services or book a discovery call.
How Blue Goat Approaches Cyber CAPA
We build the bridge between the security team's vulnerability response and the quality system's CAPA loop. Our approach starts with a written decision rule for when a cybersecurity event triggers a CAPA, anchored to the device's threat model and risk acceptance criteria. We instrument the SBOM and VEX workflow so that triage outcomes flow into CAPA initiation automatically, and we structure the root cause template to require both component-layer and process-layer analysis. Our team holds CISSP, OSCP, and prior military red-team credentials, and we ground our work in QMSR, Section 524B, the February 3, 2026 final premarket cybersecurity guidance, AAMI SW96:2023, IEC 81001-5-1, and ISO 14971. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Start with our FDA deficiency response service or our postmarket SBOM and VEX monitoring service.
After clearance, our postmarket cybersecurity services cover vulnerability monitoring, patch planning, and incident response for devices in the field.
Related reading: FDA Cybersecurity Major vs Minor Deficiency: How Reviewers Grade Findings.
FAQ
When does a medical device cybersecurity vulnerability require a CAPA?
Evaluate vulnerabilities through documented risk and quality procedures. Open a CAPA when the assessment identifies a nonconformity or systemic process failure requiring corrective or preventive action. An affected VEX status, CVD report, or FDA question does not automatically require a separate CAPA. VEX is optional.
Is a patch release the same as closing a CAPA?
No. A patch can be the immediate correction. If a CAPA was opened, close it only after the investigation, appropriate corrective actions, and effectiveness review meet approved procedures. Update affected SBOM and risk records when needed; VEX is optional.
How does cyber CAPA relate to the FDA Section 524B postmarket plan?
The postmarket cybersecurity plan describes how the manufacturer monitors, identifies, and addresses vulnerabilities. CAPA is how the plan actually closes findings inside the quality system. The postmarket plan references the CAPA procedure as the closure mechanism, and the CAPA procedure references the postmarket plan, threat model, and SBOM/VEX workflow as inputs. Inspectors expect both references and actual records.
Does the FDA require a CAPA process?
Yes. The QMSR (21 CFR Part 820, which incorporates ISO 13485:2016 by reference) requires documented corrective and preventive action procedures. Cybersecurity nonconformities that affect device safety or effectiveness fall under the same requirement as any other quality problem.
What is the difference between corrective and preventive action in cybersecurity?
Corrective action removes the root cause of a problem that already occurred, such as an exploitable vulnerability in a released device. Preventive action removes the cause of a potential problem before it occurs, based on trends, threat intelligence, or audit results.
Do penetration test findings need CAPAs?
Not automatically. Assess applicability, patient and security risk, recurrence, and process failures using approved CAPA criteria. A CVSS severity label alone does not establish a regulatory CAPA trigger.
What is a potential cyber CAPA defect the FDA observes?
Root cause stopping at the vulnerable component. The CAPA names the CVE, documents the patch, and closes. Inspectors then ask what changed in the security program to prevent the next instance, and the record has nothing. The fix is to require the root cause template to address both the component layer and the process layer, and to require a prevention action that modifies a procedure or control, not just the codebase.
Where do CAPAs on cyber events show up in management review?
QMSR requires management review to consider quality data trends. Cyber CAPA trends (open count, time to closure, recurrence rate, severity mix) belong in that review, alongside complaints, audit findings, and process monitoring. Treating cyber CAPA data as security-only and excluding it from management review is itself an observation risk.
Ready to wire cybersecurity findings into your CAPA system?
If your security team is closing vulnerabilities in a ticketing tool while your quality system has no record of the loop, you have an inspection exposure and a Section 524B alignment gap. We can build the bridge. If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. Schedule a discovery call.
Christian Espinosa, Founder, Blue Goat Cyber. Christian has led premarket and postmarket cybersecurity programs for connected medical devices across Class II and Class III submissions and previously commanded military red-team operations. Read more at christian-espinosa.
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.
Sources & references
Primary sources cited in this article. Links open in a new tab.
