Skip to content

Risk Exceptions

Some vulnerabilities can't be fixed right now: the patch isn't available, the fix breaks something else, or the affected component is sandboxed and the risk is acceptable. Accepting a risk in SentriKat records the decision, who made it, why, and when it runs out.

Why it matters: every compliance framework (NIS2, PCI-DSS, ISO 27001, SOC 2) requires you to document risk decisions. Silently ignoring a finding is not an option. A recorded acceptance with a justification and an expiry date is.

Accepting a risk

  1. On the dashboard, find the CVE row.
  2. Open the row menu and choose Accept Risk.
  3. Fill the form:
    • Justification (required): why can't this be fixed? Be specific. "Vendor patch not released yet, ETA Q3 2026" is useful; "known issue" is not.
    • Expiry (optional): the date the acceptance runs out. The field says Leave empty for permanent exception, and empty means exactly that: the acceptance never expires on its own.
  4. Save.

The acceptance takes effect immediately. There is no approval step.

An acceptance with no date is forever

Nothing reminds you about it and nothing reopens it. For anything waiting on a vendor patch, put the date in: an acceptance that comes back by itself is the difference between a decision and a thing everybody forgot.

Only an organization administrator can accept a risk. A manager cannot: triage stops at snoozing and marking fixed.

What an accepted risk does

The finding is hidden from the main dashboard list, and the dashboard says how many are hidden, above the list:

ยท 3 risk-accepted hidden

Every active acceptance becomes a not_affected statement in the VEX document, carrying the justification, who approved it and the expiry date. Anyone downstream who consumes it sees that the vulnerability was known, assessed and accepted, rather than missed.

Expired acceptances are not exported. Once the date has passed the finding is open again, and the VEX document says so.

Expiry

An acceptance with a date expires on its own: a nightly job marks it expired and the finding comes back into the dashboard list with its original severity, which was never changed while the acceptance was in force.

There is no maximum duration. The only rule the form enforces is that the date cannot be in the past, so a five-year acceptance is allowed. That makes the date your own discipline, not a limit the product imposes.

An expired acceptance can be reactivated by an administrator: you edit it, set it back to active and give it a new date, rather than writing a new one from scratch, so the original justification and its history stay attached. Nothing reactivates by itself, so until somebody does it by hand, an acceptance that has expired is not an acceptance any more.

Compliance framework mapping

Framework Control What this helps with
NIS2 Article 21(2)(a) "policies on risk analysis"
PCI-DSS v4.0 Req 6.3.1 risk ranking and acceptance
ISO 27001:2022 A.5.24 documented risk decisions
SOC 2 CC3.2 risk identification and analysis

See also