Why Vulnerability Assessments End at the Report

After years around vulnerability assessment work, one thing has always bothered me.

The assessment itself is the easier half. What comes after is harder.

An assessment means scoping the target, running the tests, verifying what turns up, and writing it into a report. That is skilled work, and it takes real effort.

But from the customer's side, nothing is fixed when the report arrives.

From there someone has to explain why a given flaw needs fixing, get the relevant people to agree, decide who does the work, secure budget and a date, make the change, and finally confirm it is gone.

In my experience, that side takes far longer.

The vendor's job usually ends at the report

An assessment vendor explains what was found. They rate severity, document how to reproduce it, and recommend a fix. Sometimes there is a readout meeting.

For most assessment contracts, that is where the scope ends.

Deliver the report, close the engagement.

On the customer's side, a different job starts at that moment.

Say the finding is "there is a problem in your authentication flow." The security owner rarely fixes that alone. They have to brief the development team, work out the blast radius, and if there is any chance of downtime, coordinate with the business side as well. If an outside vendor built the system, someone has to commission the change from that vendor.

If the fix costs money, that is a budget line. If it ships in a release, that is a schedule. And once it is done, someone has to check that the flaw is actually gone.

There is a lot of distance between finding one vulnerability and removing one vulnerability.

Most of the time goes into explaining it

Engagements that stay between engineers are the easy ones.

The hard part is explaining why a fix is necessary to people who do not work in security.

"The CVSS score is high, please fix it" does not always move anyone. Which system is this actually in? What happens if someone exploits it? How much is already blunted by other controls? Does it have to be today, or can it wait for the next release?

Without answers at that level, neither the development side nor the business side can decide.

And the work does not end once they agree.

Assign an owner, set a deadline, follow up on progress. If somebody comes back with "this change is too invasive" or "we would rather work around it," the decision reopens. When it finally ships, verify it.

Only after all of that does risk actually go down.

Writing an assessment report and managing vulnerabilities look similar. They are different jobs.

Before increasing how often you assess

People argue about assessment frequency a lot. Once a year? Twice? Every quarter?

More assessments do mean more chances to find things. Nothing wrong with that.

But if a large backlog from the last round is still open, adding another round mostly adds to the pile.

For a lot of companies, how much of what you already found has been dealt with is the more useful question than how many times a year you test.

There are limits on the supply side too. When I was on the side proposing this work, the recurring bottleneck was securing engineers who can do assessments. The end of the fiscal year fills up especially fast, and having budget does not mean you get the slot you wanted.

None of which means fewer assessments is the answer.

Where a human needs to look closely, a human should look. Where something can be checked continuously by machine — the churn in externally exposed assets, known vulnerabilities — check it every day. That split seems more natural to me.

Not stopping at "found it"

The most wasteful state in vulnerability management is finding problems that nobody follows through on.

The report lists the flaws. It was presented in a meeting. Six months later the same flaw is still there.

This is not unusual.

Historically that follow-through depended heavily on individuals. A security owner holds the list, explains it to people, chases them, verifies the fix. Which is exactly why it stops scaling as the workload grows.

What we want PentaTrail to do is not simply find more vulnerabilities.

Find what can be observed continuously from outside, prioritise it, and carry it through to why it is worth acting on and how to act. The point is to move human time away from detection and toward the judgment and the repair work that remain at the end.

PentaTrail does not close out vulnerability management on its own. Looking deeply at authenticated screens and business logic still needs a manual assessment, and the actual repair still happens on the side that owns the system.

Even so, there is still a wide gap between "assessed and reported" and "actually fixed."

The number I think security should be measured by is not how many findings were in the report. It is how much risk was gone at the end.

• Security assessment and ASM price ranges
• What drives the range in vulnerability assessment quotes
• Pricing

PentaTrail continuously checks externally exposed assets, starting from a domain you register. ASM is ¥40,000/month and CTEM is ¥68,000/month. It does not log in and assess authenticated screens. PentaTrail figures are our own published prices.