Penetration Test Servicesby Excession Labs Request a test

Penetration testing retest: checking that fixes work

A penetration testing retest checks that fixed findings are really fixed. See what we check, the four result statuses with a sample, and what you receive.

Short answer

A penetration testing retest repeats the original proof for each finding you fixed, then reports whether the issue is closed. Excession Labs can retest fixed findings. A good retest result shows the original request, the new response, the controls that still hold, and a status for each finding: fixed, partly fixed, not fixed or not retested.

Once your team has fixed the findings in a report, a retest shows whether the fixes work. It uses the same proof as the original finding.

Why retest?#

Fixes often close one path and leave another. In the Cobalt State of Pentesting Report 2025, less than half (48%) of all findings ever get resolved, and the median time to resolve is 67 days (Cobalt, p.4).

PCI SSC's v4.0 summary of changes says exploitable vulnerabilities found during a penetration test are corrected "in accordance with the entity's assessment of the risk" (requirement 11.4.4) (PCI SSC). Vendor summaries add that testing is repeated to verify the corrections. Confirm the wording with your assessor.

What does a retest check?#

For each finding you fixed, we do four things.

  1. Replay the original proof against the fixed build.
  2. Run the original controls again: nonexistent IDs, wrong record types, another account's token, anonymous calls.
  3. Try close variants: other routes, other verbs, other roles.
  4. Check that the protections that held in the first test still hold.

What does a retest result look like?#

Each finding gets a status and the evidence behind it.

Status Meaning
Fixed The original proof no longer works. Variants and controls were checked.
Partly fixed The original path is closed but a variant still works.
Not fixed The original proof still works.
Not retested The fix was not deployed, or the finding was accepted as a risk.

Sample retest result

This is a demonstration. It uses a fictional app, Harbor Notes, and no real customer system was tested.

Finding H-02: A user can read another user's note. Status: Partly fixed.

Original request on the fixed build:

GET /api/notes/7731 HTTP/1.1
Host: app.example.com
Cookie: session=<user-A-session>

HTTP/1.1 403 Forbidden

The original path is closed (Observed). The variant GET /api/notes/7731/history still returned 200 OK with the note text of user B (Observed). Controls held: note 999999 returned 404, anonymous returned 401. Fix: apply the owner check to the history route.

What do you get?#

You get an updated report in HTML, PDF and Markdown. It keeps the original finding, adds the retest result and the evidence, and lists any new issues found near the fix. You can show it to an auditor or a customer who asks whether findings were closed. We do not promise that any buyer or auditor will accept it. See customer security review.

What do we need from you?#

  • The list of findings you fixed, and a short note on each fix.
  • The fixes deployed to the environment we test.
  • Working test accounts for every role from the first test.
  • A technical contact for questions.
  • Written authorization that still covers the scope.

The guide on what happens after a pentest covers triage and fix order. If you test after each release, see recurring penetration testing.

What changes the quote?#

The number of findings to verify, their type, the number of roles and the state of the environment set the effort. Retest terms are agreed in the scope for your project. We publish no prices (see pricing).

Have a report and want the fixes checked? Request a retest.

Questions

How many retests can we have?

Retest terms are agreed in the scope for your project. Ask at scoping what your project includes. Fixing the findings in one batch and retesting them together keeps the result clear.

What do we need to do before a retest?

Deploy the fixes to the environment we test, tell us which findings you changed, and keep the test accounts working. A short note on each fix helps us choose the right checks.

What if a fix fails?

We report the finding as not fixed or partly fixed, with the request and response that show it. We give updated guidance. You can fix again and ask for another check.

Can a retest find new issues?

Yes, near the fix. A fix often moves the weakness. We check nearby routes and the controls from the first test. A full new test is a separate scope.

Sources

  1. PCI DSS v3.2.1 to v4.0 Summary of Changes, r1 (checked 9 November 2026)
  2. Cobalt State of Pentesting Report 2025, p.4 (checked 9 November 2026)
After the pentestAfter the pentest: remediation, retest and close-outWhat to do after a penetration test: triage findings, assign fixes, verify them, request a retest and close out with evidence. Includes a tracker template.PageRecurring penetration testing after each releaseRecurring vs continuous penetration testing: we test web apps and APIs after meaningful releases, scope only what changed, and verify fixes from the last report.PagePenetration test report for a customer security reviewPrepare a penetration test report for an enterprise customer security review: what buyers ask for, report versus summary letter, what to share and timing.PageSample penetration testing report for a fictional appA full sample penetration testing report for a fictional SaaS app: scope, method, nine findings with requests and evidence, controls that held, and a fix plan.After the pentestHow to read a penetration testing report, section by sectionHow to read a penetration testing report section by section: the 13 parts, an annotated sample finding, severity versus priority, and how to plan fixes.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report