Generated from the official FedRAMP/docs GitHub repo. Source path: FRMR.documentation.json on main at blob 5c6bfee74029. FRMR version: 0.9.43-beta · upstream last_updated: 2026-04-08. The official FedRAMP/rules repo exists, but grclanker still treats FedRAMP/docs as the active source until structured rules land there.

Vulnerability Detection and Response

Short name: VDR · Process ID: VDR · Web slug: vulnerability-detection-and-response

Applies to: both

Official page: https://fedramp.gov/docs/20x/vulnerability-detection-and-response

Effective Status

• 20x: required · Phase 2 Pilot
• Rev5: optional · Open Beta
• Shared requirements: 39

Requirements and Recommendations

BOTH

VDR-AGM-DRE (formerly FRR-VDR-AG-03) SHOULD NOT — Do Not Request Extra Info

Agencies SHOULD NOT request additional information from cloud service providers that is not required by this FedRAMP process UNLESS the head of the agency or an authorized delegate makes a determination that there is a demonstrable need for such.

Terms: Agency

Affects: Agencies

Note: This is related to the Presumption of Adequacy directed by 44 USC § 3613 (e).

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-AGM-MAP (formerly FRR-VDR-AG-02) SHOULD — Maintain Agency POA&M

Agencies SHOULD use vulnerability information reported by the Provider to maintain Plans of Action & Milestones for agency security programs when relevant according to agency security policies (such as if the agency takes action to mitigate the risk of exploitation or authorized the continued use of a cloud service with accepted vulnerabilities that put agency information systems at risk).

Terms: Accepted Vulnerability, Agency, Vulnerability

Affects: Agencies

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-AGM-NFR (formerly FRR-VDR-AG-04) MUST — Notify FedRAMP

Agencies MUST notify FedRAMP after requesting any additional vulnerability information or materials from a cloud service provider beyond those FedRAMP requires by sending a notification to info@fedramp.gov.

Terms: Agency, Vulnerability

Affects: Agencies

Note: This is an OMB policy; agencies are required to notify FedRAMP in OMB Memorandum M-24-15 section IV (a).

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-AGM-RVR (formerly FRR-VDR-AG-01) SHOULD — Review Vulnerability Reports

Agencies SHOULD review the information provided in vulnerability reports at appropriate and reasonable intervals commensurate with the expectations and risk posture indicated by their Authorization to Operate, and SHOULD use automated processing and filtering of machine readable information from cloud service providers.

Terms: Accepted Vulnerability, Agency, Potential Adverse Impact (of vulnerability exploitation), Vulnerability

Affects: Agencies

Note: FedRAMP recommends that agencies only review overdue and accepted vulnerabilities with a potential adverse impact of N3 or higher unless the cloud service provider recommends mitigations or the service is included in a higher risk federal information system. Furthermore, accepted vulnerabilities generally only need to be reviewed when they are added or during an updated risk assessment due to changes in the agency’s use or authorization.

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-BST-ADT (formerly FRR-VDR-AY-03) SHOULD — Automate Detection

Providers SHOULD use automated services to improve and streamline vulnerability detection and response.

Terms: Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-BST-AKE (formerly FRR-VDR-AY-06) SHOULD NOT — Avoid KEVs

Providers SHOULD NOT deploy or otherwise activate new machine-based information resources with Known Exploited Vulnerabilities.

Terms: Information Resource, Known Exploited Vulnerability (KEV), Machine-Based (information resources), Vulnerability

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-BST-DAC (formerly FRR-VDR-AY-04) SHOULD — Detect After Changes

Providers SHOULD automatically perform vulnerability detection on representative samples of new or significantly changed information resources.

Terms: Information Resource, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-BST-DFR (formerly FRR-VDR-AY-02) SHOULD — Design For Resilience

Providers SHOULD make design and architecture decisions for their cloud service offering that mitigate the risk of vulnerabilities by default AND decrease the risk and complexity of vulnerability detection and response.

