A look at proposals from different penetration testing providers shows a pattern for the pentest retest: it appears as a separate line item in the quote, gets charged as a flat full day or even at the full effort of the initial test, gets billed per finding, or disappears entirely on request. As a result, it is routinely negotiated away. My take: the retest should always be included in the price of a penetration test. The short version up front: the effort sits in the initial test. Everything that follows is essentially looking up your own test documentation and updating the report.
Where the effort actually sits
The effort of a penetration test sits in understanding and executing the test itself: getting to know the target, grasping the business logic of an application, enumerating functionality and attack surface, documenting findings with reproducible evidence. You do not understand a web application on day one if you have not spent hours on logins, roles, tenancy concepts, and APIs beforehand. This is where the actual costs of the test are created. And that is fine.
What a pentest retest actually is
Now let us look at the retest. For every single finding, the execution is stored in the test documentation: request, response, screenshot, notes on why the issue is critical. After the client remediates, the tester opens that documentation, replays the test steps, and checks: remediated, partially remediated, or still open. The report then gets an updated finding status and, if needed, a note that the fix is incomplete. That is it. The effort lies in hours, not days.
By the way, this is the serious yardstick for a provider's documentation quality: anyone who cannot reproduce their own findings from the documentation after four weeks had a documentation problem in the initial test. The retest is the quality control of pentest documentation.
I do not know whether I am alone with this view, or whether it is just PTDoc taking a lot of the reporting work off our hands. But anyone still writing pentest reports by hand in Word has missed the trend.
Why a separately charged retest hurts everyone
If verifying the remediations costs extra money, it turns into a budget question for the client instead of a security question. And budget questions, as experience shows, are answered in favor of whatever currently has no slack. The result is a list of findings whose remediation was never verified. The pentest is completed on paper, but it remains open whether the client actually fixed the findings correctly.
Anyone who eventually faces an auditor notices this. ISO 27001, PCI DSS, or MDR: nowhere is it enough to present only the pentest report. The evidence that critical findings were actually fixed is the real proof that the information security management loop works. A documented retest with an updated report status is exactly that proof.
To be commercially honest: a separately charged retest is almost pure margin, because the marginal effort is minimal. The range I see in third-party quotes runs from half a day up to double the effort of the actual test. A provider charging a full day is selling the client something that costs the provider a few hours. Making the client pay for the entire initial test again just to look up that provider's own documentation is the most consistent variant of the same business model: in the end, the client who actually remediates the findings is the one being punished.
Margins are not a crime, but they are not a business model that earns trust in an assurance relationship either. A provider who factors the retest in sells it in the overall price anyway. The only question is whether that reads as fair or as a hidden surcharge. That creates distrust in the project and, in the end, costs the provider more than the line item ever brings in.
The legitimate objection, and what it actually means
In the interest of fairness: there is a legitimate objection against a blanket-included retest. Some clients understand a retest as a mini pentest: regression testing of new features, testing of newly added interfaces, hunting for new vulnerabilities in the changed scope. That is not a retest, that is a follow-up test, and it logically has to be commissioned and paid for separately. But this objection is not an argument against inclusion. It is an argument for a clean scope definition in the proposal: retest means verifying the reported findings, everything else is a new engagement.
We have handled it this way for years and do not list the retest as a chargeable line item in our quotes. If you document your test steps in a structured, reproducible way, a retest is simply a matter of hours, as I described above.
Bottom line
The retest is the part of a penetration test that turns a report into a closed loop: document findings, kick off remediation, verify the state, update the status. A pentest that stops at the report only documents the state at the time of testing. A pentest with a retest documents the state that actually exists after remediation. Both have their value, but only the second one helps your risk management and the auditor who asks about it later.
A separately charged retest turns verification into a negotiating item instead of a component of your own review process. So the conclusion stays the same: the retest of the reported findings is standard and included in the price, cleanly defined in what it covers, and the discussion has lost its ground. And anyone billing a full day for the retest should be able to explain, without drama, what work is actually involved besides replaying your own test steps. That answer tells you more about the quality of the provider than any certification logo in the proposal.