After the Pentest Report: A Practitioner’s Playbook for Triage, Remediation, and Retest

TL;DR: Fewer than half of all pentest findings ever get fixed, and even the highest-risk ones sit open for over a month past their SLA. The report was never the deliverable that mattered. What you do with it is. This is a practical framework for triaging findings, prioritizing fixes, and closing the loop with a real retest, not just another annual scan.

Most organizations treat a penetration test report as the finish line. The PDF lands, a few tickets get filed, and attention moves back to the roadmap, until the next annual test turns up half the same findings under a new CVE.

The data backs this up. Only 48% of identified vulnerabilities are ever remediated, and even the most severe findings only reach a 69% fix rate, leaving roughly a third of top-tier risk sitting open, at a median resolve time of 37 days against a typical two-week SLA. The gap is widest for AI/LLM findings: they surface at over 2.5x the rate of other findings, yet get fixed only 38% of the time, the lowest of any asset type.

None of this is a testing problem. It’s a remediation problem, and it’s fixable with a structured process applied after every engagement.

Why Findings Stall

Before fixing the process, it helps to name where it actually breaks down. In practice, it’s rarely one dramatic failure. It’s a handful of small, compounding gaps:

Deduplication never happens

A web app test and an API test surface the same underlying authorization flaw from two angles. Without cross-referencing, it shows up as two tickets, gets partially fixed once, and reopens on the next test.

Ownership is ambiguous

A finding in a third-party library sits between the engineering team that pulled it in and the security team that flagged it. Neither owns the fix, so neither prioritizes it.

Severity gets flattened

A CVSS score alone doesn’t tell an engineering lead whether a finding is actually reachable in production, or theoretical. Everything above “Medium” ends up in the same undifferentiated backlog.

There’s no retest loop

The finding gets marked “resolved” based on a code change, not a verification test. It ships, and the fix quietly regresses six months later.

Each of these is a process gap, not a technical one, which means each is solvable without new tooling.

A Triage Framework That Actually Prioritizes

Replace “severity” as the only sorting variable with a three-part lens applied to every finding:

1. Exploitability. Is this reachable by an unauthenticated attacker, or does it require an already-compromised internal foothold? Findings your pentest team could actually chain into further access during the engagement should jump the queue. That’s a signal no CVSS score fully captures.
2. Business impact. What does this finding sit in front of? A broken access control on a customer billing endpoint is not the same risk as the same flaw on an internal admin tool used by three people. Map findings to the data or system they expose, not just their technical description.
3. Fix cost. Some high-severity findings are a one-line configuration change. Some medium-severity findings require an architecture rework. Sequencing quick, high-impact fixes first builds momentum and closes real exposure faster than working strictly down a severity list.

Score each finding across these three dimensions and you get a prioritization order that reflects actual risk reduction per unit of engineering effort, not just a list sorted by an automated scanner’s opinion.

Closing the Loop: Build a Retest Habit, Not Just an Annual Event

A fix that hasn’t been retested is a hypothesis, not a resolution. The organizations that close the remediation gap treat retesting as a standing part of the engagement, not a separate purchase decision made months later:

• Set a retest checkpoint at a fixed interval after remediation is claimed, not “whenever the next annual test happens.”
• Retest against the original proof-of-concept, not just the patched code path. Attackers don’t respect the boundaries of your fix.
• Track “reopened” findings as their own metric. A rising reopen rate is an early signal of process breakdown, well before it shows up as a breach.

This is exactly the gap Orenda’s continuous penetration testing is built to close. The same discipline that separates a real exposure from something that just got flagged also applies to remediation: a fix that hasn’t been retested is still just a claim, not a validated outcome. Instead of a fix sitting on a “resolved” ticket until next year’s engagement rolls around, continuous pentesting keeps a retest checkpoint on the calendar as a standing part of the relationship, not a new scoping conversation every time. Findings get retested against the original proof-of-concept on a fixed cadence, reopened findings get tracked as a running metric instead of a surprise, and retest window becomes something the engagement is built around rather than something a team has to remember to schedule. The habit only sticks when the cadence is structural, and that’s the problem continuous engagement is designed to solve.

AI and LLM Findings Need Their Own SLA

Given the current 38% fix rate on AI/LLM findings, treating them under the same SLA as a standard web app vulnerability is part of the problem. These findings often involve unfamiliar territory for engineering teams, including prompt injection, insecure tool-calling, and model output handling, and deserve a shorter SLA and a named owner, not a slot in the general backlog where unfamiliar findings tend to stall longest.

The Report Was Never the Point

A pentest report is a snapshot of risk at a moment in time. Its value is entirely determined by what happens in the weeks after delivery. Organizations that close the remediation gap don’t necessarily run more tests. They run a tighter triage-to-retest loop around the tests they already do.

If your last report is still sitting mostly unaddressed, that’s not a reason to wait for the next annual cycle. It’s the reason to build the loop now. Knowing what’s actually exploitable, not just what got flagged, is only half the equation. The other half is knowing what got fixed, not just what got claimed. Orenda’s continuous penetration testing engagements are built around exactly this cadence: structured findings, clear retest checkpoints, and validation that a fix actually holds, not just a PDF and a handshake.

Request a quote for more information