Define each status by what evidence is needed to enter it. Open means found and not yet resolved. Mitigated means exposure is reduced but the flaw remains. Accepted means a named approver chose to live with it for a period. Fixed means the change is deployed. Verified means a check confirmed the flaw is gone.
Why definitions matter
Ask three engineers what "closed" means and you may get three answers: the pull request merged, the deploy finished, or the scanner stopped reporting it. Metrics built on that ambiguity mislead. A regulated team that must show timely remediation needs one meaning per word.
NIST SP 800-53 describes remediating legitimate vulnerabilities in accordance with an assessment of risk, and keeping a plan of action and milestones for known weaknesses. Both only work if statuses mean the same thing to everyone.
A model with seven states
| Status | Meaning | Evidence to enter | Exit |
|---|---|---|---|
| New | Detected, not yet reviewed | Scanner or report record | Triage |
| Triaged | Ranked and owned | Severity, owner, due date | Work starts |
| Mitigated | Exposure reduced, flaw remains | Description and proof of control | Fix or acceptance |
| Accepted | Approved risk for a period | Approver, expiry, compensating control | Expiry or fix |
| Fixed | Change deployed | Deployment record | Verification |
| Verified | Check confirms the flaw is gone | Rescan or inventory export | Terminal |
| Not affected | Finding does not apply | Reason with evidence | Terminal, revisit if code changes |
A status called "false positive" often hides two separate things: the scanner was wrong, or the code is present but unreachable. Use Not affected with a stated reason for both, and record which.
Rules that keep it honest
- Only automation or an independent person moves a finding to Verified.
- Mitigated never stops the clock. The deadline for a real fix continues, unless an acceptance is recorded.
- Accepted always has an expiry. When it passes, the finding returns to Triaged.
- Reopen automatically if a rescan finds the flaw again.
- Keep status history. The dates are your evidence.
Metrics follow from statuses
Time to Fixed measures delivery. Time to Verified measures delivery plus checking. The gap between them is a quality signal: a large gap means fixes are shipping without confirmation, or confirmation depends on slow scans.
Count Accepted and Mitigated separately from Open. Lumping them together hides how much risk the organization has chosen to carry.
Aligning with other teams
Auditors, product managers and engineers all read these statuses. Publish a one-page definition and link it from the tracker. Keep the number of statuses small, because every extra state is another way to hide work.
Our SLA dashboard guide shows how to chart these states over time.
Where tooling helps
If the tool that finds issues also tracks status, closure can be automatic. Safeguard associates findings with components and records changes in dependency inventories, so a version update and the resulting disappearance of the finding appear together. Reachability analysis can support a Not affected decision, as one input.
Quick check
Is Mitigated the same as Fixed?
No. Mitigated means the flaw is still present. Treat it as open work with reduced exposure, and keep the deadline unless an acceptance is approved.
Who can mark a finding Not affected?
Someone who can show the evidence, reviewed by a second person for higher severities. Record the reason in the finding.
Sources
Last reviewed: 19 October 2026.
