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. SentriKat's risk exception workflow lets you document and track these decisions with full audit trail.

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 formal "accept the risk" workflow with justification and expiry is.

The workflow¶

1. Identify: a vulnerability finding in SentriKat.
2. Justify: write a business justification (required).
3. Set expiry: pick an expiry date (required, max 365 days).
4. Submit: sent to an approver (team lead / security officer).
5. Approve or reject: approver reviews and either approves or sends back with a comment.
6. Track: approved exceptions are flagged RISK_ACCEPTED and excluded from SLA breach counts until expiry.
7. Re-review: 14 days before expiry, SentriKat emails the requester to renew or close.

Creating an exception¶

From the UI¶

1. Go to Vulnerabilities → pick the finding.
2. Click Accept Risk in the finding toolbar.
3. Fill the form:
4. Justification (required): why can't this be fixed? Be specific — "vendor patch not released yet, ETA Q3 2026" is good, "known issue" is not.
5. Compensating controls (optional): WAF rule, network segmentation, feature flag, etc.
6. Expiry (required): pick a date. Max 365 days from today.
7. Approver (optional): pick a specific user; defaults to the product's designated approver from Admin → Approval Workflows.
8. Submit.

The approver gets an email immediately.

From an issue tracker comment¶

If your Jira/GitHub issue has a comment with [sentrikat:accept] reason: waiting for vendor patch expiry: 2026-10-01, SentriKat treats it as an exception request. The requester is the commenter.

Approval¶

Approvers see pending exceptions in Admin → Risk Exceptions → Pending.

For each request:

• View the finding in context (severity, KEV, EPSS, affected components)
• Read the justification
• Approve with an optional comment, or Reject with a required comment
• Modify the expiry if 365 days is too long

Approved exceptions move to Active Exceptions. Rejected ones go back to the requester with the rejection comment as a notification.

Active exceptions¶

An active exception:

• Flags the finding as RISK_ACCEPTED in the UI
• Excludes it from Overdue Findings in compliance reports (but is still listed in a separate "Risk-accepted findings" section of the report — the auditors want to see it)
• Pauses the SLA clock
• Skips assignment notifications
• Is visible on the Risk Register dashboard

Expiry¶

14 days before an exception expires, SentriKat emails the requester:

"Risk exception for CVE-2024-12345 in acme-backend expires on 2026-10-01. Please renew or close."

On the expiry date itself:

• The exception becomes EXPIRED
• The finding returns to its original severity status
• The SLA clock restarts (finding is now overdue if the original deadline was earlier)
• The requester and assignee are notified

Closing an exception early¶

If the root cause is fixed before expiry, close the exception from the finding detail page:

1. Open the finding
2. Click Close Exception
3. Pick "fixed" or "no longer applicable"
4. Save

This removes the RISK_ACCEPTED flag. If the finding is truly fixed and the next scan won't see it, SentriKat auto-resolves it on the next scan.

Audit trail¶

Every risk exception produces audit entries:

• exception_requested — by user X on finding Y at time T
• exception_approved or exception_rejected — by approver
• exception_expired — system-generated on expiry date
• exception_closed_early — explicit close

Exported in the compliance reports as evidence that risk decisions were documented and reviewed.

Compliance framework mapping¶

See also¶

• Remediation — assignments and SLA policies
• Compliance Reports — how risk exceptions show up in generated reports