Pentest retest

What is a pentest retest?

It is the tester coming back to check your fixes. After the report, your team fixes the findings, then the tester repeats each finding's original steps against the patched system and records whether it still reproduces. The output is a short retest report or an updated finding list with a status per finding and a retest date.

A retest is scoped to the findings, not the application. It tells you "these reported issues are fixed," which is what auditors and customers usually ask for, and nothing about flaws that were never reported.

What does a retest include and exclude?

It includes verifying each fix and the obvious variants of the same flaw. It excludes new testing of unchanged areas.

Included, in most engagements:

• Repeating the original reproduction steps for each finding in scope for retest.
• Checking closely related variants: the same missing authorization check on the sibling endpoint, the same injection on the parameter next to it.
• Confirming the fix did not simply move the problem, for example a check added to the web UI but not the API.
• A status and short evidence note for every finding, including the ones not fixed.

Excluded, unless agreed separately in the rules of engagement:

• New features or endpoints shipped since the original test.
• Areas where no finding was reported.
• A fresh attempt at chaining, privilege escalation or lateral movement across the whole scope.

The PCI SSC's guidance makes the same distinction. It says "all changes should be retested," but whether a full retest of the system is needed depends on a risk assessment of those changes. A fix that rewrites the authorization layer may justify more than a finding-by-finding check.

How is finding status reported?

Every original finding gets exactly one status and a retest date. An example status table, with invented IDs:

The statuses that cause trouble are the middle ones. "Partially fixed" should say which part remains. "Risk accepted" is the client's decision, not the tester's, and should name who accepted it. Nothing should read "Fixed" without a retest date.

The evidence for a fixed broken object level authorization finding is usually the same request from the original report, now failing. For F-01:

GET /api/projects/project_1043 HTTP/1.1
Host: api.example
Authorization: Bearer <user_b token, tenant B>

HTTP/1.1 404 Not Found
Content-Type: application/json

{"error": "not_found"}

In the original test this request returned 200 with project_1043's "name": "demo-project". The retest note records both responses.

When should a retest happen?

Soon after fixes ship, and inside the provider's retest window. None of the frameworks set a number of days; the PCI SSC guidance asks for remediation and retest "within a reasonable period of time after the original penetration test report was provided." It also warns that remediation dragging on for a long time may need a new test, since the environment will have changed.

Common practice, from published provider terms:

• HackerOne documents a remediation period "typically lasting 30 or 90 calendar days" with retests included, and a fee afterwards.
• Cobalt documents a seven-day retest turnaround per finding and a free retest period of six or twelve months depending on tier.
• Consulting quotes vary. Some include a retest round and others bill it separately; Secure Ideas, for example, lists retesting as a possible add-on. Check the statement of work.

If you run continuous penetration testing, retests can trigger automatically when a ticket moves to "ready for retest."

What do auditors and customers want to see?

They want proof that exploitable findings were fixed and that someone independent confirmed it.

PCI DSS v4.0.1 Requirement 11.4.4 reads: "Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows: In accordance with the entity's assessment of the risk posed by the security issue as defined in Requirement 6.3.1. Penetration testing is repeated to verify the corrections." (Text as mapped on Microsoft Learn; the standard itself is in the PCI SSC document library.) Requirement 11.4.1 adds that penetration testing results and remediation results are retained for at least 12 months.

The PCI SSC guidance gives an example outline for a retest report:

1. Executive summary
2. Date of original test
3. Date of retest
4. Original findings
5. Results of retest

Customers usually see this through an attestation letter, where the retest line (date, which findings were verified fixed, which were risk accepted) is one of the lines security reviewers check first.

Common mistakes

• Marking findings fixed based on the engineering ticket, with no retest.
• Retesting only the high findings and leaving mediums with no status.
• Letting the retest window lapse, then paying for a new engagement to close three findings.
• Fixing the reported endpoint and missing the sibling endpoint with the same flaw.
• Accepting risk verbally, with no named owner or rationale in the report.

Written by Parameter · Last reviewed September 27, 2026