“Retest included” appears in a lot of penetration testing proposals. It sounds simple: you fix the issues, the tester checks your fixes. In practice, the phrase can mean very different things depending on who wrote it.
Some retests are a quick glance at a list of tickets. Others are a proper verification that produces evidence your auditor can rely on. The difference matters most when an audit, a customer review or a release depends on the result.
Why the retest matters
A penetration test report tells you what was wrong on the day of testing. On its own, it does not show that anything was fixed.
Auditors and enterprise customers usually want to see both halves of the story: the issues that were found, and confirmation that the serious ones were resolved. A retest closes that loop. Without it, you are left asserting that problems are fixed, with no independent check behind the claim.
A retest also catches fixes that only look complete. A patch that blocks one payload but not a slight variation is a common example. So is an authorization check added to one endpoint but not to its sibling.
What a useful retest covers
A retest should be specific. At Rudranetra, “retest included” means the following:
- One retest of every finding in the original report. Not a sample, and not only the critical ones.
- The same depth of testing for each finding. The tester reproduces the original issue, then tries reasonable variations to confirm the fix holds.
- A clear status for each finding: fixed, partially fixed, or still open. Findings you have decided to accept are recorded as risk accepted, with your reason noted.
- An updated report that shows the retest date and the current status of every finding.
- An attestation letter you can share with auditors and customers, summarising the results without exposing technical details.
The retest covers the findings in the original report. It is not a new test of new features, which would need its own scope.
When to ask for it
Timing affects how useful the retest is.
Ask too early and some fixes will not be deployed yet, so they come back as open. Ask too late and the environment may have changed so much that the original findings are hard to compare.
We ask clients to request the retest within 60 days of the report. That window gives most teams enough time to fix and deploy, while the original context is still fresh.
How to prepare
A retest goes faster when the tester knows exactly what changed. Before you ask for it:
- Deploy every fix to the environment that was tested, or tell the tester where the fixes now live.
- Note what you changed for each finding. A sentence or a link to the pull request is enough.
- Keep the test accounts working. Expired credentials are a common cause of delays.
- Flag anything you are accepting rather than fixing, with a short reason, so it is recorded correctly.
Questions to ask any provider
Before you sign, ask what “retest included” means in writing:
- Does the retest cover every finding, or only some severities?
- Is there a time limit for requesting it?
- Will you get an updated report showing the status of each finding?
- Is an attestation letter part of the deliverables?
- What happens if a fix is only partially effective?
Clear answers to these questions tell you whether the retest will give you evidence, or just reassurance.
You can see how retest status is presented in our sample report, and how the retest fits into the wider process on our how we work page.
Planning a test with an audit deadline? Talk to us and we’ll build the retest into the timeline.