The core concept

Not every vulnerability gets fixed on schedule. Deviation management is how you formally document the exceptions: findings that cannot or will not be remediated within the standard timeline, and why.

Three analysis categories, familiar to anyone who has run a vulnerability program:

• Operational Requirement (OR): remediation would break a required function. The vulnerability is real, but fixing it would cause more harm than accepting the risk. Compensating controls mitigate the exposure.
• False Positive (FP): the scanner flagged something that is not actually a vulnerability in your environment. The finding exists in the scan report, but the risk does not apply.
• Risk Adjustment (RA): the actual risk is lower than the scanner severity suggests. The vulnerability exists, but environmental context, such as network segmentation, compensating controls, or low asset criticality, reduces the real-world impact.

Each type has its own evidence requirements, its own approval chain, and its own relationship to the parent finding. The common thread: every deviation links to a parent finding, carries a documented justification, names a responsible approver, and is reviewed on a cadence.

One thing changed in June 2026, and it is worth stating plainly. Under the FedRAMP Consolidated Rules for 2026 (released June 25, 2026, effective July 4, 2026), deviations are no longer something you request from FedRAMP. The provider POA&M as a FedRAMP artifact is eliminated. False positive, operational requirement, and risk adjustment deviation requests are gone with it. The replacement is blunt: any vulnerability not fully mitigated or remediated within 192 days of evaluation MUST be categorized as an accepted vulnerability (VER-TFR-MAV) and reported transparently through machine-readable vulnerability reporting. The internal discipline survives. You still need the FP analysis, the risk acceptance, the compensating controls documentation, and the named approver. That work is what stands behind an honest accepted-vulnerability categorization, and CMMC still requires it outright. What disappeared is the request-and-wait relationship with FedRAMP.

One data model detail matters here. In Stratus GRC-ITSM, all vulnerabilities, misconfigurations, and assessment findings are tracked as Issue Tickets. An Issue Ticket becomes a POA&M entry when “IS POA&M” is set to Yes; the open and closed Issue reports are the POA&M where a framework still uses one, and the same Issue data produces the vulnerability and accepted-vulnerability reports FedRAMP wants now. There is no separate POA&M object. Deviations attach to the Issue Ticket directly. The deviation, the parent finding, and the reporting status are one connected record. With that in mind, the rest of this article covers the framework-specific requirements that determine when and how a deviation gets created, approved, and reported.

What CMMC requires

CMMC assessors expect documented risk acceptance with justification, compensating controls, and approval by the right people. Not every vulnerability in a CUI environment can be fixed immediately. The question is whether you have a formal process for the exceptions. Nothing in the FedRAMP changes touches this; CMMC’s POA&M rules are unchanged.

The relevant practices:

• RA.L2-3.11.1 (Level 2): Periodically assess the risk to organizational operations, organizational assets, and individuals. 3-point, not POA&M-eligible. This is the risk assessment practice. Deviations are a subset of risk assessment: you are making a risk-based decision to accept, adjust, or dismiss a finding.
• CA.L2-3.12.2 (Level 2): Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities. 3-point, not POA&M-eligible. This is the POA&M practice. The POA&M is the artifact that tracks your open findings, milestones, and timelines.
• RA.L2-3.11.3 (Level 2): Remediate vulnerabilities in accordance with risk assessments. 1-point, POA&M-eligible. This is the risk-based remediation practice. It explicitly ties remediation to risk assessment, which is where deviations live.

CMMC POA&M rules: items have to close within 180 days of the assessment finding. Certain 5-point practices cannot use POA&Ms at all. The C3PAO verifies closeout at reassessment.

What a C3PAO assessor looks for:

• An active POA&M with milestones, owners, and realistic timelines
• Risk acceptance with authorizing official signature for every deviation
• Evidence of periodic review showing that deviations are re-evaluated, not filed and forgotten
• Compensating controls documented for operational requirements
• Evidence that supports false positive determinations, not just a note that says “FP”
• Remediation progress, not a static list of items nobody is working

The common gap: deviations tracked informally or not at all. Missing authorizing official sign-off. POA&Ms treated as parking lots for findings nobody is working. Deviations exist as notes in a spreadsheet with no structured review process.

RA.L2-3.11.1 and CA.L2-3.12.2 are both not POA&M-eligible. The risk assessment process and the POA&M process themselves cannot be deferred. If you do not have a functioning deviation and POA&M workflow at assessment time, those practices do not score. The irony: you cannot use a POA&M to defer the practice that governs POA&Ms.

What FedRAMP Rev5 requires

Rev5 providers knew the old process cold. RA-5(d) set remediation SLAs from date of discovery: 30 days for High findings, 90 for Moderate, 180 for Low. Overdue items landed on the POA&M with milestones, reported monthly in the ConMon package. Deviations were formal requests: OR, FP, or RA, each with documented justification, type-specific evidence, and authorizing official approval, linked to parent POA&M items so the monthly report reflected current status. That is now the historical process.

