Deviations: counting rules and expiry behaviour¶

1. An accepted risk is still an open finding¶

Worth restating here because it is asked constantly, and because the platform's own status list makes it look otherwise.

Risk accepted is not flagged as a closed type in the status master. A vulnerability under an approved, in-date deviation therefore:

continues to count as open,
continues to appear in open totals and severity breakdowns,
and continues to age.

Customers frequently expect an approved deviation to remove the finding from their open figures. It does not, and that is deliberate — an accepted risk is still an exposure. See the platform-wide counting rules for the full status table.

2. Expiry is a date passing, not an event¶

A deviation is expired when its acceptance date has passed — recorded as the acceptance's expiry date on the vulnerability. Nothing runs to "expire" it in a way a user would witness, and nobody is necessarily told.

Consequences:

Items appear in the Expired list without any action. The date passed; that is all.
Nobody is prompted. Unless your deployment has notification configured, an expired deviation waits to be noticed. The Expired list needs reviewing on a schedule.
Expiry does not change the vulnerability's status. The finding does not reopen — it was never closed. It simply stops being covered.

3. Renewal is a new decision, not an extension¶

Renewing an expired deviation creates a fresh acceptance with a fresh end date and goes through approval again. It does not extend the original.

This matters for audit trails: a finding accepted for three consecutive years shows three separate approvals, not one long one. That is the intended behaviour — each renewal is a point at which somebody consciously re-accepted the risk.

4. Approval routing is evaluated at request time¶

Which approver a request goes to is determined by the approval configuration when the request is raised. Changing the configuration afterwards does not re-route requests already in flight.

Support check: "we changed the approval matrix but requests are still going to the old approver" — check whether those requests predate the change. New requests will route correctly.

5. Two lists that look similar and are not¶

List	Contains
Validated Vulnerabilities	Findings with an approved, still-valid deviation
Expired Vulnerabilities	Findings whose deviation has lapsed

Neither list is "closed findings". Both contain open vulnerabilities. The names suggest resolution; the contents are exposures in different administrative states.

Triage order¶

"Why is an accepted risk still in our open count?" → rule 1, by design
"These expired without warning" → rule 2, expiry is a date passing
"Why do we have three approvals for one finding?" → rule 3, renewals are separate
"Approvals are going to the wrong person" → rule 4, check request dates
"The Validated list isn't closed items" → rule 5, correct — both lists are open findings