Updated July 2026 to reflect the FedRAMP Consolidated Rules for 2026, released June 25, 2026.

The core concept

Vulnerability management is a pipeline: scan, enrich, evaluate, prioritize, remediate, verify, report. Every finding moves through it with an owner and a deadline. Frameworks differ on scanning frequency, severity evaluation, remediation timelines, and reporting format. The pipeline itself is the same.

Scanning is the easy part. Running a scanner and getting results is table stakes. The hard part is everything after: normalizing results from multiple scanners into one schema, determining which findings are new versus remediated versus reopened across scan cycles, enriching findings with threat intelligence, assigning owners and SLAs, tracking remediation, handling findings that cannot be fixed on the standard timeline, and reporting it all in the format each framework expects.

That pipeline is what breaks when tools are disconnected. And it is what every framework tests.

graph LR
    S[Scan Results] --> E[Enrich and Evaluate]
    E --> ISS[Issue Ticket]
    ISS -->|remediate| CL[Closed]
    ISS -->|cannot fix| DEV[Deviation]
    DEV --> ACC[Accepted Vulnerability]

    style S fill:#2b5797,stroke:#5b9bd5,color:#fff
    style E fill:#5c4a1a,stroke:#ffc857,color:#fff
    style ISS fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style CL fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style DEV fill:#4a1a5c,stroke:#c77dff,color:#fff
    style ACC fill:#5c1a3d,stroke:#ff6b9d,color:#fff

What CMMC requires

CMMC does not set a specific scanning frequency. It does require that you scan, remediate, and prove both. The evidence has to show a pattern, not a one-time event.

The relevant practices:

• RA.L2-3.11.2 (Level 2): Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified. 5-point, not POA&M-eligible. This is the scanning practice. “Periodically” means you define a schedule and stick to it. “When new vulnerabilities are identified” means you have a process for responding to newly disclosed CVEs outside your routine schedule.
• SI.L1-3.14.1 (Level 1): Identify, report, and correct information system flaws in a timely manner. 5-point, not POA&M-eligible. This is the remediation practice, and it comes from Level 1. “Timely” is not defined by CMMC with specific day counts the way FedRAMP does. But assessors expect to see severity-driven timelines and evidence that they are met.
• RA.L2-3.11.3 (Level 2): Remediate vulnerabilities in accordance with risk assessments. 1-point, POA&M-eligible. This is the only vulnerability management practice that can be deferred via POA&M. It requires risk-based prioritization, meaning you make remediation decisions based on the risk each vulnerability poses in your specific environment.

Supporting practices:

• SI.L2-3.14.3: Monitor security alerts, advisories, and directives and take action.
• RA.L2-3.11.1: Periodically assess the risk to organizational operations, organizational assets, and individuals.

What a C3PAO assessor looks for:

• A scan schedule and scan results that match it. If the policy says monthly, the assessor expects 12 months of monthly scan reports.
• Remediation timelines tied to severity, and evidence of follow-through. Not just “we plan to fix criticals in 30 days” but actual closure data.
• A process for handling newly disclosed CVEs outside the routine schedule.
• Evidence you act on security alerts and advisories, not just receive them.
• Scan coverage that matches the asset inventory. If the inventory lists 50 servers and the scan report covers 43, the assessor will ask about the other 7.

The common gap: you scan, but you cannot show timely remediation or consistent triage. Scan results pile up in a dashboard without tracking. Findings are not assigned to individuals. Remediation deadlines are not tied to severity. There is no evidence trail from “finding discovered” to “finding remediated” or “finding accepted as a risk.”

The scoring matters. RA.L2-3.11.2 (scanning) and SI.L1-3.14.1 (remediation) are both 5-point and not POA&M-eligible. If you cannot show timely scanning and remediation, those practices do not score, and you cannot defer them. At that point these are not findings on a POA&M. They are pass-fail gates.

What FedRAMP Rev5 requires

FedRAMP is prescriptive about vulnerability management. That has not changed. What changed is where the prescriptions live. The Consolidated Rules for 2026 (released June 25, 2026, effective July 4, 2026) apply the same two vulnerability standards to Rev5 and 20x alike: VDR (Vulnerability Detection and Response) and VER (Vulnerability Evaluation and Reporting). Both are mandated by CISA BOD 26-04, and providers must obtain them by December 7, 2026.