The Consolidated Rules for 2026 apply to Rev5 as well as 20x, and they retire all of it:

• The provider POA&M as a FedRAMP artifact is eliminated. Agencies still keep POA&Ms for agency-owned actions and risk acceptances; providers no longer submit one to FedRAMP.
• Deviation requests are gone. There is no FP, OR, or RA request to file and nobody at FedRAMP waiting to adjudicate it. The false positive call is now your own evaluation obligation: providers SHOULD evaluate detected vulnerabilities in the context of the offering to determine if they are false positives (VER-EVA-EFP).
• The 30/90/180 SLAs are replaced by class-and-impact-based timeframes (covered in the next section), mandated for both Rev5 and 20x by CISA BOD 26-04, with the new vulnerability process required by December 7, 2026.
• Monthly reporting survives in a new form: a human-readable vulnerability activity report at least monthly (VER-TFR-MHR), plus accepted vulnerabilities summarized in the Ongoing Certification Report every 3 months (CCM-OCR-AVL).

What independent assessors look for shifts with it:

• Evaluation records for every finding: exploitability, internet reachability, and impact rating, with dates
• False positive determinations backed by evidence specific to your configuration, not placeholder text
• A named approver behind every risk acceptance that feeds an accepted-vulnerability categorization
• Vulnerability reports that match your operational data, not a spreadsheet assembled at month end

The reconciliation trap did not go away; it moved. If deviation analysis lives in one tracker and vulnerability reports are assembled from another, the monthly activity report and the accepted-vulnerability list will disagree. Inconsistencies in published certification data are worse than inconsistencies in a private POA&M, because agencies read the reports directly.

What FedRAMP 20x requires

Under the Consolidated Rules, vulnerability handling splits across two rule families, both mandated by CISA BOD 26-04 with an obtain deadline of December 7, 2026, and both applying to 20x and Rev5:

• VDR (Vulnerability Detection and Response): detection cadences plus mitigation and remediation timeframes.
• VER (Vulnerability Evaluation and Reporting): contextual evaluation and all reporting, including accepted vulnerabilities.

Every detected vulnerability gets three evaluations under VER, all MUST:

• VER-EVA-EIR: is it an Internet-Reachable Vulnerability (IRV)? Binary determination.
• VER-EVA-ELX: is it a Likely Exploitable Vulnerability (LEV)? Binary determination.
• VER-EVA-EPA: estimate the Potential Agency Impact N-rating (PAIN), N1 through N5.

The 192-day threshold (VER-TFR-MAV, MUST): 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 not a target. It is a mandatory reclassification point. Traditional POA&M extensions could run indefinitely. The 192-day rule forces an explicit “accepted vulnerability” categorization instead.

Accepted vulnerability reporting (VER-RPT-AVI, MUST) requires:

• The provider’s internally assigned tracking identifier
• Time and source of the detection
• Time of completed evaluation
• Internet-reachability status (IRV or not)
• Exploitability status (LEV or not)
• Currently estimated Potential Agency Impact N-rating
• Explanation of why this is an accepted vulnerability
• Supplementary information that helps agencies assess or mitigate the risk to their data

Recommended remediation timeframes (VDR-TFR-PVR, SHOULD) for Class C (the successor to Moderate), measured from evaluation, for likely exploitable, internet-reachable vulnerabilities:

• PAIN-5 + LEV + IRV: 2 days
• PAIN-4 + LEV + IRV: 4 days
• PAIN-3 + LEV + IRV: 16 days
• PAIN-2 + LEV + IRV: 48 days

Timeframes stretch for findings that are not internet-reachable or not likely exploitable, out to 192 days, which is exactly where the accepted-vulnerability rule takes over.

The key shift: the rules force an explicit decision. After 192 days, a finding is no longer “open and being worked.” It is “accepted.” That categorization is visible to every agency consuming your certification data, in the monthly reporting and in the Ongoing Certification Report. Agencies use the PAIN rating, exploitability status, and reachability status to make their own risk decisions about whether to continue using your service.

The MUST versus SHOULD distinction matters when designing workflows. The 192-day accepted vulnerability rule (VER-TFR-MAV) is mandatory. The remediation timeframes (VDR-TFR-PVR) are recommended targets. Build workflows that enforce the MUST and surface the SHOULD.

Common gap: no process for accepted vulnerability documentation, no PAIN scoring, no 192-day tracking, no IRV or LEV determinations, and vulnerability data not structured for machine-readable reporting.

The pain we lived

Deviation management was where our disconnected tools broke down the hardest.

