Why Retesting Is the Part Most Teams Skip — and Why That's a Problem

After a pentest, the typical next step is remediation. The engineering team reviews the findings, prioritizes them, and starts working through the list. This part gets done reasonably well.

The part that gets skipped is verification — confirming that each fix actually closes the vulnerability it was meant to address. Teams mark findings as "resolved" in a ticket tracker without independent verification that the fix worked.

Why fixes fail more often than expected

Security vulnerabilities often have multiple entry points. A finding might be documented against one specific endpoint, but the underlying issue exists in five places. The fix addresses the documented endpoint. The others remain vulnerable.

Authorization vulnerabilities are a common example. A broken access control issue is identified at /api/projects/{id}. The engineering team adds an authorization check at that endpoint. But the same resource is also accessible via /api/search and /api/export, neither of which was covered in the fix. The fix looks complete. The vulnerability isn't.

An independent retest catches this. A self-reported fix does not.

The difference between "fixed" and "verified fixed"

For internal purposes, marking a finding as resolved in a ticket is sufficient. For external evidence — customers, auditors, procurement reviewers — it is not.

An enterprise prospect who asks "how do you know these findings are resolved?" gets a fundamentally different answer depending on whether the fix was self-reported or independently verified.

A retest confirmation letter from the penetration tester states: "We retested finding PC-001 on [date] and confirm that the authorization bypass is no longer reproducible." That is specific, external, and credible. "Our team fixed it in the Q2 sprint" is not.

What retesting should produce

A proper retest produces a written confirmation document, not just a verbal or email sign-off. The document should list each original finding, the retesting date, the result (confirmed resolved / partially resolved / not resolved), and any observations about related surfaces.

This document is separate from the original pentest report. It is the evidence that the loop closed — not just that testing was done.

Retesting as part of the engagement, not an afterthought

The most common reason retesting gets skipped is timing. The pentest vendor finished months ago. Scheduling a retest requires a new quote, new scheduling, renewed access setup. The friction is high enough that it just doesn't happen.

The better model is to include retesting in the original engagement structure. One retest round, within 30 days of delivery, built into the price. The confirmation letter is part of the deliverable set, not an additional line item.

When retesting is built in, teams actually use it. The full cycle — discovery, remediation, verification — completes. The evidence is there when you need it.