The Rev5 controls still anchor the baseline:

• RA-5 (Vulnerability Monitoring and Scanning)
• SI-2 (Flaw Remediation)

But the FedRAMP-defined parameters that used to hang off them are history: monthly OS, web application, and database scanning, remediation in 30 days (Critical/High), 90 days (Moderate), and 180 days (Low), patches within 30 days of release. FedRAMP removed most FedRAMP-defined control parameters, and the VDR and VER rules now supply the numbers:

• Detection cadence. VDR-TFR-MVF: Rev5 providers verify and validate the status of machine-based resources at least once every month (SHOULD for Class B, MUST for Classes C and D). VDR-TFR-NMV: non-machine resources at least once every 3 months (MUST, all classes). And “vulnerability detection” is broader than scanning: VDR-CSO-DET is a MUST that covers assessment, threat intelligence, vulnerability disclosure, bug bounties, penetration testing, and supply chain monitoring.
• Remediation timeframes. Class-and-PAIN-based under VDR-TFR-PVR, the same tables 20x uses. Covered in the next section.
• Deviations. False positive, operational requirement, and risk adjustment deviation requests to FedRAMP no longer exist. False positives are a provider determination (VER-EVA-EFP). Everything else either gets mitigated or remediated on the clock, or becomes an accepted vulnerability at 192 days (VER-TFR-MAV).
• POA&Ms. Eliminated as a FedRAMP artifact. The accepted vulnerability list and the VER reports replace them.

What independent assessors look for:

• Detection coverage that matches the asset inventory and the assessment scope. Every scannable asset in the inventory should appear in detection results.
• Evidence that evaluation and mitigation happen within the class-based timeframes, tracked from the evaluation date.
• A process for Known Exploited Vulnerabilities per the due dates in the CISA KEV Catalog (VDR-TFR-KEV, per CISA BOD 26-04), not only the routine cadence.
• Monthly human-readable activity reports (VER-TFR-MHR) that reconcile against detection results.

Common gap: scanning covers servers but misses applications, containers, or cloud configurations. Remediation timeframes exist in the policy but are not tracked as actual deadlines with evidence. Detection coverage does not match the asset inventory, and nobody reconciles the two.

If your program is still tuned to 30/90/180, you are tracking against SLAs that no longer exist. The new timeframes are tighter at the top and looser at the bottom, and they run from the evaluation date, not the discovery date. An independent assessor will test against the new clocks.

What FedRAMP 20x requires

The pilot-era VDR standard split in two when the Consolidated Rules landed. VDR (Vulnerability Detection and Response) keeps detection cadences and mitigation and remediation timeframes. VER (Vulnerability Evaluation and Reporting) takes contextual evaluation and reporting. Both apply to 20x and Rev5, both are mandated by CISA BOD 26-04, and both must be obtained by December 7, 2026 (grace ends March 7, 2027). There is no KSI for vulnerability management; these requirements are enforced directly as FedRAMP rules.

VER evaluates every finding on three dimensions, and all three are MUST requirements:

• Exploitability (VER-EVA-ELX): is this a LEV (Likely Exploitable Vulnerability)? A binary determination, not a score: the vulnerability is not fully mitigated, is reachable by a likely threat actor, and a threat actor who knew about it would likely cause harm.
• Reachability (VER-EVA-EIR): is this an IRV (Internet-Reachable Vulnerability)? Also binary: could a payload originating from the public internet exploit or trigger it?
• Potential Agency Impact (VER-EVA-EPA): assign a PAIN rating (Potential Agency Impact N-rating) from N1 (minimal customer effects) to N5 (a debilitating customer effect on more than one agency).

One more evaluation rule worth quoting: VER-EVA-AIA. Providers MUST assume the exploitation of vulnerabilities can be automated unless they have evidence proving otherwise.

Key MUST requirements:

