In a patch report, "done" can mean the vulnerable code was replaced, a workaround reduced exposure, the system was retired, or a ticket was marked closed. Only the first fully removes the flaw. Ask which definition was used, because the time to each state can differ by weeks.
Five meanings of "done"
| State | What changed | Residual risk |
|---|---|---|
| Patched and verified | Fixed version is running and confirmed | Low |
| Patched, not verified | Package or image updated, not redeployed or tested | Unknown |
| Mitigated | Config change, rule or isolation in place | Flaw still present |
| Accepted | Owner agrees to live with it, with a date to review | Full, but known |
| Closed in tool | A scanner or ticket stopped showing it | Could be a false closure |
The 2025 Verizon DBIR language is useful here. Press coverage quotes it as 54% "fully remediated", which implies there are partial states (Infosecurity Magazine). Reports that use a weaker word, such as "addressed" or "resolved", may include mitigation.
Why the definition shifts the time
Mitigation is usually faster than a patch, because it avoids testing a new version. If a report counts mitigation as done, its times will look better than a report that requires the fixed version to be running. Neither is wrong, but they are not comparable.
Common false closures
- A package was bumped in a manifest, but the running service was never redeployed.
- A scanner stopped detecting a flaw because of a changed scan configuration.
- A ticket was closed when the pull request merged, not when the release shipped.
- A finding was suppressed without an owner or expiry.
How to define done in your own program
- Write one sentence for each state in the table above.
- Only the first state stops the clock for a "fixed" metric.
- Report mitigations separately, with the date a real fix is expected.
- Verify with a rescan after redeploy, not before.
Keeping mitigation as its own line also gives leadership an honest picture: how much exposure is reduced today, and how much is actually gone.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at where a fix is available and what still has to happen before a finding can honestly be called done.
Reporting it honestly
When you present figures, show a small stacked count: verified fixed, mitigated, accepted and still open. Leadership can see at a glance how much exposure is actually removed. It also changes behavior, because a team that is measured on verified fixes stops treating ticket closure as the goal.
Why teams drift toward weak definitions
Deadlines reward closure. When a target is missed, the easiest edit is to widen what counts as done. A written definition, agreed in advance and reviewed by someone outside the team that owns the metric, prevents that drift without anyone having to accuse anyone.
Quick check
Is a mitigation a fix?
No. It lowers exposure while the flaw remains. Track it as its own state with an end date.
When should the clock stop?
When the fixed version is running and a verification step, such as a rescan after redeploy, confirms it.
Sources
Last reviewed: 19 October 2026.
