Proving the Fix: Rescanning and Verifying Vulnerability Remediation

A closed ticket only proves that someone said a vulnerability was fixed. To verify vulnerability remediation, you rescan the affected assets, ideally with authenticated checks, and confirm the finding is gone. Mitigations need their own test, because a scanner will usually still flag the vulnerable version. Build that verification into your ticket closure rules, automate the rescans, reopen findings that come back, put expiry dates on exceptions, and report verified fixes separately from claimed ones.

The sections below cover each of these in turn.

Why doesn't a closed ticket prove the fix?

Most remediation work is done in good faith. The problem is that the person closing the ticket usually sees the change they made, not its result on every affected system. Several common failures sit in that gap.

The patch didn't install

Deployment tools often report that an update was sent or scheduled, not that it installed. Updates fail for ordinary reasons: a full disk, a missing prerequisite, a conflicting process or a device that went offline mid-install. Some failures produce no error anyone sees.

The reboot never happened

Many patches only take effect after a restart. Until then, the old code is still loaded in memory and still exploitable. Servers with long uptimes and laptops that are put to sleep rather than restarted are frequent examples.

Only some instances were patched

The ticket names one server, but the vulnerable software runs on four. Load-balanced pools, clustered nodes, disaster recovery copies and forgotten test systems often share the same software. So do system images and templates, which can reintroduce the old version every time a new machine is built from them.

The fix went to the wrong place

An administrator updates the system package, but the application ships its own bundled copy of the vulnerable library. Or the change lands on the right hostname in the wrong environment. The work was real, and the vulnerability is still there.

How do you verify a fix with rescanning?

The most reliable proof is the same kind of check that found the vulnerability in the first place, run again after the change.

Rescan the affected assets promptly

Don't wait for the next scheduled scan cycle if it's weeks away. Run a targeted rescan of the affected assets once the change window closes and any required reboots are done. For internet-facing systems, include an external scan so you see what an outsider sees.

Use authenticated checks where you can

An unauthenticated scan looks at a system from the network. It often relies on service banners and responses, which may not change when a patch is applied. That can produce false results in both directions.

An authenticated scan logs in and reads the installed package versions, file versions and configuration directly. For verification, that's much stronger evidence. It can also report whether a reboot is still pending on many systems.

Confirm the scan actually worked

A finding can disappear for the wrong reasons. If the scanner couldn't log in, the host was offline or the scan timed out, the vulnerability may simply not have been checked.

Before you treat "not found" as "fixed," confirm three things:

• The asset was reachable during the scan.
• Authentication succeeded on that asset.
• The specific check for that vulnerability ran.

Most scanners report authentication failures separately. Review that report as part of every verification cycle.

How do you verify a mitigation versus a patch?

A patch removes the vulnerable code, so the scanner's finding should disappear. A mitigation, such as disabling a feature, changing a setting or blocking a port, leaves the vulnerable code in place. The scanner will usually keep reporting the finding, because the version hasn't changed.

That means mitigations need their own verification:

Keep "mitigated" as a separate status from "fixed." A mitigation reduces risk, but it can be undone by a configuration change or a new deployment. Re-verify it on a schedule and keep the underlying finding open until the patch is applied.

What closure criteria should your ticketing system use?

Verification only sticks if your ticketing system requires it. Define the workflow so that the remediation owner can't close a ticket on their own word.

A workable status flow looks like this:

1. Open. The finding is assigned to a remediation owner.
2. In progress. Work is scheduled or underway.
3. Fixed, pending verification. The owner reports the change is complete.
4. Verified closed. A rescan or specific test confirms the fix.
5. Reopened. Verification failed, or the finding came back later.

Add two side statuses: Mitigated, for workarounds awaiting a permanent fix, and Risk accepted, for approved exceptions. Both need an expiry date.

Require evidence at the verification step. That means the scan or test that confirmed the fix, its date and who or what performed it. Ideally, the security team or an automated rescan closes the ticket, not the person who made the change.

How do you automate rescans?

Manual verification works for a handful of findings. It breaks down at scale, so automate as much of it as your tools allow.

Common patterns include:

• Trigger a rescan when a ticket moves to "fixed, pending verification."
• Rescan recently changed assets daily, using your patch or change records to build the target list.
• Auto-close a ticket when an authenticated scan confirms the finding is gone from every affected asset.
• Auto-reopen a ticket when the finding reappears on any asset it covered.

Put guardrails on auto-closure. Only close on results from scans where authentication succeeded and the relevant check ran. Match findings on a stable asset identifier plus the vulnerability, rather than on hostname alone, so a rebuilt or renamed machine doesn't break the link.

Laptops that rarely connect to the office network need extra attention. Scanning agents installed on the device, where available, can report results without the machine being on the internal network.

Why track reopened findings?

A finding that comes back is telling you something about your process. Reopen the original ticket rather than creating a new one. That keeps the history together and preserves the original detection date, so the finding's age stays honest.

Common reasons for reopened findings:

• A system image or template still contains the old version.
• Configuration management or a deployment rolled back a change.
• A patch was uninstalled to fix a compatibility problem.
• The fix covered one instance but not a new one built later.

Track the reopen rate by team and by asset type. A high rate usually points to a root cause, like an outdated image, that one fix upstream will clear.

Why should exceptions expire?

Risk acceptances and mitigations are decisions made with the information available at the time. That information changes. A finding that was low risk when you accepted it may not be once exploit code is published or the system becomes internet-facing.

Give every exception:

• A named approver
• A documented reason and any compensating controls
• An expiry date, such as 90 days or six months
• An automatic return to the open queue when it expires

At each review, re-verify any mitigation the exception relies on. If the compensating control is gone, so is the basis for the exception.

How should you report verified versus claimed remediation?

Most vulnerability reports count closed tickets. That measures activity, not outcomes. Report two numbers side by side:

The gap between claimed and verified is often the most useful number on the page. A small, stable gap means your process works. A large or growing one tells you where patches aren't landing.

Measure remediation time to verified closure, not to the owner's report. Otherwise you're measuring how quickly people update tickets.

Frequently asked questions

How soon after patching should we rescan?

As soon as the change window closes and any required reboots are done. For critical findings, that usually means within a day or two. Waiting for the next monthly scan leaves you guessing for weeks.

Can we rely on our patch management tool's compliance report instead?

It's useful, but it answers a different question. It tells you whether updates it manages were installed. It won't catch bundled components, systems outside its reach or vulnerabilities fixed by configuration. Use it alongside rescanning, not in place of it.

What if the scanner keeps flagging a vulnerability we know is fixed?

Investigate before overriding it. Some systems apply security fixes without changing the version string the scanner reads, which can cause false positives. If you confirm the fix another way, record the evidence and mark the finding as a false positive with that documentation attached.

Who should close vulnerability tickets?

Ideally, not the person who made the change. Have the security team, or an automated rescan with the guardrails above, move tickets from "pending verification" to "closed." That separation keeps the metric honest without slowing the work.

Key takeaways

• A closed ticket is a claim. A clean authenticated rescan is evidence.
• Check that scans reached the asset, logged in and ran the relevant check before treating a missing finding as fixed.
• Verify mitigations with their own tests, and keep them separate from permanent fixes.
• Require verification evidence before closure, and automate rescans with sensible guardrails.
• Reopen returning findings on the original ticket and chase the root cause.
• Give every exception an expiry date and report verified remediation next to claimed remediation.