Deviation Management Across CMMC, FedRAMP Rev5, and FedRAMP 20x

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.

There are three deviation types, consistent across frameworks:

• 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 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. There is no separate POA&M object. Deviations attach to the Issue Ticket directly. The deviation, the parent finding, and the POA&M 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 reviewed.

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.

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

FedRAMP Rev5 manages deviations through POA&M entries with milestones. The requirements are prescriptive.

RA-5(d) sets the baseline remediation SLAs from date of discovery:

• High: 30 days
• Moderate: 90 days
• Low: 180 days

Findings that exceed these timelines become overdue. Overdue POA&Ms are tracked and reported monthly in the ConMon package.

Each deviation requires documented justification plus type-specific evidence:

• Operational Requirement (OR): why remediation would break function, plus compensating controls and their effectiveness
• False Positive (FP): evidence that the scanner result is not a real vulnerability in your environment, specific to your configuration
• Risk Adjustment (RA): analysis of why actual risk is lower than scanner severity, based on environmental context

Deviations link to parent POA&M items so monthly reports reflect current deviation status. When an assessor reviews the ConMon package, the POA&M should clearly show which items are open, which are deviated, what type of deviation applies, and who approved it.

What 3PAOs look for:

• POA&M completeness: every open finding tracked with milestones and owners
• Milestone tracking that shows forward progress, not repeated extensions
• Documented justification for every overdue item
• Quality of deviation documentation: real analysis, not placeholder text
• Authorizing official approval on every deviation

Common gap: overdue POA&Ms pile up with repeated extensions and no remediation progress. The milestone date slides forward every month. The justification is “waiting for vendor patch” for the third consecutive quarter. Deviations tracked in a spreadsheet separate from the POA&M, requiring manual reconciliation every month. The deviation tracker says one thing, the POA&M says another. The inconsistencies become findings.

What FedRAMP 20x requires

20x, through the Vulnerability Detection and Response (VDR) process, adds stricter reporting for findings not remediated on schedule. VDR does not replace POA&Ms. It supplements them with a risk-based tracking methodology that forces transparency on long-standing vulnerabilities.

The relevant KSI:

• KSI-AFR-04 (Vulnerability Detection and Response): document the VDR methodology per the FedRAMP VDR process. Machine-based validations check that scanning coverage is active and comprehensive. Non-machine-based validations review that all vulnerabilities are tracked as issues with SLAs and enriched data, and that the VDR standard operating procedure aligns with 20x guidance.

The 192-day threshold (VDR-TFR-MAV, MUST): any vulnerability not 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 can run indefinitely. VDR forces an explicit “accepted vulnerability” categorization after 192 days.

Accepted vulnerability documentation (VDR-RPT-AVI) requires:

• Tracking identifier
• Detection time and source
• Evaluation time
• Internet-reachability status (IRV or non-IRV)
• Exploitability status (LEV or NLEV)
• Estimated Potential Adverse Impact (N1 through N5)
• Explanation of acceptance
• Supplementary information for agency risk decisions

Recommended remediation timeframes (SHOULD, not MUST) for the Moderate baseline:

• N5+LEV+IRV: 2 days
• N4+LEV+IRV: 4 days
• N3+LEV+IRV: 16 days
• N2+LEV+IRV: 48 days

The key shift: VDR forces 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 authorization data. Agencies use the N1 through N5 scale, 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 (VDR-TFR-MAV) is mandatory. The specific remediation timeframes (VDR-TFR-PVR) are recommended targets. Build workflows that enforce the MUST and surface the SHOULD.

Common gap on the path to 20x: no process for accepted vulnerability documentation, no N1 through N5 impact scoring, no 192-day tracking, no IRV/non-IRV classification, and POA&M data not structured for VDR 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. With VDR’s 192-day threshold, that pattern forces every long-standing item into accepted vulnerability status with full documentation. 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 deviations and POA&Ms the same thing.

1. Deviation as a linked object. When a finding cannot be remediated on schedule, a deviation is created and linked to the parent Issue Ticket. Same system, same ticket, one relationship. Not in a separate tracker. Attached to the finding it applies to.
2. Type-specific workflows. ORs, FPs, and RAs each have their own workflow with required fields. ORs require justification, compensating controls, and an expiration date. FPs require evidence specific to the environment, not a generic note. RAs require a risk analysis explaining why the actual risk is lower than the scanner severity.
3. Approval routing. Deviations route to the right approver based on type and severity. The approval, the approver’s identity, and the timestamp are captured on the deviation record. Single-click approval on the ticket, not an email chain. Approved deviations are logged. Rejected deviations put the finding back into active remediation with a new SLA.
4. Expiration and renewal. Operational requirements carry expiration dates. Approaching expiration triggers a renewal review task automatically. Expired ORs without renewal revert the finding to active remediation. No stale ORs sitting approved indefinitely with compensating controls nobody has checked in a year.
5. Automatic POA&M updates. The deviation is linked to the Issue Ticket. The Issue Ticket is the POA&M entry (when “IS POA&M” = Yes). The POA&M report reflects the deviation status automatically. An item with an active OR shows as deviated, not as overdue. When the OR expires, it shows as active again. No reconciliation between deviation tracker and POA&M. They are the same data.
6. 192-day accepted vulnerability tracking for VDR. Every open Issue Ticket has a running clock from evaluation date. Findings approaching the 192-day threshold are surfaced early so teams have time to remediate or prepare the accepted vulnerability documentation. When they cross the threshold, the VDR-RPT-AVI documentation workflow fires with all required fields: tracking ID, detection and evaluation times, IRV/non-IRV, LEV/NLEV, N1 through N5 impact, explanation of acceptance, and supplementary information. The accepted vulnerability categorization is not a manual reclassification. It is a workflow that triggers automatically.
7. Reporting consistency. Monthly vulnerability reports and POA&M exports pull from the same data. A finding with an active OR shows as deviated in every report. A finding with an expired OR shows as active. When the deviation status changes, every report that references the finding reflects the change immediately. No lag between the deviation action and the reporting output. No assembling deviation data from one spreadsheet and POA&M data from another.

graph LR
    ISS[Issue Ticket] --> DEV[Deviation]
    DEV --> OR[Operational Requirement]
    DEV --> FP[False Positive]
    DEV --> RA[Risk Adjustment]
    OR --> APR[Approval + Expiration]
    FP --> APR2[Approval + Evidence]
    RA --> APR3[Approval + Analysis]
    ISS --> POAM[POA&M Report]
    DEV --> POAM
 
    style ISS fill:#5c1a1a,stroke:#ff6b6b,color:#fff
    style DEV fill:#4a1a5c,stroke:#c77dff,color:#fff
    style OR fill:#1a3d5c,stroke:#4ecdc4,color:#fff
    style FP fill:#1a5c3d,stroke:#51cf66,color:#fff
    style RA fill:#5c4a1a,stroke:#ffc857,color:#fff
    style APR fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style APR2 fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style APR3 fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style POAM fill:#2b5797,stroke:#5b9bd5,color:#fff

One data model handles CMMC risk acceptance evidence, FedRAMP Rev5 POA&M deviation reporting, and FedRAMP 20x VDR accepted vulnerability documentation. The Issue Ticket is the finding. The deviation is attached to it. The POA&M is the same ticket. The VDR accepted vulnerability report pulls from the same record. 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.]