In FedRAMP's legacy playbook, a deviation request is how a cloud provider asks to treat a vulnerability finding differently from its scanner rating. There are three types: false positive, risk adjustment and operational requirement. Each is tracked in the plan of action and milestones, and some need agency approval.
This post summarizes a legacy page. FedRAMP says it is moving to new rules for 2026, so check current guidance before relying on any detail.
The three types
| Type | What it says | What it needs |
|---|---|---|
| False positive | The reported vulnerability does not exist on the system | Evidence. A validated false positive moves to the closed tab. Those not validated by the assessor stay pending |
| Risk adjustment | The scanner rating is too high because of mitigating factors | Documented mitigating factors or compensating controls. Pending ones need agency approval before authorization |
| Operational requirement | The finding cannot be fixed without breaking the system | A justification. FedRAMP will not approve one for a High vulnerability, though the provider may still mitigate the risk |
The page also states that approved operational requirements are still considered open risks. A related category, vendor dependency, covers fixes waiting on a third party. It is not a deviation request, stays open and needs monthly vendor check-ins.
Timelines in the legacy playbook
The same page says Critical and High risks must be remediated within 30 days of discovery, Moderate within 90 days and Low within 180 days. That explains why deviation requests exist at all: they are the formal route for the cases where the clock cannot be met.
What to borrow even if you are not in FedRAMP
You do not need to be in a federal program to learn from the structure. It splits "not a real finding," "less severe than scored" and "real but cannot be fixed yet" into distinct, evidence-backed categories. Most internal exception processes blur these.
| FedRAMP idea | Everyday equivalent |
|---|---|
| False positive | Scanner error, documented with proof |
| Risk adjustment | Rescored with local context, such as CVSS environmental data |
| Operational requirement | Time-boxed exception with compensating controls |
| Vendor dependency | Waiting on a supplier, tracked with check-ins |
Practical points
- Keep every item on the register, including false positives.
- Do not use a risk adjustment to hide a real severity. Show the factors.
- Treat an operational requirement as open risk, with controls and an end date.
- Review dated items at fixed intervals.
This post does not claim any certification or authorization for anyone. It describes a public process.
Where Safeguard fits
Safeguard supports compliance and evidence automation and policies that record waivers and approvals, which can feed the kind of tracking these processes ask for.
Quick check
Can a High vulnerability get an operational requirement?
According to the legacy FedRAMP playbook, no. The provider may still mitigate the risk, but that type will not be approved for a High finding.
Is a false positive still tracked?
Yes. The playbook has validated false positives recorded on a closed tab, and unvalidated ones listed as pending.
Sources
Last reviewed: 19 October 2026.