We tracked deviations in a spreadsheet separate from the POA&M. The POA&M lived in another spreadsheet, or sometimes in a different tool entirely. Every month, someone reconciled the two. Did the deviation tracker include all the POA&M items that had deviations? Did the POA&M reflect the correct deviation type for each item? Did the approval dates match? Did the compensating controls description in the deviation tracker match the mitigation notes in the POA&M?

This reconciliation consumed hours and was never clean. The deviation tracker would list an item as False Positive. The POA&M would still show it as open with a remediation milestone. Someone had updated one and not the other. The assessor would pull both artifacts, see the inconsistency, and that was a finding about the process itself, on top of whatever the original finding was.

Authorizing official sign-off was worse. Every deviation needed documented approval. Those approvals happened over email. Six months later, when an assessor asked for the approval evidence, we spent an hour searching for the email. Sometimes the approver had left the organization and the approval was in a deactivated account.

Periodic review was supposed to happen. It did not. An operational requirement would be approved in January, scheduled for review in July, and nobody would remember to review it. The OR would sit there, approved and stale, with compensating controls that may no longer be valid. When the assessor asked for evidence of periodic review, we could show the initial approval but not the follow-up.

The POA&M itself became a parking lot. Findings would land on it, get a milestone, miss the milestone, get a new milestone, miss that one too. The POA&M grew, but nothing closed. Extensions were the norm. We had POA&M items that were two years old with the same “waiting for vendor patch” justification, re-dated quarterly. The 192-day accepted-vulnerability rule (VER-TFR-MAV) exists because of that pattern: every long-standing item now gets categorized as accepted, with full documentation, in reports agencies actually read. Under our old process, we were not ready for that.

How we automate it

Here is how we built deviation management in Stratus GRC-ITSM. The goal: eliminate the reconciliation problem by making the deviation, the finding, and the reporting the same connected data.

1. Deviation as an approval-gated ticket. When a finding warrants a false positive call, a risk acceptance, or an operational requirement, a deviation ticket is created with the rationale and evidence, parented to the vulnerability Issue tickets it covers. Same system, one relationship, not a separate tracker. The ticket is stamped automatically with the FedRAMP controls, KSIs, FedRAMP Rules, and CMMC mappings that apply, scoped to the system’s baselines.
2. Type-specific rationale and evidence. FPs require evidence specific to the environment, not a generic note. ORs require justification and compensating controls. RAs require a risk analysis explaining why the actual risk is lower than the scanner severity. This is the analysis that has to stand behind an accepted-vulnerability categorization.
3. Approval stays human. Deviations route to the right approver, and the approver’s identity and timestamp are captured on the ticket. Deviations are never auto-approved; that gate is a design decision, not a gap in the automation. Rejected deviations put the finding back into active remediation.
4. Approved deviations cascade automatically. When a deviation is approved or changes state, its status, priority, and risk posture propagate down to every Issue it covers, SLA-aware across the remediation SLA regimes. Approve one false positive covering forty per-asset findings and all forty update, with their SLA clocks handled correctly.
5. 192-day accepted vulnerability tracking. Every Issue carries its remediation SLA for the applicable regime, with a running clock from evaluation date. SLA-breach and due-by-week reports surface findings approaching the threshold early, so teams have time to remediate or prepare the acceptance analysis. Findings that cross it are reported as accepted vulnerabilities with the VER-RPT-AVI fields: tracking ID, detection and evaluation times, IRV and LEV status, PAIN rating, and the deviation’s rationale as the explanation of acceptance.
6. Deviation activity self-generates KSI validation evidence. Working deviations correctly, with rationale, evidence, and human approval, generates dated validation evidence into KSI tracking automatically. The deviation workflow is not just risk management; it is proof the process runs.
7. Reporting from live data. The open and closed Issue reports are the POA&M for CMMC, and the same data produces the machine-readable vulnerability and accepted-vulnerability reports FedRAMP wants. A finding covered by an approved deviation shows that status in every report immediately. Nothing to reconcile.

graph LR
    ISS[Vulnerability Issue] --> DEV[Deviation Ticket]
    DEV --> TYPE[False Positive / Risk Accepted / Operational Requirement]
    TYPE --> APR[Human Approval + Evidence]
    APR --> RPT[POA&M and Accepted Vulnerability Reports]

    style ISS fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style DEV fill:#4a1a5c,stroke:#c77dff,color:#fff
    style TYPE fill:#5c4a1a,stroke:#ffc857,color:#fff
    style APR fill:#1a5c3d,stroke:#51cf66,color:#fff
    style RPT fill:#2b5797,stroke:#5b9bd5,color:#fff

One data model handles CMMC risk acceptance evidence and the FedRAMP accepted-vulnerability categorization and reporting. The Issue Ticket is the finding. The deviation is parented to it. The POA&M and the accepted-vulnerability report pull from the same records. No monthly reconciliation between tools.

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.]