How to Run a Penetration Test Retest Properly

To run a retest properly, find out in writing what each fix was, verify the underlying weakness with a variation you did not publish rather than replaying the original payload, give every finding exactly one outcome, and state what you did not retest. A retest is short and quoted cheaply, yet it is the document your client is most likely to forward to an auditor, an insurer or their largest customer.

Verify the weakness, not the payload

The original proof of concept failing is necessary and nowhere near sufficient. A team that blocked your exact string has not fixed input handling; they have fixed your string, and they will believe otherwise until somebody tells them.

Retest the underlying weakness with a variation you deliberately did not publish in the original report. That is not gamesmanship: publishing every variation you know teaches a defensive team to pattern-match rather than fix, and holding one back is what lets you distinguish the two outcomes later. It is also why remediation a developer will action describes the cause, not the payload.

Ask what the fix was, in writing, before you start

A one-line answer changes what you test. These are not the same claim and they do not deserve the same retest:

What they say	What you should verify
"We added a WAF rule"	Whether the underlying weakness is still present behind it, and whether the rule is bypassable. This is mitigation, not remediation, and the report should say so.
"We parameterised the query"	Every other path reaching the same sink, not only the one you originally used.
"We removed the endpoint"	Whether an older API version, a cached route or a mobile client path still reaches it.
"We now check permissions"	Where the check lives, and whether it applies to every verb and every bulk variant of the operation.
"It was a configuration issue"	Whether the configuration is enforced by anything, or whether the next deployment can silently undo it.

Three outcomes, defined before anyone opens a terminal

Every original finding should end in exactly one state, and the definitions belong in the scoping document rather than in the tester's head.

1. Fixed. The weakness is absent and a reasonable variation of the original attack fails.
2. Partially fixed. The specific instance is resolved but other instances of the same weakness remain, or a compensating control is doing work the fix should be doing.
3. Open. The weakness is present. Note whether exploitability has changed since the original test, in either direction.

"Partially fixed" needs a sentence, not just a status. If the injection is fixed on the endpoint you reported and present on a second one you found while retesting, say so plainly, because the residual risk is not a fraction of the original; it is a different finding that happens to share a cause. Where the fix is a mitigation rather than a remediation, name the difference, because a client who believes a WAF rule fixed the query will make their next architecture decision on it.

Report what the fix introduced

Remediation introduces vulnerabilities regularly, and predictably: a new authorisation check placed after the data load, an input filter that breaks the encoding of a neighbouring field, a rushed deployment that exposes a debug route, a rate limit added to the login form and not to the password reset.

A retest scoped so tightly that new issues cannot be reported is a retest designed to produce a clean result. Say up front that anything found in the retested areas will be reported, price accordingly, and then report it.

A client who hears from you that their fix opened something else is far better served than one who hears it from an incident, and they know it.

Write a delta, not a second report

A retest is not really a document about your testing. It is the artefact the client uses to prove something to somebody else: an auditor, an insurer, a customer running a supplier assessment, a board asking whether the thing from six months ago got fixed. So it has to be readable alongside the original: per finding, the state, the evidence for that state, and nothing else. Restating descriptions and re-explaining methodology turns a five-page delta into a thirty-page document nobody compares to anything.

Name the original assessment and its date at the top, keep the format identical to your report so the pair reads as one body of work, and include the four facts an auditor needs a year later, all routinely missing:

• The date the retest was performed, not the date the document was written.
• The environment tested, and the build or release identifier if one exists.
• Who performed it, and whether it was the same tester as the original.
• Whether each fix was verified by exploiting it again or by inspecting the change.

That last one matters more than it looks. Verifying by inspection is legitimate and often the only option, but it is a weaker claim than a failed exploitation attempt, and a reader is entitled to know which one they have.

Say what you did not retest

The most common defect in a retest is silence about its own scope. A document headed "Retest" with five verified fixes reads, to anybody who was not on the call, as confirmation that the whole estate was re-examined, and it gets forwarded on exactly that reading.

• The original finding identifiers you retested, and their outcome.
• The findings you did not retest, and why: out of scope, not yet remediated, environment unavailable.
• The environment, if the fix was verified somewhere other than where the original was found.

Timing is a scoping decision, not a scheduling one

Retesting too early wastes the engagement because half the fixes are still in a release branch. Agree that the client confirms deployment to the tested environment before the window opens, put it in the scoping document rather than an email thread, and agree in advance what happens if they confirm and it turns out not to be deployed. That will happen, and negotiating it while a tester sits idle is worse than negotiating it now. Agreed vulnerability remediation timelines make the date predictable.

The sentence the client actually needs

Usually one they can forward without explanation: the critical and high findings from the original assessment have been verified as resolved, on this date, by the firm that identified them. Everything else in the document exists to support that sentence, and it is often the sentence that ends up in an attestation letter an auditor will accept.

Write it deliberately, put it at the top, and make sure it is true in the strict sense rather than the generous one. If it is not true, write the version that is; a qualified sentence you can stand behind is worth more to the client than an unqualified one that falls apart under questioning.

Price it in the original quote

Quoting a retest after findings exist makes it look like an upsell triggered by bad news. Quoting it in the original statement of work makes verification a normal part of the engagement, and it is the single easiest change a firm can make to raise the proportion of its findings that actually get fixed. Pricing penetration testing work covers how to build it in.