Deviations & Risk Acceptance¶
Sometimes a vulnerability cannot be fixed within its SLA. The fix may need a vendor release, a change freeze may be in force, or the cost of fixing may genuinely outweigh the risk. A deviation records that decision formally — who asked, who approved, on what grounds, and until when.
The purpose is that accepting risk is a dated, reviewable decision with a name attached, rather than a finding quietly ageing out of sight.
The shape of a deviation¶
| Requested by | The person asking to defer the fix |
| Justification | Why it cannot be fixed now, and what compensates for it |
| Approver | Determined by the approval configuration, usually by severity |
| Valid until | The date the acceptance stops being valid |
How one moves through the system¶
- Raised against a specific vulnerability, with a justification and a proposed end date.
- Routed to an approver. Who that is depends on your approval configuration — more severe findings usually require more senior sign-off.
- Approved or rejected. Rejection returns the vulnerability to normal tracking.
- Active until its end date.
- Expired once that date passes.
What expiry means¶
When a deviation expires, the vulnerability returns to normal tracking. It does not re-open — it was never closed — but it stops being covered by an accepted-risk decision and appears again in the expired list for attention.
Expired deviations can be renewed if the situation genuinely has not changed. Renewal is a fresh decision with a fresh end date, not an extension of the old one, so it goes through approval again.
A deviation does not close the vulnerability
This is the most common misunderstanding. A finding under an approved deviation is still an open finding. It still appears in open counts, and depending on your configuration it may still age.
A deviation documents why nothing is being done yet. It does not assert the weakness is gone. Only validation of an actual fix does that.
Where to find things¶
1 where you are · 2 approval state and expiry
| Screen | Shows |
|---|---|
| Deviation Management | All deviations and their current state |
| Validated Vulnerabilities | Findings with an approved, still-valid deviation |
| Expired Vulnerabilities | Findings whose deviation has lapsed and now need attention |
The Expired list is the one worth reviewing on a schedule. Items land there without anyone doing anything — the date simply passes — so nothing prompts you unless you look.
Configuration¶
Two settings shape how deviations behave:
- Approval configuration — who must approve, usually by severity.
- Designation configuration — which roles may request and which may approve.
Both are administrative settings. Changing them affects future requests, not decisions already made.