The Most Expensive Part of a Penetration Test Happens After the Report Is Delivered

Ask most organizations what a penetration test costs, and they’ll quote you the invoice from the testing firm. That number is almost never the real cost.

The real cost shows up after the report lands: in the remediation that doesn’t happen, the findings that get re-discovered next year, and the risk that sits open far longer than anyone’s willing to admit out loud.

The Report Is the Easy Part

A good pentest report is genuinely useful. It’s specific, it’s evidence-based, and it tells you exactly where an attacker could get in. Firms have gotten good at this part: clear write-ups, CVSS scores, proof-of-concept screenshots, clean executive summaries.

But a report is a snapshot, not a fix. The gap between “we know about this finding” and “this finding is actually closed” is where most of the real cost, and most of the real risk, lives.

Where Pentest Value Actually Goes to Die

I’ve sat through more remediation kickoff meetings than I can count, and the pattern is depressingly consistent.

The findings get triaged, not fixed. Critical and high findings get assigned. Medium and low findings get filed away as “accepted risk,” often without anyone actually walking through what that risk means, because nobody has the bandwidth to have that conversation properly.

Ownership is unclear. A finding says “misconfigured S3 bucket” or “outdated library in the customer portal.” Great, whose job is that? Security found it, but security doesn’t own the infrastructure or the codebase. It sits in a ticket queue, assigned to a team that’s already three sprints behind on its own roadmap, and the pentest finding loses every prioritization fight against a feature deadline.

There’s no verification loop. The finding gets marked “resolved” in the tracker because someone made a change. Nobody retests it. Six months later, a config gets rolled back during a deployment, or a patch gets reverted during a rollback, and the exact same vulnerability is back, except now nobody’s looking for it, because it’s already “closed.”

The next pentest re-finds the same issues. This is the tell. When a firm comes back a year later and finds three of last year’s “resolved” findings still exploitable, that’s not a testing problem. That’s a remediation process problem, and it’s far more expensive than the test itself, because now you’ve paid twice to learn something you already knew.

Why This Keeps Happening

It’s not usually incompetence. It’s incentive structure. The pentest is a compliance deliverable with a due date: SOC 2, a customer requirement, a board ask. Once the report is delivered, the box is checked, the auditor is satisfied, and the organizational urgency evaporates. Remediation has no equivalent deadline pressure, so it competes for engineering time against things that do have deadlines: features, incidents, other compliance work.

The pentest was never actually the expensive part. Buying the test is easy. Building an organization that reliably closes what the test finds is hard, and almost nobody budgets for that part.

What I’d Actually Do Differently

If I’m advising a client on getting real value out of a pentest budget, remediation planning starts before the test does, not after the report arrives.

1. Assign owners before findings exist. Map which teams own which systems in advance, so a finding never lands in a queue with nobody’s name on it.
2. Set remediation SLAs by severity, and track them like you track uptime. If criticals have a 15 day SLA and nobody’s watching whether that SLA is met, it’s not really an SLA, it’s a suggestion.
3. Retest, don’t just mark resolved. A finding isn’t closed until someone independently verifies it’s closed. That can be the same firm, an internal red team, or even a scoped scan, but “the engineer says it’s fixed” isn’t evidence.
4. Track repeat findings year over year as a KPI. The number of findings you had is a testing metric. The number of repeat findings is a remediation metric, and it’s the one that actually tells you whether the program is working.

My Take

Most organizations measure pentest success by the report: how professional it looks, how thorough it is, how few criticals it found. I’d measure it by what the next report looks like a year later. If the same class of finding shows up twice, the test did its job and the organization didn’t.

The invoice for the test is a rounding error compared to the cost of a breach that traces back to a finding you already paid someone to identify and then never fixed. If you want to know whether your security program is mature, don’t ask how many pentests you’ve run. Ask how many findings from last year’s pentest are still open, and be honest about the answer.