Pentest Findings Management: Report to Verified Fix

This article is about the findings themselves: how one travels from a line in a PDF to a verified fix, and the four places it falls out. If you are building the wider operating model around testing, vendors, scheduling and board reporting, that is covered separately in [how to run a penetration testing programme](https://securitywall.co/blog/how-to-run-a-penetration-testing-program).

Where findings actually go

The most useful published measurement comes from Cobalt's State of Pentesting research, drawn from more than 5,000 penetration tests. Two numbers matter.

48% of exploitable findings were remediated. Just over half were not. And 69% of findings rated high or critical were fixed, which means roughly three in ten serious findings stayed open. The same research found a gap between perception and reality: 81% of organisations described their security posture as strong.

There is one genuinely encouraging number alongside those. Median time to resolve serious vulnerabilities fell from 112 days in 2017 to 37 days. Teams that do fix things fix them far faster than they used to. The problem is not speed any more. It is drop off.

Drop off is not one failure. It is four, and they compound.

A workflow that leaks a fifth at each of four handoffs delivers roughly four findings in ten. That is not a model of what happens; it is an arithmetic illustration of why a plausible looking process produces the published remediation rate. The rest of this article is about closing each handoff specifically.

Handoff 1: report to backlog

The report is a document. Your engineering organisation works from a tracker. Someone has to move findings across, and if that someone is a human with a PDF open on one screen and Jira on the other, findings are lost in proportion to how tired they are.

Three failures live here:

Transcription loss. Nobody creates tickets for the low and informational findings, so they never enter the backlog and never get counted. Six months later the same issues appear on the next report, and you pay full rate to rediscover them.

Duplicate inflation. The same issue arrives from a tester, a scanner and sometimes a bug bounty report, described three different ways. Import all three and you get three tickets, three owners and an open count nobody believes. Once the count is disbelieved, the backlog stops being used as a decision tool.

Context stripping. The ticket gets the finding title and a severity, and the evidence, request and response pair and screenshot stay behind in the PDF. The engineer receives an instruction without proof, which is the fastest route to a dispute.

The fix is mechanical. Findings should arrive in the tracker, not in a document that someone copies into the tracker. Where that is not possible, one person owns transcription within a fixed window, works to a deduplication rule rather than judgement, and copies evidence across with the finding rather than referring back to the report.

Handoff 2: backlog to owner

A finding with a severity and no name attached to it will sit. This is the cheapest handoff to fix and the most frequently skipped, because assigning work to another team requires a conversation.

Name the owner during scoping, not after the report. The intake form for an engagement should carry a named engineer who will receive findings on that asset. Agreeing it before testing starts turns a negotiation into an administrative step, because at that point nobody knows what will be found and nobody is defending anything.

Three cases break this and need a rule each:

• Findings that span two teams. One owner, named, accountable for coordination. Shared ownership is no ownership.
• Findings on systems with no clear owner. The absence of an owner is itself a finding, and it belongs in the report. An unowned internet facing system is a risk independent of whatever the tester found on it.
• Group inboxes and team queues. A queue is where a finding goes to age. Assign to a person; let them reassign.

Handoff 3: owner to fix

The engineer has the ticket, the time and the intent, and still cannot close it. This handoff fails on quality of information rather than process.

Reproduction steps are the whole game. A finding an engineer cannot reproduce is a finding they cannot verify they have fixed. If the ticket does not contain the request, the response, the preconditions and the account used, the engineer either guesses or disputes. Both outcomes cost more than writing it down properly.

Remediation guidance must be specific to the configuration. A link to vendor documentation is not guidance. The engineer needs to know what to change in their stack, and where the change interacts with something else.

Disputes need a process, not a conversation. When a team says a finding is a false positive or not applicable, put the burden of proof on the dispute: the disputing team supplies evidence, the original tester reviews it, and the outcome is written down either way. Never let a verbal dismissal close a finding, and never let a dispute stop the clock. If the dispute is upheld, stop the clock retroactively.

Risk acceptance is a decision, not an absence of one. An accepted risk gets a named approver, a stated reason, a review date and an expiry. Acceptances that never expire are how a three year old critical finding surfaces in an audit with nobody able to say who agreed to it. The approver should sit on the business side, not in security: security advises on risk, the business owns it.

Handoff 4: fix to verified

This is the handoff that decides whether your remediation rate is real. Everything upstream can work perfectly and still produce a number that means nothing, because a closed ticket is not a closed finding.

Three distinct failures hide here:

The fix addresses the symptom. An input is sanitised at one entry point while the underlying handling stays unsafe, so the finding is closed and the class of issue remains. A retest of the original attack path catches this. A review of the code diff often does not.

The fix regresses. It worked when deployed and a later change undid it. This is invisible unless previously closed findings are re tested at the next engagement, which is why regression checking belongs in the workflow rather than in good intentions.

Closure is asserted rather than proven. Someone marked it done. Nothing confirmed it.

Decide in advance what happens when a retest fails. Most teams have no answer, so a failed retest quietly becomes a new ticket and the original closes. That single habit is enough to make a remediation metric meaningless. The original must stay open, the clock must keep running, and the failure must be visible.

The economics here are what push teams toward self attestation. If every verification is a scheduled engagement with a purchase order attached, most findings will be closed on assertion. SLASH runs retests automatically rather than booking them as new work, which is what makes independent verification affordable at volume rather than aspirational.

What a findings workflow needs

Strip away tooling preferences and the requirements are short. Any system that satisfies these will outperform any system that does not, whatever it is built on.

What auditors accept as remediation evidence

Most writing on this subject stops at the fix. In practice the workflow has a second customer, and it is the person auditing you. What satisfies them is narrower than teams expect, and it is decided by how you closed the finding rather than by whether you closed it.

Four numbers that expose drop off

Open finding counts hide drop off, because a finding that was silently closed looks identical to one that was fixed. These four do not.

Verified closure rate. Findings closed with verification, divided by findings closed. If this is well under 100% you are measuring tickets, not fixes. It is the single most diagnostic number in this article and almost nobody tracks it.

Reopen rate. Findings that failed retest or recurred at a later engagement. Above roughly one in ten indicates a development process problem rather than a testing problem.

Transcription completeness. Findings in the tracker divided by findings in the report. Should be exactly 1. Anything less means handoff 1 is leaking and you cannot see it anywhere else.

Oldest active exception. The age of your longest standing risk acceptance, with a count of those past review date. Expired exceptions should be zero, always.

Report the same four every cycle. Changing metrics between reports reads as managing the message, and once an exec team suspects that, they start asking for the raw reports.

Questions teams ask

What percentage of pentest findings actually get fixed? Across more than 5,000 penetration tests, Cobalt's State of Pentesting research found 48% of exploitable findings were remediated, and 69% of findings rated high or critical. So just over half of exploitable findings and roughly three in ten serious ones remained open. Teams that do fix issues now fix them considerably faster than they used to: median time to resolve serious vulnerabilities fell from 112 days in 2017 to 37 days.

What is pentest findings management? The process that carries a finding from the report to a verified fix: importing it into the engineering tracker with its evidence, deduplicating against existing findings, assigning a named owner, tracking it against a remediation window, handling disputes and exceptions, and verifying closure by retest rather than assertion.

Should findings go into Jira or a security platform? Into whatever engineering already uses. A finding that does not appear on the sprint board does not get fixed, and no amount of chasing changes that. A security platform is useful for consolidation, reporting and retest tracking, but it should push into the engineering tracker rather than expect engineers to work in two places.

Who should own remediation of a pentest finding? A named engineer on the team that owns the affected system, agreed during scoping rather than after the report arrives. Security owns the process and the evidence. The business owns the risk, which is why risk acceptance should be approved outside security.

How do we handle a finding engineering says is a false positive? Put the burden of proof on the dispute. The disputing team supplies evidence, the original tester reviews it, and the outcome is recorded whichever way it goes. The clock keeps running during the dispute and stops retroactively if the dispute is upheld. A verbal dismissal should never close a finding.

What counts as proof that a finding is fixed? For critical and high findings, an independent retest in which the original attack path is re executed and fails, performed by someone other than the engineer who wrote the fix. For medium, a reviewed code or configuration change. Self attestation is acceptable only for low and informational findings. PCI DSS requirement 11.4.4 names repeat testing explicitly.

How long should remediation take? Common windows are seven days for critical, thirty for high, ninety for medium, and next planned cycle for low. What matters more than the numbers is that the clock starts when the ticket reaches the owning team rather than when the tester found the issue. Starting it earlier punishes engineering for your import lag and the SLA loses credibility within a quarter.

Where to start

Measure transcription completeness first. Take your last report, count the findings, count the tickets, and divide. It takes twenty minutes and it tells you whether your problem is the workflow or the first ten minutes of it. Most teams who run this are surprised.

Then add verified closure rate. Those two numbers between them locate the leak, and everything else in this article is a fix for one of the four handoffs they point at.