Only a fix that removes the vulnerable code from production counts as remediated in the strict sense. A mitigation reduces exposure but leaves the flaw, and an accepted risk leaves both. Report each closure type separately, or your remediation numbers will overstate how much risk went away.
Four closure types
| Closure | What it means | Risk after closure |
|---|---|---|
| Fixed | The vulnerable code or version is gone from production | Removed |
| Mitigated | A control reduces exploitability but the flaw remains | Reduced, not removed |
| Accepted | A named owner decided to live with it for a period | Unchanged |
| False positive or not applicable | The finding was wrong or does not apply to the product | None, but check the reason |
Mixing these into one "closed" count is the quickest way to make a program look better than it is.
Rules that keep the numbers honest
- A fix needs deployment evidence. A merged pull request is not a fix until it reaches production.
- A mitigation needs a description and an expiry. For example, a rule that blocks the vulnerable path, reviewed on a date.
- An acceptance needs an owner, a reason and a review date. An exception without a review date is permanent.
- A false positive needs a short reason. "Not reachable" should reference how that was checked.
See exception metrics for aging, renewals and coverage.
How to report them
Show a stacked bar of closures per month, split by type. Executives can then see how much of the progress is real reduction and how much is deferral. If accepted closures climb steadily, that is a policy conversation, not a success.
| Pattern | What it suggests |
|---|---|
| Mostly fixed | Healthy remediation |
| Rising accepted | Deferral growing, review the exception process |
| Rising false positive | Tool tuning or scope problem |
| Rising mitigated with no follow up | Temporary controls becoming permanent |
Steps to implement
- Add a required closure type field to every finding.
- Make deployment evidence a required link for fixed closures.
- Add expiry dates for mitigated and accepted.
- Run a monthly report that lists expiring items.
- Reopen items automatically when mitigation or acceptance expires.
Why this matters for audits and customers
Reviewers often ask how you handle findings you do not fix. A clear closure taxonomy with recorded decisions is a straightforward answer, and it avoids inflating figures you may be asked to substantiate later. See reporting zero findings without overclaiming.
Safeguard's autonomous remediation opens fix pull requests, off by default with every category on Manual, and its policies can record exceptions with owners and dates. A free scan shows which findings already have a fixed version.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which findings have a fix available and decide which closure type each would fall under once handled.
Quick check
Is a virtual patch a fix?
It is a mitigation. The flaw remains in the code, so record it as mitigated with an expiry.
Should accepted risks count against the SLA?
Report them separately. They are outside the SLA by decision, but they should still be visible and reviewed.
Last reviewed: 19 October 2026.
