Retesting Is Where Most Penetration Testing Contracts Quietly Fail the Buyer

Read a penetration testing statement of work closely and you will usually find that the deliverable is a document. The testing days are priced, the report is defined, the debrief is scheduled. Retesting appears as a single sentence, often as an option, occasionally with a window attached, and almost never with a definition of what a passed retest requires.

That single sentence is where the engagement either produces a security improvement or produces a PDF. Everything before it is diagnosis. Nothing in a diagnosis makes anybody safer.

What the vague clause actually permits

"One round of retesting included within 30 days" reads like a protection. Consider what it allows in practice.

It allows the retest to be consumed by whichever findings happen to be closed first, which are the easy ones, because a team clearing a backlog starts with the quick configuration changes. The architectural finding that needs a sprint of work misses the window, and by the time it is fixed the included retest is spent. It also allows the retest to be a re-run of the original exploit rather than a check of whether the underlying weakness is gone, which are different tests with different results. And it allows "fixed" to mean whatever the two parties assume it means, since nobody wrote it down.

The 30-day window is the part that deserves the most suspicion. It is set by the tester's scheduling convenience, not by your release cadence. If your change process moves a database schema alteration through review in six weeks, a 30-day retest window guarantees that the findings requiring real engineering will never be verified by the people who found them.

Four things "fixed" gets to mean

The word does a lot of unexamined work. Here is the range it covers in practice, in ascending order of how much it is worth.

What was done	What it actually establishes	Holds up under retest?
Ticket closed in the tracker	Somebody accepted the finding	No
Original payload no longer works	One input is now blocked	Sometimes, briefly
Underlying weakness removed	The class of input is handled correctly	Yes
Weakness removed plus a regression test	It will still be fixed after the next release	Yes, and stays that way

The gap between rows two and three is where most retest disputes live. A tester reports reflected input handling in a search parameter. The team adds a filter for the specific characters in the proof of concept. The retest re-runs the proof of concept, it fails, the finding is marked closed. The next tester, six months later, encodes the payload differently and reports the same weakness as new. Nothing was fixed. A signature was blocked.

Row four is the only state that survives contact with a development team over time, and it is almost never a contractual requirement. Asking for a regression test alongside the fix costs the developer an hour and removes the finding permanently. Understanding severity ratings and what a finding is actually claiming helps here, which is why reading a penetration test report properly matters more to remediation quality than to procurement.

The commercial incentive nobody names

Retesting is unattractive work for a supplier. It is short, it is difficult to schedule efficiently, it requires the original tester to be available and to reload context on an environment they last saw two months ago, and it is usually already paid for. A day of retesting earns nothing while a day of new testing earns revenue.

None of that makes suppliers dishonest. It makes retesting the thing that slips. The practical expressions of the incentive are recognisable: retests scheduled by whoever is free rather than by whoever ran the original engagement, retest confirmations delivered as a two-page letter rather than as evidence, and a preference for verifying by re-running the documented steps because that is the fastest defensible check available.

The buyer side has a matching incentive. A retest that fails reopens findings, which reopens the conversation with the customer or the auditor who asked for the report. A retest that passes closes it. Both parties benefit in the short term from a light retest, and nobody in the room is the person who will handle the incident.

Terms worth writing into the contract

These are cheap to ask for at signature and nearly impossible to obtain afterwards.

1. Retest scheduling driven by your remediation, not by a fixed window. Phrase it as a number of retest visits available for twelve months rather than one round within 30 days.
2. The original tester named, or a named substitute who has read the engagement notes, with the handover as the supplier's obligation rather than yours.
3. A written definition of closure per severity. For high and critical findings, require that the underlying weakness be tested, not the original payload, and say so explicitly.
4. Evidence with the retest result. The same standard you expect in the original report: what was attempted, what happened, and a reproducible reference. A letter asserting closure is not evidence.
5. A rule for partial remediation. Findings frequently end up mitigated rather than fixed, for instance a vulnerable component put behind an access control instead of being upgraded. Decide in advance whether that closes the finding, downgrades it, or gets recorded as an accepted risk with a named owner and a review date.
6. Retest scope covering regressions in the immediate area, not only the finding itself. Fixes introduce faults, and the code around a security fix is the code most recently changed under time pressure.

Point five is where the honest arguments happen, and having the rule written down converts an argument into a decision. Our guide on retesting and what fixed means works through the mitigation versus remediation distinction in more depth, and the scoping guidance covers how to describe the environment so that the retest can reach the same systems the original test did, which is a surprisingly common practical failure when the estate has changed in between.

What to do next

Take your last engagement and check three facts. How many findings were rated high or critical. How many of those have a retest result with evidence attached. How many were verified by testing the underlying weakness rather than re-running the original proof of concept.

If the third number is lower than the first, your remediation status is an assumption rather than a finding. Fix the contract before the next engagement rather than the report after it: retest terms are negotiable at signature and rarely negotiable later. Our VAPT and penetration testing services page sets out how we handle verification, including what evidence accompanies a closed finding.