The quick check
A client emails on Thursday: they have fixed the critical and high findings from the test in spring and need a retest before a customer audit at the end of the month. 'It should only take a day.' Your operations manager looks at the original engagement. Was a retest included in the price? The proposal says 'one retest within three months', and it has been five. The tester who did the original work is booked solid.
Someone agrees a day, partly to keep the client happy. Another tester picks it up, reads the original report the night before, and on the day finds that the client also changed their login flow, and wants that looked at 'while you are in there'. The day becomes two. The second day is not invoiced because nobody wants to argue about it.
The retest report is a new document with its own numbering, and the client's auditor asks how it relates to the original.
Why retests are messy
- Retest terms (included or chargeable, time limits, how many) are written in each proposal differently.
- Clients rarely say exactly which findings they want retested.
- The original tester has the context, but may not be available.
- Scope creep on retests is common, because the client sees the tester as already 'in'.
- Retest reports are written from scratch rather than as an update to the original findings.
Individually a retest is small. Across a busy testing firm, they add up to a steady leak of unplanned, often unbilled days.
What retests cost when they are not managed
| Problem | Result |
|---|---|
| Included retest terms unclear | Paid work given away |
| Scope not confirmed | Retest grows on the day |
| Different tester, no handover | Time spent re-learning the environment |
| Standalone retest report | Client confused, auditor asks questions |
| Urgent booking | Other engagements moved to fit it in |
The retest handling we build
- Every engagement records its retest terms in structured form: whether a retest is included, how many, within what period, and at what rate otherwise.
- A client requests a retest through a short form listing their original findings. They tick the ones they want retested and confirm they are fixed. Anything new they mention is flagged as out of retest scope.
- The system checks the request against the engagement's retest terms and shows your operations manager whether it is included, chargeable or needs a new quote, before anyone agrees a date.
- An estimate is suggested from the number and type of findings selected, using your own rules, for a person to confirm.
- Booking prefers the original tester, and if they are not available, the new tester gets a handover pack: the original findings, notes, access details and the client's remediation notes.
- The retest report updates the original findings with their new status (resolved, partially resolved, not resolved) and links to the original report, so the client's auditor can follow the thread.
- Chargeable retests create the invoice line automatically when the report is issued.
We connect this to your reporting platform and your practice or accounting system through their APIs where available, so nothing is retyped.
How retests run afterwards
A retest request arrives with the findings selected and the commercial position already clear. If it is chargeable, the client is told up front, with a price. The tester, original or not, starts with everything they need. Anything new is quoted separately rather than absorbed. And the client gets a retest report that reads as a continuation of the original, which is what their auditor wants to see.
You also see, over time, how many retests are included versus chargeable, which is useful when you set retest terms in future proposals.
Recognise this?
- Retest requests arrive without a list of findings.
- Nobody is sure whether a retest is included in the original fee.
- Retests regularly grow beyond what was agreed.
- Retest reports do not link back to the original findings.
- Chargeable retests sometimes go unbilled.