SecOps
Risk acceptance and false positives
An exception records why a finding should temporarily stop counting as open. This guide explains the difference between accepting a real risk and deciding a report does not apply, with the recheck dates that keep those decisions from becoming permanent by accident.
Choose the right decision
| Choice | Meaning | Example |
|---|---|---|
| Risk accepted | The risk is real, but you deliberately defer remediation | A legacy service needs a replacement plan, with restricted exposure in the meantime |
| False positive | The reported issue does not apply to this target | The scanner matched a package incorrectly and you have checked the actual component |
An exception is not a fix. A low score, a difficult upgrade or a busy team is not evidence that a report is false.
Record an exception
Open a finding's Update box, choose the status, write a reason and set Recheck on. SecOps requires a future date and a note:
- Risk accepted: no more than 180 days ahead.
- False positive: no more than 365 days ahead.
Write enough for another admin to understand the target, evidence, decision and next action. Recording the decision in SecOps is not a separate approval workflow that proves your organisation's risk-acceptance policy was followed.
When does it expire?
The exception remains active through its recheck date. After that date passes, the derived model counts the finding open again if the source still reports it open, and restarts its remediation deadline from the recheck date. A source-closed finding stays fixed. The change becomes visible after the next model run.
For example, a risk acceptance with Recheck on 15 November still applies on 15 November. On a later run after that day it no longer suppresses the finding. Reassess the evidence before extending it.
An imported exception without a usable recheck date does not suppress the open finding. Check imported status mappings and dates rather than assuming the exception took effect.
Review exceptions together
Open Remediation → Exceptions to see the reasons, recorded actors and dates. Pay attention to expired decisions and missing dates. A list shrinking because findings moved into exceptions is different from a list shrinking because the underlying issues were fixed.
If an exception is no longer appropriate, update the finding to an active work status. Let the source establish Fixed after remediation.
Expected access activity is a different rule
Mark expected on an access event creates an activity-matching rule. It is separate from vulnerability risk acceptance and does not carry this exception's recheck date. It preserves the audit event while hiding matching event-based attention. See Expected activity.
Continue with Working findings or Remediation.