Should a retest be included in the price of a penetration test?

It should be stated either way. Some providers include one retest round in the engagement price, others charge for it separately, and some leave it out of the quote entirely. Whichever applies, the quote should name how many rounds are included, the window in which you can request one, and what happens to findings that fail the retest.

Penetration Test Retest: What Counts as Fixed, and What the Quote Should Say

Q: What is a penetration test retest?

A retest is a follow-up check, after you have applied fixes, that each reported finding can no longer be exploited the way the tester originally exploited it. It is run against the specific technique that worked, not as a fresh broad test of the whole environment, and it ends with a statement of which findings are closed, which are partly fixed, and which remain open.

Q: Is a retest the same as running a vulnerability scan again?

No. A scan re-checks for known signatures and can report a clean result while the underlying weakness is still reachable by a different path. A retest repeats the original attack path and variations of it, because a fix that blocks one request but leaves the flaw in place is the most common way a finding is wrongly marked closed.

Q: What happens if a finding fails the retest?

It stays open and is reported as such, with a note on what was tried and why it still works. The useful question for a provider is whether a second attempt after a further fix is covered, because real remediation often takes more than one round.

The short answer

A penetration test retest is a second, narrower test after you have fixed what the first one found. Its job is to confirm that each reported finding can no longer be exploited the way it was exploited the first time, and to say so in writing. It is not a vulnerability scan run again, and it is not a second full test. What counts as "fixed" has to be defined before the first test starts, because a retest that is not scoped in the quote is the one part of a pentest engagement most likely to be dropped, argued about, or billed as a surprise.

Who this is for

This is for the Head of Security, CISO, or engineering lead at a casino, crypto exchange, or fintech whose pentest report is about to land, or who is comparing quotes and wants to know what the retest line should say. It is about the follow-up step. For what goes into the first test, see scoping a penetration test for an online casino; for what the report itself should contain, see what a real pentest report looks like.

Why a finding is not closed when the report is delivered

A report lists what was found at a point in time. Closing a finding means two separate things happened afterwards: your team changed something, and someone verified that the change removed the exposure. Teams often treat the first as the second. A ticket moves to "done", the dashboard goes green, and nobody has tried the attack again.

The gap matters because fixes are frequently narrower than the flaw. A common pattern is a patch that blocks the exact request the tester used while leaving the same weakness reachable by a slightly different one. The ticket is correctly closed against the report text and the exposure is still there. A retest exists to catch that.

What a retest checks

For each finding, a sound retest asks, in order:

Does the original technique still work? The tester repeats the exact steps from the report.
Does a close variation still work? The same weakness, reached by a different parameter, endpoint, encoding, or role.
Is the root cause addressed, or only the symptom? Input validated in one place and not another, a permission added to one route and not its sibling.
Does anything the fix touched now behave differently? Only if the retest scope includes this; see the quote section below.

The result is a status per finding, not a single pass or fail for the engagement:

Status	Meaning
Closed	The original technique and reasonable variations no longer work
Partly fixed	The original path is blocked, a variation still works
Open	The finding is still exploitable as reported
Not retested	Out of the retest scope or not yet remediated, with the reason stated

If a provider's retest result is a single line saying "remediation verified" with no per-finding status, you do not have evidence you could show an auditor or a regulator.

Retest versus re-scan

A vulnerability scanner checks for known signatures and misconfigurations. It is the right tool for breadth, and it belongs in your routine; the difference between a vulnerability assessment and a penetration test is covered separately. As a way of confirming a pentest finding is fixed, it is weak for one reason: pentest findings are very often things a scanner never reported in the first place, such as broken business logic, a chained path across several low-severity issues, or an authorization check missing on a single function. A clean scan after remediation says nothing about those.

What a retest does not cover

A retest is deliberately scoped to the original findings. It is not:

A new full test of the environment. New features shipped since the test are outside it.
A guarantee that the application is secure. It confirms specific findings only.
A review of everything you changed. Unless the quote says so, code or configuration changes made in the fix are not independently reviewed.

Knowing this up front avoids the most common retest dispute: the retest passes, a new issue appears in a fix, and the customer believed the retest had cleared the changed area too.

What the retest terms in the quote should say

Ask each provider to put these in writing and compare:

Included or separate. Whether a retest is in the engagement price or quoted on its own.
Rounds. How many retest rounds are included, and the price of a further round.
Window. The period after report delivery in which you can request a retest, and how long the provider's access and environment assumptions remain valid.
Scope. Which findings are covered: all of them, or only those above a severity you choose. Low-severity items in a chain can matter more than their label.
Who performs it. Whether it is the tester who found the issue or someone new who has to re-learn the target.
Output. A per-finding status table and an updated report, not a verbal confirmation.
Failed findings. What happens to a finding that fails: is a second attempt after a further fix covered?
Fix review. Whether the retest looks at what was changed, or only re-attacks the original path.

If items 2, 6, or 7 are missing, the retest is a promise and not a deliverable.

Questions worth asking on the first call

If a finding fails the retest, what is the process and what does it cost?
Will the engineer who found it do the retest?
How do you handle a fix that blocks our exact payload but not the underlying weakness?
Can we see a redacted example of a retest status table?
How long after delivery can we still ask for a retest?

A provider who has run many retests will answer these in specifics. A provider who has not will answer with the word "included".

What this does not replace

A retest closes the loop on one engagement. It does not replace a recurring vulnerability assessment, and it does not watch your environment between tests, which is the job of a Managed SOC. Regulated firms should also check what their framework expects around evidence of remediation, and keep the retest report with the original.

Limitations

This is a buyer's framework. It does not set a remediation deadline for your organisation and does not interpret a specific regulation's retest requirements; check the current text of the framework that applies to you. It ranks no provider and cites no statistics.

What to do next

Lay the quotes you hold next to the eight items above and mark what each one leaves out. If you want a second reader on a draft scope before you sign, request a fixed quote for a penetration test and send the retest wording with it. The Penetration Testing page describes how an engagement runs from scope to retest.

Frequently asked questions

What is a penetration test retest? A follow-up check that each reported finding can no longer be exploited the way it originally was, run against the specific technique that worked and ending in a per-finding status.

Is a retest the same as running a vulnerability scan again? No. A scan can come back clean while the underlying weakness is still reachable by a different path. A retest repeats the original attack path and variations of it.

Should a retest be included in the price? It should be stated either way: rounds included, the request window, and what happens to findings that fail.

What happens if a finding fails the retest? It stays open and is reported with what was tried. Ask whether a second attempt after a further fix is covered.

Does a retest cover new vulnerabilities introduced by the fixes? Only if the quote says so. A retest is scoped to the original findings.

Sources and review

This article describes retest practice in general terms and cites no external statistics and no AnySec-original numbers, case results, or SLA figures. Engagement shape follows AnySec's published Penetration Testing service terms. Author: AnySec Engineering. Published 2026-10-04; last reviewed 2026-10-04.