• VDR-CSO-DET: systematically, persistently, and promptly discover and identify vulnerabilities. Not limited to scanning; an out-of-date control statement in your Security Decision Record is a vulnerability too.
• VDR-CSO-RES: track, evaluate, monitor, mitigate, remediate, and report all detected vulnerabilities.
• VER-TFR-MAV: any vulnerability that is not or will not be fully mitigated or remediated within 192 days of evaluation MUST be categorized as an accepted vulnerability. This is the hard cutoff, and it is what replaced the POA&M. 192 days is not a target. It is a mandatory reclassification point.
• VER-TFR-MHR: human-readable activity reports at least monthly.
• VER-RPT-PER and VER-RPT-VDT: persistent reporting to all necessary parties with detailed per-vulnerability information: detection time and source, evaluation time, LEV and IRV status, historical and current PAIN rating, each completed reduction, and overdue status.
• VER-RPT-AVI: accepted vulnerabilities additionally require an explanation of why the vulnerability is accepted.

Key SHOULD requirements (recommended, not mandatory):

• VDR-TFR-PVR mitigation and remediation timeframes, which vary by Certification Class and PAIN rating. For Class D (the successor to High): PAIN-5 LEV+IRV = 12 hours; PAIN-3 NLEV = 64 days. For Class C (the successor to Moderate): PAIN-5 LEV+IRV = 2 days; PAIN-3 NLEV = 128 days. For Class B: PAIN-5 LEV+IRV = 4 days. Every class bottoms out at 192 days for PAIN-2 NLEV findings. These are targets, not mandates, but your independent assessor will ask about them.
• VER-TFR-EVU evaluation timeframes: evaluate ALL vulnerabilities within 14 days (Class A), 7 days (Class B), 5 days (Class C), or 2 days (Class D) of detection. This is how fast you need to evaluate a new finding, not fix it. And it matters twice, because the PVR clocks and the 192-day clock both start at evaluation.
• VDR-TFR-KEV: remediate Known Exploited Vulnerabilities per the due dates in the CISA KEV Catalog, even if fully mitigated, as required by CISA BOD 26-04.
• VDR-CSO-AKE: do not deploy new machine-based resources with Known Exploited Vulnerabilities.
• VER-TFR-IRI: at Classes C and D, treat internet-reachable likely exploitable vulnerabilities with a PAIN rating above N3 as a FedRAMP Reportable Incident until they are partially mitigated to N3 or below. A bad enough vulnerability is an incident.

Cadences scale by class. Machine verification and validation for 20x (VDR-TFR-MVX): at least every 7 days at Class B, every 3 days at Class C, both MUST. Machine-readable historical activity feeds in JSON (VER-TFR-MRH): monthly at Class B, every 14 days at Class C, every 7 days at Class D, all SHOULD.

The distinction between MUST and SHOULD still matters. The 192-day accepted vulnerability rule (VER-TFR-MAV) is mandatory. The PVR remediation timeframes are recommended targets that vary by class. Know the difference.

Common gap on the path to 20x: CVSS-only severity with no LEV, IRV, or PAIN evaluation, no evaluation-date tracking (both the PVR targets and the 192-day cutoff run from evaluation, not discovery), findings data not structured for the VER report fields, and no accepted vulnerability process at all.

The pain we lived

Vulnerability management was the pain that started everything.

We run different combinations of scanners across environments depending on what is deployed: infrastructure scanners, web application scanners, container scanners, database scanners. Each tool produces results in its own format with its own severity scale. A “high” in one scanner is not the same as a “high” in another. A finding identified by CVE in one tool might be identified by a proprietary plugin ID in another.

Step one, every month, was normalizing all of that into a single view. We could not afford a six-figure enterprise vulnerability platform for each client. So we did it by hand: export from each scanner, map to a common severity, deduplicate, and produce one unified findings list. For each environment. Every month.

Then the reconciliation. Compare this month’s results against last month. Which findings are new? Which ones were remediated? Which ones were closed last month but reappeared? This reconciliation is where most programs break. If you cannot reliably determine new versus remediated versus reopened, your tracking data drifts. Closed items reopen without anyone noticing. New items are mixed in with items that have been there for six months. The report stops reflecting reality.

Then the mapping. In that era, every finding that met POA&M criteria had to be tracked as a POA&M entry. In a disconnected toolset, that meant manually creating a POA&M entry for each finding, linking it to the scanner source, assigning an owner, setting an SLA, and tracking it to closure. When a change ticket remediated five findings, someone had to manually update five POA&M entries and link them to the change ticket. The POA&M is gone as a FedRAMP artifact now, but the work it represented is not: something still has to carry the owner, the deadline, and the closure evidence for every finding.