Terms: Cloud Service Offering, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-BST-MSP (formerly FRR-VDR-AY-05) SHOULD NOT — Maintain Security

Providers SHOULD NOT weaken the security of information resources to facilitate vulnerability scanning, detection, or assessment activities.

Terms: Information Resource, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-BST-SIR (formerly FRR-VDR-04) MAY — Sampling

Providers MAY sample effectively identical information resources, especially machine-based information resources, when performing vulnerability detection UNLESS doing so would decrease the efficiency or effectiveness of vulnerability detection.

Terms: Information Resource, Machine-Based (information resources), Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-CSO-DET (formerly FRR-VDR-01) MUST — Vulnerability Detection

Providers MUST systematically, persistently, and promptly discover and identify vulnerabilities within their cloud service offering using appropriate techniques such as assessment, scanning, threat intelligence, vulnerability disclosure mechanisms, bug bounties, supply chain monitoring, and other relevant capabilities; this process is called vulnerability detection.

Terms: Cloud Service Offering, Persistently, Promptly, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-CSO-DOC (formerly FRR-VDR-11) MUST — Documentation for Recommendations

Providers MUST document the reason and resulting implications for their customers when choosing not to meet FedRAMP recommendations in this process; this documentation MUST be included in the authorization data for the cloud service offering.

Terms: Authorization data, Cloud Service Offering

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-CSO-RES (formerly FRR-VDR-02) MUST — Vulnerability Response

Providers MUST systematically, persistently, and promptly track, evaluate, monitor, mitigate, remediate, assess exploitation of, report, and otherwise manage all detected vulnerabilities within their cloud service offering; this process is called vulnerability response.

Terms: Cloud Service Offering, Persistently, Promptly, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Note: If it is not possible to fully mitigate or remediate detected vulnerabilities, providers SHOULD instead partially mitigate vulnerabilities promptly, progressively, and persistently.

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-EVA-EFA (formerly FRR-VDR-10) SHOULD — Evaluation Factors

Providers SHOULD consider at least the following factors when considering the context of the cloud service offering to evaluate detected vulnerabilities:

Checklist items:

• Criticality: How important are the systems or information that might be impacted by the vulnerability?
• Reachability: How might a threat actor reach the vulnerability and how likely is that?
• Exploitability: How easy is it for a threat actor to exploit the vulnerability and how likely is that?
• Detectability: How easy is it for a threat actor to become aware of the vulnerability and how likely is that?
• Prevalence: How much of the cloud service offering is affected by the vulnerability?
• Privilege: How much privileged authority or access is granted or can be gained from exploiting the vulnerability?
• Proximate Vulnerabilities: How does this vulnerability interact with previously detected vulnerabilities, especially partially or fully mitigated vulnerabilities?
• Known Threats: How might already known threats leverage the vulnerability and how likely is that?

Terms: Cloud Service Offering, Fully Mitigated Vulnerability, Likely, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-EVA-EFP (formerly FRR-VDR-06) SHOULD — Evaluate False Positives

Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are false positive vulnerabilities.

Terms: Cloud Service Offering, False Positive Vulnerability, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-EVA-EIR (formerly FRR-VDR-08) MUST — Evaluate Internet-Reachability

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are internet-reachable vulnerabilities.

Terms: Cloud Service Offering, Internet-Reachable Vulnerability (IRV), Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-EVA-ELX (formerly FRR-VDR-07) MUST — Evaluate Exploitability

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to determine if they are likely exploitable vulnerabilities.

Terms: Cloud Service Offering, Likely, Likely Exploitable Vulnerability (LEV), Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Updated note from technical assistance; removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-EVA-EPA (formerly FRR-VDR-09) MUST — Estimate Potential Adverse Impact

Providers MUST evaluate detected vulnerabilities, considering the context of the cloud service offering, to estimate the potential adverse impact of exploitation on government customers AND assign one of the following potential adverse impact ratings:

