Finding problems is easy. The hard part is a system that closes them predictably.
Set clocks by severity and exposure
A critical on an internet-facing system is not the same as a critical on an isolated test host. Define remediation windows by both severity and exposure, agree them with engineering leadership rather than announcing them, and measure against the date the finding was created, not when it was assigned.
Route to the owner, not to a queue
Findings should arrive with the team that owns the asset, in the tool they already use. A security backlog nobody else can see is where findings go to age.
Exceptions are decisions
Some things genuinely cannot be fixed by the date: a vendor has no patch, the system is being decommissioned, the fix breaks a dependency. That is an exception, and it needs an owner, a compensating control, an expiry date and an approver senior enough for the risk. Expired exceptions should reopen automatically.
Measure the system, not the people
Useful numbers: median time to remediate by severity, the proportion fixed within the window, the age of the oldest open critical, and the number of live exceptions. Rising exception counts usually mean the windows are unrealistic — which is a conversation, not a compliance failure.
The feedback loop
When the same finding returns every quarter, remediation is treating a symptom. Push it back to the source: the base image, the template, the library version, the default configuration.