FDA Cybersecurity Unresolved Anomalies Table: How to Document Vulnerabilities and Residual Risk in Premarketing Submissions
How to build the Unresolved Software Anomalies table for FDA premarket cybersecurity submissions — CVSS scoring, exploitability assessment, clinical impact analysis, compensating controls, SBOM linkage, VEX status, labeling language, release criteria, and common reviewer objections.
What This Article Covers / Does Not Cover
This article addresses one artifact: the Unresolved Software Anomalies table (sometimes called the unresolved anomalies document or cybersecurity anomaly assessment) required in FDA premarket submissions for cyber devices. It covers the data fields, scoring methodology, SBOM linkage, VEX integration, labeling impact, release decision criteria, and common reviewer objections specific to this document.
It does not cover general cybersecurity program setup, threat modeling methodology, SBOM generation tooling, penetration testing methodology, or ISO 14971 Risk Management safety risk management processes. For broader cybersecurity submission guidance, see Medical Device Cybersecurity and FDA Cybersecurity Premarket Deficiencies. For SBOM-specific requirements, see SBOM for Medical Devices.
Background: Why FDA Requires the Unresolved Anomalies Table
FDA's February 2026 revised guidance, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," requires premarket submissions to include a cybersecurity-specific assessment of unresolved software anomalies. This guidance updated the June 2025 version to align with the Quality Management System Regulation (QMSR, amended 21 CFR Part 820), which incorporates ISO 13485:2016 by reference.
Section V.A.5 of the guidance addresses "Security Assessment of Unresolved Anomalies" directly. This is a distinct requirement from the general unresolved anomalies document in the eSTAR template. Where the eSTAR unresolved anomalies section addresses software defects broadly, the cybersecurity assessment specifically evaluates each unresolved anomaly for its security implications -- exploitability, attack surface contribution, and potential to compromise device safety or data integrity.
For devices qualifying as "cyber devices" under Section 524B of the FD&C Act, unresolved vulnerabilities must be assessed for patient safety impact. Section 524B(b)(2) requires manufacturers to "design, develop, and maintain processes and procedures that provide a reasonable assurance that the device and related systems are cybersecure." Leaving vulnerabilities unassessed in a released device is inconsistent with that statutory mandate.
The practical stakes are significant. Medcrypt's 2026 analysis of FDA deficiency letters shows that submissions are being flagged for "unresolved findings" -- including those labeled Low or Medium risk -- when they lack documented mitigation strategies, acceptance criteria, or by-design justification. RunSafe's 2026 Medical Device Cybersecurity Index reports that 24% of healthcare organizations experienced a cyberattack targeting a medical device, and 80% of those organizations reported the attack impacted patient care. Reviewers are scrutinizing unresolved anomalies with that backdrop in mind.
Unresolved Anomalies Table: Required Data Fields
The following table describes the minimum data fields expected in a cybersecurity unresolved anomalies assessment. Not every field applies to every anomaly, but the table structure should accommodate all of them.
| Data Field | Description | Source Document | Example |
|---|---|---|---|
| Anomaly ID | Unique identifier traceable to the defect tracking system | Defect tracker (Jira, Azure DevOps, etc.) | CYBER-2026-0042 |
| Description | Concise description of the anomaly and its security relevance | Defect tracker, penetration test report | "TLS certificate validation disabled in diagnostic port communication" |
| Discovery Method | How the anomaly was identified | Pen test report, SAST/DAST output, SBOM vulnerability scan, internal review | "Penetration test (PT-2026-003, finding 7)" |
| CVSS Base Score | CVSS v3.1 or v4.0 base score with vector string | CVSS calculator output | "7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)" |
| CVSS Temporal Score | Temporal score reflecting current exploit maturity | CVSS calculator, threat intelligence | "6.5 (E:U/RL:O/RC:C)" |
| Exploitability Assessment | Whether a practical exploit exists or is feasible | Threat intelligence, CVE databases, penetration test results | "No known public exploit; proof-of-concept code exists but requires local access" |
| Clinical Impact Assessment | Assessment of how the anomaly could affect patient safety or clinical workflow | Risk management file, clinical engineering review | "Moderate -- could delay diagnostic results if exploited, causing treatment postponement" |
| Compensating Controls | Controls that reduce the risk of the anomaly being exploited | Architecture documentation, security controls matrix | "Diagnostic port restricted to service-mode only; port disabled during normal operation; network segmentation enforced" |
| Residual Risk Level | Risk level after compensating controls are applied | Security risk assessment | "Low" |
| SBOM Component Link | Reference to the specific SBOM component associated with the anomaly | SBOM (CycloneDX or SPDX) | "Component: openssl v3.1.2 (CycloneDX ref: comp-89)" |
| VEX Status | Vulnerability Exploitability eXchange status | VEX document | "Affected" |
| VEX Justification | Justification code per CISA VEX minimum requirements | VEX document | "Vulnerable code is present and executed in the attack path" |
| Planned Resolution | Planned fix or mitigation and associated timeline | Sprint planning, roadmap | "Upgrade to OpenSSL 3.2.1 in release 4.3.0, scheduled Q3 2026" |
| Target Version | Software version in which the anomaly will be resolved | Release planning | "v4.3.0" |
| Labeling Impact | Whether the anomaly requires labeling or IFU updates | Labeling review | "Yes -- add cybersecurity considerations section describing diagnostic port restrictions" |
| Release Decision | Justification for releasing with the anomaly unresolved | Risk management file, release board minutes | "Release approved per risk acceptance criteria; residual risk within acceptable bounds per RF-2026-018" |
CVSS Scoring and Exploitability Assessment
Scoring Each Anomaly
Each unresolved anomaly must be scored using CVSS v3.1 or, increasingly, CVSS v4.0. The base score captures the intrinsic qualities of the vulnerability: attack vector, attack complexity, privileges required, user interaction scope, and impact on confidentiality, integrity, and availability. The temporal score reflects the current state of exploitability and remediation availability.
The environmental score is where medical device context becomes critical. FDA's Medical Device Development Tool (MDDT) qualified CVSS Supplemental Rubric (documented in the MDDT Summary of Evidence SEBQ) adds healthcare- and patient-safety-specific environmental metrics that go beyond generic IT scoring. This rubric instructs assessors to weight availability and integrity impacts differently when a device directly supports patient care, reflecting the reality that a denial-of-service condition on an infusion pump is fundamentally different from the same condition on a web server.
Cybersecurity Risk vs. ISO 14971 Safety Risk
Cybersecurity risk assessment for unresolved anomalies is fundamentally different from ISO 14971 safety risk assessment. ISO 14971 uses probability of occurrence multiplied by severity of harm. Cybersecurity risk uses exploitability-based assessment: how feasible is the attack, what is the attacker's required access level, and what is the impact if the exploit succeeds. An anomaly that is extremely unlikely to occur randomly (e.g., a buffer overflow requiring a crafted network packet) may be trivially exploitable by a determined attacker. CVSS captures this distinction; probability-based scoring does not.
Scoring Decision Table
| CVSS Score Range | Exploitability Level | Expected Documentation |
|---|---|---|
| 0.0 - 0.0 (Informational) | Not exploitable | Document in table; no compensating controls required |
| 0.1 - 3.9 (Low) | Exploitable with significant effort or constraints | Document in table with monitoring plan; compensating controls recommended |
| 4.0 - 6.9 (Medium) | Exploitable with moderate effort | Document in table with compensating controls; include in Cybersecurity Management Plan for postmarket monitoring |
| 7.0 - 8.9 (High) | Readily exploitable | Fix required before release in most cases; if compensating controls justify deferral, clinical review sign-off required |
| 9.0 - 10.0 (Critical) | Trivially exploitable with significant impact | Fix required before release. Do not include in unresolved anomalies table -- resolve the anomaly. |
Clinical Impact Assessment Matrix
Each anomaly requires a clinical impact assessment that evaluates what happens to the patient if the vulnerability is exploited. This is distinct from the CVSS technical impact score. A CVSS 9.8 vulnerability that exposes device telemetry data may have a lower clinical impact than a CVSS 6.5 vulnerability that could disable an alarm.
| Clinical Impact Level | Description | Required Evidence | Example |
|---|---|---|---|
| No impact | Exploitation does not affect device functionality, patient data, or clinical workflow | Technical analysis confirming isolation from clinical functions | "Error logging endpoint exposes internal paths; no clinical data or functions affected" |
| Low -- minor workflow disruption | Exploitation causes minor inconvenience or workflow delay without affecting clinical outcomes | Workflow analysis, clinical engineering review | "Slow response in device management UI; no impact on therapeutic delivery" |
| Moderate -- delayed diagnosis/treatment | Exploitation could delay diagnostic results or treatment initiation | Clinical impact analysis with estimated delay ranges | "Network DoS could delay image transfer by up to 30 minutes; clinical protocol allows 45-minute window" |
| High -- potential patient harm | Exploitation creates a credible pathway to patient injury | Clinical risk analysis, clinical engineering sign-off, compensating controls documentation | "Unauthorized parameter modification possible via diagnostic port in service mode; service-mode interlock and physical access requirement reduce likelihood" |
| Critical -- multi-patient harm or death | Exploitation could simultaneously affect multiple patients or cause death | Clinical risk analysis, independent clinical review, release board approval with documented justification | "Vulnerable library used in dose calculation; exploit could alter calculation results for multiple patients concurrently" |
Compensating Controls Documentation
What Qualifies as a Compensating Control
A compensating control is a technical, administrative, or physical safeguard that reduces the likelihood or impact of an unresolved anomaly being exploited. For the unresolved anomalies table, controls must be documented with sufficient specificity that a reviewer can independently assess whether the control adequately mitigates the risk.
How Compensating Controls Affect Environmental CVSS Score
Compensating controls modify the environmental metrics in the CVSS score. For example, if a vulnerability requires network access (AV:N) but the device is deployed on a segmented VLAN with no internet egress, the Modified Attack Vector (MAV) can be set to reflect the restricted access. If authentication is not required by the vulnerability (PR:N) but the device requires physical badge access to the room, the Modified Privileges Required (MPR) reflects that constraint. Each control should map to a specific CVSS environmental metric modification.
Compensating Controls Reference Table
| Control Type | Example | How It Reduces Risk | Documentation Required |
|---|---|---|---|
| Network segmentation | Device on isolated VLAN, no internet egress | Reduces attack vector from network to local/physical | Network architecture diagram, VLAN configuration, firewall rules |
| Authentication requirements | Mutual TLS required for all device communication | Prevents unauthorized system from exploiting vulnerability | Authentication architecture, certificate management procedure |
| Monitoring and detection | SIEM integration with anomaly detection for diagnostic port activity | Enables rapid response if exploitation is attempted | Monitoring configuration, alert thresholds, incident response procedure reference |
| Configuration hardening | Unnecessary services disabled, default credentials changed | Reduces attack surface available for exploitation | Hardening checklist, configuration baseline, verification test results |
| Physical access controls | Device installed in restricted-access room with badge entry | Limits exploitability to authorized physical access holders | Physical security requirements in deployment guide |
| Encryption at rest | Patient data encrypted using AES-256 on local storage | Reduces impact of confidentiality-focused vulnerabilities | Encryption specification, key management procedure |
| Input validation | Server-side input validation on all external-facing interfaces | Prevents injection-based exploitation of downstream vulnerability | Input validation specification, test results |
| Failsafe defaults | Device enters safe state on communication failure or integrity check failure | Limits duration and severity of exploitation impact | Failsafe design specification, test results |
SBOM Linkage and VEX Integration
Linking Anomalies to SBOM Components
Each anomaly in the unresolved anomalies table must link to a specific component in the Software Bill of Materials. Whether the SBOM is in CycloneDX or SPDX format, the linkage should use a unique component identifier (package URL or CycloneDX BOM reference) so a reviewer can trace from anomaly to component to vulnerability record.
VEX Status Values
The Vulnerability Exploitability eXchange (VEX) document, per CISA's Minimum Requirements for VEX (April 2023), assigns one of the following statuses to each vulnerability:
- Not Affected: The vulnerable component is present but the vulnerability does not affect this device
- Affected: The vulnerability affects the device and is unresolved
- Fixed: The vulnerability has been remediated in the current version
- Under Investigation: Analysis is in progress
- In Triage: Vulnerability has been identified but not yet assessed
VEX Justification Codes
For vulnerabilities marked "Not Affected," VEX requires a justification code from the CISA minimum requirements:
- Component not present: The vulnerable component is not included in the device
- Vulnerable code not present: The component is present but the specific vulnerable code path has been removed or was never included
- Vulnerable code not executed: The vulnerable code exists but is never called in the device's execution path
- Vulnerable code not in execution path: The vulnerable code is reached but is not in the path that could lead to the security impact
- Inline mitigation already present: The device includes a compensating control within the code that prevents exploitation
Why VEX Reduces Reviewer Noise
Without VEX, a reviewer scanning an SBOM with 200 components and 50 associated CVEs must assess all 50 vulnerabilities independently. With VEX, the manufacturer pre-classifies each CVE: 35 are "Not Affected" with justification codes, 10 are "Fixed" in the current version, and 5 are "Affected" and appear in the unresolved anomalies table with full documentation. The reviewer can focus on the 5 that matter.
Traceability Table
| Anomaly ID | SBOM Component | CVE | VEX Status | VEX Justification | Risk File Reference |
|---|---|---|---|---|---|
| CYBER-2026-0042 | openssl v3.1.2 | CVE-2026-XXXXX | Affected | -- | SRM-2026-018 |
| CYBER-2026-0043 | libcurl v8.1.0 | CVE-2025-YYYYY | Not Affected | Vulnerable code not in execution path | -- |
| CYBER-2026-0044 | linux-kernel v5.15 | CVE-2026-ZZZZZ | Affected | -- | SRM-2026-019 |
| -- | jackson-databind v2.14.0 | CVE-2025-WWWWW | Fixed | -- (fixed in current build) | -- |
| -- | log4j v2.17.1 | CVE-2021-44228 | Not Affected | Vulnerable code not present (mitigated in v2.17.1) | -- |
Labeling and IFU Impact Assessment
When Unresolved Anomalies Require Labeling Updates
FDA's guidance Section VI.A requires that labeling address residual cybersecurity risks that are relevant to the device user. An unresolved anomaly requires a labeling update when:
- The anomaly could be triggered or exacerbated by user action (e.g., connecting the device to an unapproved network)
- The anomaly affects how the device should be deployed or configured to maintain security
- The user needs to take specific action to maintain the effectiveness of a compensating control
- The anomaly creates a condition the user should be able to recognize and report
What to Include in Labeling
For each anomaly that requires labeling impact, the Instructions for Use (IFU) or operator manual should include:
- A description of the residual risk in terms the intended user can understand
- Any configuration or deployment requirements that support compensating controls
- Instructions for recognizing indicators of potential exploitation
- Reporting instructions for suspected cybersecurity incidents
Illustrative Labeling Language
The following is illustrative only. Actual labeling language must be developed in coordination with regulatory affairs, clinical, and legal review.
Cybersecurity Considerations
This device uses encrypted communication channels for all data transmission. To maintain device security:
- Connect the device only to approved hospital networks with active network monitoring
- Do not connect the device to public or unsecured wireless networks
- Report any unexpected device behavior, including unexplained restarts or communication errors, to [manufacturer contact] immediately
- Ensure the device is installed in a restricted-access area as specified in the installation guide
The device diagnostic port is active only during authorized service operations. Contact [manufacturer] if the diagnostic port indicator is illuminated during normal operation.
Release Criteria Decision Tree
The following decision tree provides a structured approach for determining whether an unresolved anomaly can be released or must be fixed before submission.
Step 1: Does the anomaly have a CVSS base score of 7.0 or higher (High or Critical)?
- YES: Fix required before release. Do not include in the unresolved anomalies table; resolve the anomaly and verify the fix through testing.
- NO: Proceed to Step 2.
Step 2: Can exploitation of the anomaly cause direct patient harm as assessed in the clinical impact analysis?
- YES: Fix required before release, OR document compensating controls AND obtain clinical review sign-off confirming that residual risk is acceptable. Include in the unresolved anomalies table with full documentation.
- NO: Proceed to Step 3.
Step 3: Is the anomaly exploitable over the network (remote attack vector)?
- YES: Document compensating controls in the table. Include the anomaly in the Cybersecurity Management Plan for postmarket monitoring. Ensure compensating controls are verified in penetration test results.
- NO: Proceed to Step 4.
Step 4: Is the anomaly listed in CISA's Known Exploited Vulnerabilities (KEV) Catalog?
- YES: Fix required before release, OR provide documented justification with a committed timeline for resolution and compensating controls that address active exploitation risk.
- NO: Proceed to Step 5.
Step 5: Is the residual risk acceptable per the risk management file and the cybersecurity risk assessment?
- YES: Release with documented justification in the unresolved anomalies table. Ensure the anomaly is included in the postmarket monitoring plan.
- NO: Fix required before release.
Common FDA Reviewer Objections and Remediation
| Reviewer Objection | Root Cause | How to Remediate |
|---|---|---|
| "Unresolved findings without documented mitigation" | Anomalies listed with descriptions and scores but no compensating controls or acceptance criteria | Add compensating controls with technical detail, or provide explicit risk acceptance with clinical justification |
| "CVSS score appears inconsistent with described vulnerability" | Generic CVSS scores copied from NVD without considering device-specific environmental factors | Recalculate CVSS with device-specific environmental metrics using the FDA MDDT-qualified supplemental rubric; document scoring rationale |
| "No clinical impact assessment provided" | Cybersecurity anomalies assessed only for technical impact, not for patient safety consequences | Add a clinical impact column with assessment from clinical engineering or a qualified clinical reviewer; reference the Clinical Impact Matrix above |
| "Compensating controls not described in sufficient detail" | Controls listed by name only (e.g., "network segmentation") without configuration details or evidence of effectiveness | Document each control with configuration specifics, deployment requirements, and verification evidence (test results, architecture diagrams) |
| "VEX status not provided for SBOM-listed vulnerabilities" | SBOM submitted with associated CVEs but no VEX document explaining which vulnerabilities affect the device | Generate a VEX document per CISA minimum requirements; assign status and justification for every CVE associated with SBOM components |
| "No linkage between anomalies and SBOM components" | Unresolved anomalies described in general terms without connecting them to specific software components | Add SBOM component references (package URL or BOM-ref) to each anomaly entry; ensure traceability from anomaly to component to CVE |
| "Labeling does not address residual cybersecurity risks" | Anomalies with user-facing compensating controls (network requirements, access restrictions) not reflected in IFU | Conduct a labeling impact assessment for each anomaly; update IFU or operator manual with deployment requirements and user-facing security instructions |
| "Acceptance criteria for residual risk not defined" | Anomalies accepted as residual risk without specifying what threshold constitutes acceptable risk | Document quantitative or qualitative acceptance criteria in the risk management file; reference the acceptance criteria in the anomaly table release decision |
| "Postmarket monitoring plan does not address unresolved anomalies" | Anomalies documented for premarket but not carried forward to the postmarket cybersecurity management plan | Ensure each unresolved anomaly with a remote attack vector or medium+ CVSS score is included in the Cybersecurity Management Plan with specific monitoring actions |
| "Exploitability assessment based on outdated threat intelligence" | VEX justifications or exploitability statements referencing threat data older than 90 days | Update exploitability assessments with current threat intelligence; include assessment date and source in the anomaly table |
File and Document Cross-Reference
The unresolved anomalies table does not exist in isolation. It connects to multiple documents in the premarket submission. The following table clarifies ownership and cross-references.
| Document | Owner | Reviewer | Approver | Where the Anomaly Table Is Referenced |
|---|---|---|---|---|
| Unresolved Anomalies Table | Software Engineering Lead | Cybersecurity Engineer, Clinical Engineer | Regulatory Affairs, Release Board | Standalone document; referenced in Security Risk Management Report and Design History File |
| SBOM | Build/Release Engineer | Cybersecurity Engineer | Software Engineering Lead | Anomaly table links to SBOM via component references; SBOM vulnerability scan output feeds anomaly discovery |
| VEX Document | Cybersecurity Engineer | Software Engineering Lead | Regulatory Affairs | Anomaly table consumes VEX status for each CVE; VEX reduces scope of anomalies requiring full documentation |
| Security Risk Management Report | Cybersecurity Engineer | Clinical Engineer, Systems Engineer | Regulatory Affairs | Anomaly table is an input to the risk report; residual risks from the table are assessed in the report |
| Threat Model | Systems Security Architect | Cybersecurity Engineer, Software Engineering Lead | Regulatory Affairs | Threat model identifies attack surfaces that inform exploitability assessments in the anomaly table |
| Penetration Test Report | Security Testing Lead (internal or third party) | Cybersecurity Engineer | Software Engineering Lead | Pen test findings feed anomaly entries; compensating controls must be validated in pen test scope |
| Design History File | Systems Engineer | Regulatory Affairs | Program Manager | Anomaly table is a controlled document within the DHF; design traceability includes anomaly resolution tracking |
| Risk Management File | Risk Management Engineer | Clinical Engineer, Cybersecurity Engineer | Regulatory Affairs | Cybersecurity residual risks from the anomaly table are documented in the risk management file per ISO 14971 and IEC 62304 |
| IFU/Labeling | Technical Writer | Clinical Engineer, Regulatory Affairs | Regulatory Affairs, Legal | Anomalies requiring user awareness drive labeling updates per the labeling impact assessment |
| Cybersecurity Management Plan | Cybersecurity Engineer | Regulatory Affairs, Quality Assurance | Executive Management | Unresolved anomalies with postmarket implications are carried into the management plan for ongoing monitoring |
Pre-Submission Validation Checklist
Use this checklist before submitting the premarket package. Each item should be verified and documented.
- Every known unresolved cybersecurity anomaly is listed in the table with a unique identifier
- Each anomaly has a CVSS base score with the full vector string documented
- CVSS environmental score reflects device-specific deployment context
- CVSS scoring rationale is documented (not just the numeric score)
- Exploitability assessment considers the device's specific deployment environment and threat landscape
- Exploitability assessment references current (within 90 days) threat intelligence sources
- Clinical impact assessment is documented for each anomaly with more than "No impact" rating
- Clinical impact assessment is reviewed and signed off by clinical engineering or a qualified clinical reviewer
- Compensating controls are described with sufficient technical detail for independent verification
- Each compensating control maps to a CVSS environmental metric modification
- Each anomaly links to a specific SBOM component via package URL or BOM-ref
- VEX status is assigned for every CVE associated with every SBOM component
- VEX justification codes are provided for all "Not Affected" vulnerabilities
- Anomalies appearing in CISA KEV Catalog are explicitly flagged with documented justification
- Labeling has been reviewed for anomalies requiring user-facing security information
- Risk management file has been updated with cybersecurity residual risks from the anomaly table
- Release decision is documented for each anomaly with reference to risk acceptance criteria
- Unresolved anomalies with remote attack vectors are included in the Cybersecurity Management Plan
- The anomaly table is consistent with the penetration test report findings
- The anomaly table is consistent with the threat model attack surface analysis
- Document control metadata (version, date, author, approver) is complete
- All cross-references to SBOM, VEX, risk file, and DHF entries are verified and current
Common Failure Modes
Listing zero anomalies. A complex software system with zero unresolved anomalies signals to FDA that the analysis may be incomplete. The guidance expects manufacturers to assess unresolved anomalies, not necessarily to have zero of them. A well-documented table with three to five low-risk anomalies and thorough justification is more credible than an empty table on a 500,000-line codebase. If the table is genuinely empty, include a statement describing the process used to confirm completeness.
Treating cybersecurity anomalies the same as ISO 14971 safety hazards. IEC 62304 software anomaly tracking and ISO 14971 hazard analysis serve different purposes. A software defect that has no safety consequence (e.g., a logging format vulnerability) may have a significant cybersecurity consequence. The cybersecurity unresolved anomalies table must assess each anomaly through an exploitability and attack-surface lens, not solely a patient-harm probability lens.
Using generic CVSS scores without environmental context. Copying the NVD base score for a CVE without calculating device-specific environmental metrics is a common deficiency. FDA reviewers expect to see Modified Attack Vector, Modified Attack Complexity, and other environmental metrics that reflect how the device is actually deployed. The MDDT-qualified supplemental rubric provides the framework for this.
Omitting VEX status for known vulnerabilities. Submitting an SBOM that identifies 30 CVEs without a VEX document forces the reviewer to independently assess all 30. VEX is the mechanism by which the manufacturer communicates which vulnerabilities are actually relevant to the device. Without it, reviewers default to the most conservative interpretation.
Failing to link anomalies to SBOM components. An anomaly described as "weakness in communication protocol" without identifying the specific library, version, and SBOM reference is not traceable. Reviewers cannot verify the assessment without knowing exactly which component is affected and which version is in use.
Providing too much detail (raw problem reports) vs. too little. The unresolved anomalies table is an assessed summary, not a dump of raw defect tracker output. Each entry should represent a security-assessed anomaly with scoring, impact analysis, and documented disposition. Including 200 entries with one-line descriptions creates noise; including 3 entries with thorough analysis is defensible.
How to Remediate a Deficient Submission
When FDA issues an Additional Information (AI) letter citing deficiencies in the unresolved anomalies documentation, follow this structured remediation process:
Step 1: Map each deficiency to a specific table row or structural gap. AI letters typically reference deficiencies by guidance section. Map the deficiency language to the specific anomaly entries or missing elements in your table.
Step 2: Update CVSS scoring with device-specific environmental metrics. If the reviewer flagged inconsistent scores, recalculate using the MDDT-qualified supplemental rubric and document the full vector string and scoring rationale for each affected anomaly.
Step 3: Add or strengthen clinical impact assessments. If clinical impact was missing or insufficient, engage clinical engineering to provide documented assessments that go beyond generic statements. Reference the Clinical Impact Matrix and include specific scenarios.
Step 4: Document compensating controls with technical specificity. If controls were flagged as insufficiently described, add configuration details, deployment requirements, architecture diagrams, and test evidence. Each control should map to a specific CVSS environmental metric modification.
Step 5: Update the VEX document. Ensure every CVE in the SBOM has a VEX status and that "Not Affected" entries include valid justification codes per CISA requirements.
Step 6: Update the risk management file. Add or update cybersecurity residual risk entries that correspond to the unresolved anomalies. Ensure acceptance criteria are documented and that the release decision references these criteria.
Step 7: Update labeling if required. Review the labeling impact assessment for each anomaly. If user-facing compensating controls exist, ensure the IFU includes appropriate deployment instructions and cybersecurity considerations.
Step 8: Update the Cybersecurity Management Plan. Ensure all unresolved anomalies with postmarket monitoring implications are carried forward with specific monitoring actions, thresholds, and response procedures.
Step 9: Verify cross-document consistency. Confirm that the anomaly table, SBOM, VEX, risk management file, threat model, penetration test report, and labeling all tell a consistent story. Inconsistencies between documents are a common source of follow-up questions.
Step 10: Resubmit with a deficiency response matrix. Include a response matrix that maps each AI letter deficiency to the specific remediation action and the document page or section where the remediation can be found.