Vulnerabilities
A closed ticket is not the same as a verified fix.
Remediation tracking connects a finding to an owner, an approved change and evidence that the intended risk reduction actually happened.
Define what closure means
A remediation record should identify the affected asset, finding, responsible owner and required action. It should also explain how completion will be verified. Without a closure standard, 'done' may mean anything from a patch being downloaded to a service actually running the corrected version.
Use status labels that distinguish planned work, implementation, verification and exceptions. This makes it possible to see where progress has stalled. A large number of completed change tasks can otherwise hide findings that are still exposed.
Plan a safe change
Patching can require restarts, compatibility checks and coordination with application owners. Establish a suitable maintenance window, a tested rollback approach where practical, and a way to confirm the business service still works. The urgency of the risk should inform the change process without eliminating accountability.
If remediation is deferred, record the approver, reason, interim safeguards and review date. An exception should be time-bound and visible. Indefinite acceptance by silence leaves both the technical team and the business without a clear decision owner.
Verify from the relevant perspective
Use a follow-up assessment, version evidence or another appropriate check to confirm the finding is resolved. If the original assessment could not authenticate, that limitation must be addressed before relying on its result. Also validate the user-facing service: removing a vulnerability while breaking the application is not a complete operational outcome.
In practice
The update installed, but the old service is still running
Illustrative scenario, not a client case study.
In a hypothetical manufacturer, an administrator installs a security update and marks the change task complete. The application requires a restart before the corrected component takes effect, but that restart was postponed during a busy production period.
- The verification step identifies that the running service still uses the old component. The finding stays open even though the installation task succeeded.
- The owner coordinates an approved restart with the business, confirms rollback options and records the temporary exposure until the maintenance window.
- After the restart, the team verifies the active version, repeats the relevant assessment and checks the business workflow. Only then does it close the finding with evidence attached.
A separate verification stage caught a gap that task completion could not. Keeping implementation and risk closure distinct makes reporting more honest and follow-up more reliable.
What to put in place
- Give every finding an owner, target date and closure test.
- Coordinate changes with service owners and recovery options.
- Track exceptions with an approver and an expiration date.
- Close findings only after technical and service verification.
The takeaway
Track the risk through to verified closure. Activity counts are useful, but they should not substitute for evidence that exposure has changed.