Penetration Test Findings That Never Get Fixed: Running a Retest Programme

The report is not the outcome

An assessment produces a document, a debrief, and a set of findings. The findings that matter are the ones that are still open six months later, and those are rarely the ones the report emphasised. A critical finding in a system scheduled for replacement is a decision, and a medium finding in the payment path is a risk nobody owns.
A retest programme exists to convert findings into tracked changes, and it fails for mundane reasons rather than technical ones.

Why findings stay open

Ownership is unclear. The finding was reported against an application operated by one team and developed by another. Neither considers it theirs.
The fix is not funded. A finding that requires a design change competes with feature work and loses by default, because the risk is probabilistic and the feature has a date.
The finding is not reproducible. It was demonstrated during a short window, described in prose, and nobody can reproduce it in the environment that now exists.
The finding is a duplicate or a variant of one already closed, and the tracking system lists it separately, so the count grows and the credibility of the list falls.

A retest process that holds

Make acceptance explicit. Every finding is either scheduled with a date or formally accepted with a named risk owner and an expiry. "Open" is not a status; it is an absence of a decision.
Track the retest, not the report. A finding is closed when the original technique no longer works against the current build, demonstrated and recorded. A configuration screenshot is evidence of intent, not of effect.
Keep the reproduction detail. The request, the payload, the account and the observed response are what allow a retest months later, and they are the part most often omitted to keep the report readable.
Report the closure rate, not the finding count. The number that predicts risk reduction is the proportion of previous findings verified closed, and it is the number that should be reported to management.

Defensive implications and limits

The limit is that an assessment samples the environment at a point in time. Closing every finding from one test does not mean the system is secure; it means the sampled issues were addressed.
Retesting also consumes the same scarce specialist capacity as testing. A programme that retests everything and tests nothing new will confirm that last year's findings are fixed while new functionality ships unreviewed. The useful balance is to retest findings above a severity threshold and to keep the discovery work going, which is less satisfying than a clean closure rate and closer to what reduces risk over time.