The manual process consumed days every month per environment. Across 15+ environments, it consumed weeks. The error rate was constant. Inconsistencies between the POA&M, the scan report, and the deviation tracker were the norm, not the exception. The root cause was always the same: the finding, the POA&M entry, the change ticket, and the deviation all lived in different places. The data existed. The relationships did not.

How we automate it

Here is how we built the vulnerability management pipeline in Stratus GRC-ITSM. The goal was to eliminate every manual step between “scanner produces results” and “report is delivered.”

1. Scan ingestion. Results from infrastructure, container, application, database, and web tools feed into one data model. Different scanners, different formats, one normalized schema. The platform handles the format translation. No export-and-paste.
2. Automatic enrichment. Every finding is enriched on intake with CISA KEV status, EPSS score, and threat intelligence feeds. No manual CVE lookups. No “let me check if this is on the KEV list.” The enrichment data is there when the finding arrives.
3. Asset context drives the evaluation. Findings are correlated with the live asset inventory. The platform knows which assets are internet-facing, which handle federal data or CUI, and what the blast radius is. That context feeds the three VER determinations: LEV from KEV + EPSS + threat intel, IRV from network exposure, and the PAIN rating (N1 through N5) from asset criticality.
4. One umbrella Issue per CVE, one child per asset. Every distinct CVE or weakness becomes a single umbrella Issue with a child per affected asset. On every scan cycle, findings are compared against prior results: new findings create Issues, remediated findings close them, reopened findings reopen them. No manual reconciliation. Every Issue is also stamped automatically with the FedRAMP controls, KSIs, FedRAMP Rules, and CMMC practices it maps to, scoped to the baselines the system is actually certified against.
5. SLAs per certification regime. Remediation deadlines are set on intake for each regime the system answers to: the class-and-PAIN-based VDR-TFR-PVR targets for FedRAMP, severity-driven timelines for CMMC. Approaching deadlines escalate. Breached SLAs get flagged immediately. The 192-day accepted vulnerability threshold (VER-TFR-MAV) is tracked from the evaluation date. Findings approaching it are surfaced early. When they cross it, the required documentation fires.
6. Deviations stay human, and cascade. False positives, risk acceptances, and operational requirements are structured deviation records parented to the umbrella Issue, with required justification, compensating controls, and evidence. Approval is never automated. Once a deviation is approved, its risk posture cascades down to every Issue it covers automatically, SLA-aware across the remediation regimes. This internal deviation discipline is what feeds the accepted vulnerability reporting FedRAMP now expects.
7. Qualifying vulnerabilities escalate into Incidents. Per VER-TFR-IRI, internet-reachable likely exploitable findings above N3 qualify as FedRAMP Reportable Incidents until partially mitigated to N3 or below. The pipeline escalates qualifying Issues into Incident tickets, where the FedRAMP incident reporting lifecycle takes over.
8. Reports and evidence from live data. The open and closed Issue reports are the vulnerability reporting artifacts. Monthly human-readable activity reports per VER-TFR-MHR, machine-readable vulnerability detail and accepted vulnerability reports in the FedRAMP JSON shapes, and CMMC remediation evidence all generate from the same data model. And remediating an Issue on time is itself evidence: on-time remediation self-generates KSI validation evidence, so working the queue produces the proof.

graph LR
    SCAN[Scan Results] --> ISS[Umbrella Issue per CVE, per-asset children]
    ISS -->|remediated| CLOSED[Closed]
    ISS -->|deviation approved| ACC[Accepted Vulnerability]
    ISS -->|192 days| ACC
    CLOSED --> RPT[Monthly + Machine-Readable Reports]
    ACC --> RPT

    style SCAN fill:#2b5797,stroke:#5b9bd5,color:#fff
    style ISS fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style CLOSED fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style ACC fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style RPT fill:#1a5c3d,stroke:#51cf66,color:#fff

The point: one data model produces CMMC remediation evidence, the monthly FedRAMP activity reports, and the accepted vulnerability list for Rev5 and 20x alike. No tool-to-tool reconciliation. No spreadsheet gymnastics. No separate reporting artifact to assemble. The Issue is the report.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]