FedRAMP 20x Accepted Vulnerabilities: What to Record and Report

FedRAMP 20x accepted vulnerability records should explain the weakness that remains and why the provider has classified it as accepted. For Class B and C teams, accepted is a defined reporting category; it is not another word for remediated or an indication that the agency has made its own risk decision.

Build the record while the decision is being made. That makes the reason, evaluation and supporting evidence easier to preserve than reconstructing them after a reporting deadline.

Classify acceptance using intent and timing

FRD-ACV defines an accepted vulnerability as one the provider does not intend to fully mitigate or remediate, or one that has not or will not reach that state within the maximum overdue period referenced in the definition. FRD-ODV separately defines an overdue vulnerability as one the provider intends to fully mitigate or remediate but has not or will not do so within FedRAMP's recommended or required timeframes. FedRAMP Definitions

VER-TFR-MAV requires providers in the Class B and C scope discussed here to categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as accepted. Preserve the forward-looking wording: a forecast that treatment will not finish within that period is relevant, not just the passage of day 192. FedRAMP Vulnerability Evaluation and Reporting

Read these provisions together. If the provider already does not intend full mitigation or remediation, the definition itself is relevant to classification. Treat 192 days as the stated rule threshold, not a reason to postpone recording a known decision.

Include the accepted-vulnerability reporting information

VER-RPT-AVI requires the following information about accepted vulnerabilities when reporting vulnerability detection and response activity. The list below paraphrases the rule; use the linked official rule and schema for implementation. FedRAMP VER-RPT-AVI

• The provider's internal tracking identifier.
• Detection time and source, plus the time evaluation was completed.
• Whether the vulnerability is internet-reachable and whether it is likely exploitable.
• The current estimated Potential Agency Impact N-rating.
• An explanation of why the vulnerability is accepted.
• Supplementary information the provider determines will responsibly help agencies assess or mitigate the resulting risk to their federal customer data in the offering.

Write the acceptance explanation so a reader can distinguish a deliberate treatment decision from a timing forecast. As an editorial practice, link it to the engineering rationale and evidence rather than filling the field with a generic accepted label.

Preserve the difference between treatment and agency risk

FedRAMP defines remediation as a vulnerability being eliminated or neutralized and no longer detected. A provider's accepted classification describes a different condition. The mitigation and remediation guide explains the treatment distinction. FedRAMP Definitions

Separately, official agency-use guidance says the agency authorizing official accepts risk for the agency's specific use of the service. Do not present a provider's accepted-vulnerability label as that agency decision. FedRAMP agency-use guidance

The reporting rule above explicitly addresses accepted vulnerabilities. Keep the record available to the reporting process rather than using acceptance as an automatic removal condition.

Review the record when its basis changes

A practical internal review can check the treatment intent, forecast, present exposure, current impact estimate and explanatory evidence. Assign an owner for changes that affect the rationale. These are editorial operating suggestions, not a new official approval form.

The VER page lists optional adoption on July 4, 2026, initial and ongoing certification adoption on December 7, 2026, and a grace-period end of March 7, 2027. Keep applicability and the version of the rule alongside your reporting implementation.

Use the evidence readiness checklist to make the decision and its support retrievable. The record should tell a reviewer what remains, why it is accepted and what information supports that description.