Terms: Agency, Catastrophic Adverse Effect, Cloud Service Offering, Limited Adverse Effect, Negligible Adverse Effect, Potential Adverse Impact (of vulnerability exploitation), Serious Adverse Effect, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-EVA-GRV (formerly FRR-VDR-05) SHOULD — Group Vulnerabilities

Providers SHOULD evaluate detected vulnerabilities, considering the context of the cloud service offering, to identify logical groupings of affected information resources that may improve the efficiency and effectiveness of vulnerability response by consolidating further activity; requirements and recommendations in this process are then applied to these consolidated groupings of vulnerabilities instead of each individual detected instance.

Terms: Cloud Service Offering, Information Resource, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-FRP-ADV (formerly FRR-VDR-EX-02) MAY — Sensitive Details

FedRAMP MAY required providers to share additional information or details about vulnerabilities, including sensitive information that would likely lead to exploitation, as part of review, response or investigation by necessary parties.

Terms: Likely, Vulnerability, Vulnerability Response

Affects: FedRAMP

Recent update: 2026-02-04 — Changed to FedRAMP responsibility; removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-FRP-ARP (formerly FRR-VDR-EX-01) MAY — Additional Requirements

FedRAMP MAY require providers to share additional vulnerability information, alternative reports, or to report at an alternative frequency as a condition of a FedRAMP Corrective Action Plan or other agreements with federal agencies.

Terms: Agency, Vulnerability

Affects: FedRAMP

Recent update: 2026-02-04 — Changed to FedRAMP responsibility; removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-RPT-AVI (formerly FRR-VDR-RP-06) MUST — Accepted Vulnerability Info

Providers MUST include the following information on accepted vulnerabilities when reporting on vulnerability detection and response activity:

Checklist items:

• Provider’s internally assigned tracking identifier
• Time and source of the detection
• Time of completed evaluation
• Is it an internet-reachable vulnerability or not?
• Is it a likely exploitable vulnerability or not?
• Currently estimated potential adverse impact of exploitation
• Explanation of why this is an accepted vulnerability
• Any supplementary information the provider determines will responsibly help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the accepted vulnerability

Terms: Accepted Vulnerability, Agency, Cloud Service Offering, Federal Customer Data, Internet-Reachable Vulnerability (IRV), Likely, Likely Exploitable Vulnerability (LEV), Potential Adverse Impact (of vulnerability exploitation), Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-RPT-HLO (formerly FRR-VDR-RP-02) SHOULD — High-Level Overviews

Providers SHOULD include high-level overviews of ALL vulnerability detection and response activities conducted during this period for the cloud service offering; this includes vulnerability disclosure programs, bug bounty programs, penetration testing, assessments, etc.

Terms: Cloud Service Offering, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-RPT-NID (formerly FRR-VDR-RP-03) MUST NOT — Responsible Disclosure

Providers MUST NOT irresponsibly disclose specific sensitive information about vulnerabilities that would likely lead to exploitation, but MUST disclose sufficient information for informed risk-based decision-making to all necessary parties.

Terms: All Necessary Parties, Likely, Vulnerability

Affects: Providers

Note: This requirement will be superseded in the event of formal action related to an investigation or corrective action plan.

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-RPT-PER (formerly FRR-VDR-RP-01) MUST — Persistent Reporting

Providers MUST report vulnerability detection and response activity to all necessary parties persistently, summarizing ALL activity since the previous report; these reports are authorization data and are subject to the FedRAMP Authorization Data Sharing (ADS) process.

Terms: All Necessary Parties, Authorization data, Persistently, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-RPT-RPD (formerly FRR-VDR-RP-04) MAY — Responsible Public Disclosure

Providers MAY responsibly disclose vulnerabilities publicly or with other parties if the provider determines doing so will NOT likely lead to exploitation.

Terms: Likely, Vulnerability

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-RPT-VDT (formerly FRR-VDR-RP-05) MUST — Vulnerability Details

Providers MUST include the following information (if applicable) on detected vulnerabilities when reporting on vulnerability detection and response activity, UNLESS it is an accepted vulnerability:

