Fixed, accepted or ticketed: close the loop on every vulnerability finding

Most vulnerability reports end the same way. The scan runs, the PDF goes out, and three months later the same findings are back in the next PDF. Nobody decided to ignore them. Nobody decided anything at all.

The fix is not a better scanner. It is a rule: every finding has to end somewhere.

Key takeaways

• Every finding should end in one of three places: fixed and proven by a rescan, accepted in writing, or ticketed with an owner and a due date.
• Rank by real-world evidence first (is it being exploited, how likely is it to be), then by severity score.
• A fix only counts when a rescan that could actually see the issue no longer finds it.
• "Accepted" needs a reason, a compensating control if there is one, and an end date.

Why findings get stuck

A raw scan export gives you hundreds of rows, each with a severity score. It does not tell you who owns the fix, when it is due, or whether the client already said no last quarter. So the report becomes a list of problems, and the list becomes background noise.

Findings get stuck in four predictable places:

1. Nobody owns them. The report went to a contact, not to the person who patches.
2. No date. "Critical" with no deadline is a mood, not a plan.
3. Silent refusals. The client said "we can't take that server down" on a call, and that decision lives nowhere.
4. No proof. The patch went in, but nobody checked the rescan, so the finding is still on the books, or worse, marked fixed when it isn't.

The three outcomes

1. Fixed, and proven

A finding is fixed when a rescan of the same system, by the same scanner, with the same access, no longer finds it. All three parts matter:

• Same system. If the host is missing from this scan, you know nothing about it.
• Same scanner. Scanners name and detect issues differently, so comparing two different tools gives you false "fixes".
• Same access. If last month's scan logged in and this month's didn't, issues that need a login were never looked for. Mark them not rechecked, not fixed.

Write the result down system by system: "OpenSSH fixed on three servers" is proof. "We did some patching" is not.

2. Accepted, in writing

Sometimes the right answer is not to fix. A legacy system runs a line-of-business app, or the fix needs downtime the client won't approve. That is a valid decision, as long as it is recorded:

• What is being accepted, and on which systems.
• Why, in the client's words.
• Compensating control, if there is one (network isolation, extra monitoring).
• Who signed off, and when the acceptance ends.

An end date matters most. Acceptances that never expire turn into permanent blind spots. When one ends, the finding comes back for a new decision.

3. Ticketed, with a due date

Everything else becomes work. Each ticket needs an owner and a due date based on how urgent the finding really is:

• Known exploited (on the CISA KEV list): fix first. If KEV gives a due date, use it when it is sooner than your own.
• Likely to be exploited (a high EPSS score): next.
• Severity alone: after that, on your normal schedule.

Put the ticket where the work already happens, in your PSA or ticketing system, not in a separate spreadsheet. Then track what is past due, by how many days, and how many were fixed on time.

A monthly loop that works

1. Scan with the same scanner and settings as last time. Use a credentialed scan if you can.
2. Rank by evidence: KEV, then exploit likelihood, then severity.
3. Decide for each new finding: fix (ticket it) or accept (record it).
4. Rescan and compare. Close what is proven fixed. Flag what came back.
5. Report the three lists to the client: fixed, accepted, in progress, with what is past due.

Do this every month and the report stops being a list of problems. It becomes a record of decisions and work done, which is what clients, auditors and insurers actually want to see.

How we built this into Scan Hub

We built Varaxon Scan Hub around this loop. It is scanner-agnostic: upload the export from the scanner you already run, or connect Microsoft Defender or ConnectSecure. Reports are evidence-led. Code ranks findings by CISA KEV, VulnCheck KEV and EPSS before severity, and AI only writes the explanations from those facts.

From there, each finding can end in one of the three places: pushed as a ticket into ConnectWise PSA or HaloPSA with a due date, accepted with a reason and an end date (or signed online by the client), or proven fixed in the next report's Since the last scan section. A proof pack rolls months of that into one PDF for audits and renewals.

Every new account gets a 14-day free trial of Core, with up to 10 reports and no card needed. Start a free trial or see sample reports.

Originally published at https://blog.varaxontech.com on October 28, 2026.