How to run a retest that is worth what you charge for it

A retest is the engagement most likely to be squeezed. It is short, it is quoted cheaply, and there is commercial pressure on everyone involved for the answer to be yes. It is also the document your client is most likely to forward to an auditor, a customer or an insurer, which makes it the worst place in your practice to be casual.

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.

Retest the underlying weakness with a variation you deliberately did not publish in the original report. Where the fix is claimed to be architectural, verify the architecture: if the answer was "we now validate server-side", find a path that reaches the same sink and check it there too. If the answer was "we removed the endpoint", check whether the previous version is still routable.

Ask what the fix actually was

Ask before you start, in writing. A one-line answer changes what you test. "We added a WAF rule" and "we parameterised the query" are different claims with different retest strategies, and one of them is not a fix.

Three outcomes, defined before you start

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

• Fixed. The weakness is absent and a reasonable variation of the original attack fails.
• 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.
• Open. The weakness is present. Note whether exploitability has changed since the original test.

"Could not reproduce" is not a state. It is a description of your afternoon, and it puts the client in the position of deciding what it means.

Report what the fix introduced

Remediation introduces vulnerabilities regularly: a new authorisation check placed after the data load, an input filter that breaks the encoding of a different field, a rushed deployment that exposes a debug route. 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 report it. A client who learns from you that their fix opened something else is far better served than one who learns it from an incident, and they know it.

Write a delta, not a second report

The deliverable should 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.

Include the date, the environment tested, the build or release identifier if one exists, and the name of the tester. Those four facts are what makes the document useful to an auditor a year later.

Timing is a scoping decision

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, and write it into the scoping document rather than an email thread. Agree what happens if they confirm and it turns out not to be deployed, because that will happen.

The sentence the client actually needs

Usually one they can forward: 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. Write it deliberately, put it at the top, and make sure it is true in the strict sense rather than the generous one.

Price it in the original proposal

Quoting the retest after findings exist makes it feel like an upsell triggered by bad news. Quoting it at proposal stage makes it part of the engagement, and it is the single easiest change a firm can make to raise the proportion of clients who actually verify their fixes. Which, since that is the point of the whole exercise, is worth more than the line item.

What the retest is worth to the client afterwards

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.

That changes what makes it good. It has to be findable a year later, unambiguous about dates and scope, and readable next to the original without a covering email explaining how they relate.

• Name the original assessment and its date explicitly, so the pair can be read together.
• State the environment and, where one exists, the build or release identifier.
• Say what was retested and what was not, in one sentence each.
• Keep the format identical to your report, so it reads as part of the same body of work.