Checklist items:

• Provider’s internally assigned tracking identifier
• Time and source of the detection
• Time of completed evaluation
• Is it an internet-reachable vulnerability or not?
• Is it a likely exploitable vulnerability or not?
• Historically and currently estimated potential adverse impact of exploitation
• Time and level of each completed and evaluated reduction in potential adverse impact
• Estimated time and target level of next reduction in potential adverse impact
• Is it currently or is it likely to become an overdue vulnerability or not? If so, explain.
• Any supplementary information the provider responsibly determines will help federal agencies assess or mitigate the risk to their federal customer data within the cloud service offering resulting from the vulnerability
• Final disposition of the vulnerability

Terms: Accepted Vulnerability, Agency, Cloud Service Offering, Federal Customer Data, Internet-Reachable Vulnerability (IRV), Likely, Likely Exploitable Vulnerability (LEV), Overdue Vulnerability, Potential Adverse Impact (of vulnerability exploitation), Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-TFR-EVU — Evaluate Vulnerabilities Quickly

Terms: Vulnerability, Vulnerability Detection

Affects: Providers

VDR-TFR-IRI — Internet-Reachable Incidents

Terms: Incident, Likely, Likely Exploitable Vulnerability (LEV), Potential Adverse Impact (of vulnerability exploitation), Vulnerability

Affects: Providers

VDR-TFR-KEV (formerly FRR-VDR-TF-02) SHOULD — Remediate KEVs

Providers SHOULD remediate Known Exploited Vulnerabilities according to the due dates in the CISA Known Exploited Vulnerabilities Catalog (even if the vulnerability has been fully mitigated) as required by CISA Binding Operational Directive (BOD) 22-01 or any successor guidance from CISA.

Terms: Known Exploited Vulnerability (KEV), Vulnerability

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-TFR-MAV (formerly FRR-VDR-TF-03) MUST — Mark Accepted Vulnerabilities

Providers MUST categorize any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation as an accepted vulnerability.

Terms: Accepted Vulnerability, Vulnerability

Affects: Providers

Structured timeframe: 192 days

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-TFR-MHR (formerly FRR-VDR-TF-01) MUST — Monthly Activity Report

Providers MUST report vulnerability detection and response activity to all necessary parties in a consistent format that is human readable at least monthly.

Terms: All Necessary Parties, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

Structured timeframe: 1 month

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-TFR-MRH — Historical Activity

Terms: All Necessary Parties, Machine-Readable, Persistently, Vulnerability, Vulnerability Detection, Vulnerability Response

Affects: Providers

VDR-TFR-NRI — Non-Internet-Reachable Incidents

Terms: Incident, Likely, Likely Exploitable Vulnerability (LEV), Potential Adverse Impact (of vulnerability exploitation), Vulnerability

Affects: Providers

VDR-TFR-PCD (formerly FRR-VDR-TF-LO-04) — Persistent Complete Detection

Terms: Drift, Information Resource, Likely, Persistently, Vulnerability, Vulnerability Detection

Affects: Providers

Recent update: 2026-02-04 — Removed italics and changed the ID as part of new standardization in v0.9.0-beta; no material changes.

VDR-TFR-PDD — Persistent Drift Detection

Terms: Drift, Information Resource, Likely, Persistently, Vulnerability, Vulnerability Detection

Affects: Providers

VDR-TFR-PSD — Persistent Sample Detection

Terms: Information Resource, Machine-Based (information resources), Persistently, Vulnerability, Vulnerability Detection

Affects: Providers

VDR-TFR-PVR — Mitigation and Remediation Expectations

Terms: Likely, Potential Adverse Impact (of vulnerability exploitation), Vulnerability

Affects: Providers

VDR-TFR-RMN SHOULD — Remaining Vulnerabilities

Providers SHOULD mitigate or remediate remaining vulnerabilities during routine operations as determined necessary by the provider.

Terms: Vulnerability

Affects: Providers