Vulnerability Deviation¶
Quick Summary
Used to formally deviate from standard remediation SLAs on one or more issue tickets. Follows FedRAMP's deviation process with a built-in approval workflow, supporting false positives, operational requirements, and risk adjustments.
The Vulnerability Deviation ticket type is used when an organization needs to formally apply a deviation to one or more issue tickets rather than remediate within the prescribed SLA. Every deviation ticket is associated with at least one parent issue (and can span multiple), creating a traceable link between the finding and the justification for not remediating it on the standard timeline.
Deviation Types¶
The available deviation types follow FedRAMP's deviation process:
- False Positive - the finding does not represent an actual vulnerability
- Operational Requirement - remediation would break a required business function
- Risk Adjustment - the risk is accepted with compensating controls or other justification
- Operational Requirement + Risk Adjustment - a combination of both
The fields in the Vulnerability Deviation tab align with FedRAMP's Vulnerability Deviation Request template, capturing the rationale, supporting evidence, and relevant metadata in a format that maps directly to what an authorizing official expects to review.
Approval Workflow¶
A key distinction from issue tickets is that deviation tickets carry an approval workflow. The typical lifecycle moves through the following statuses:
| Status | Meaning |
|---|---|
| Pending | Deviation request submitted, awaiting review |
| Approved | Deviation granted by the appropriate authority |
| Rejected | Deviation denied; standard remediation SLA applies |
| Closed | Deviation is no longer needed (not a standard end state) |
Depending on context, approval may be granted internally (for instance, by a CISO or security lead within your organization) or it may require external approval, such as from a sponsoring agency in the case of a FedRAMP authorization. This tiered approval model reflects the real-world governance chain: some deviations are within the system owner's authority to accept, while others require sign-off from the party who granted the ATO.