Retest and remediation verification

The second thing almost every buyer purchases is proof that the findings were fixed. It is cheap if you plan for it, expensive if you discover the retest window closed while the tickets sat in a backlog.

Last reviewed 2026-08-31Written by Jacob Masse, TrazTech Inc.

A retest costs $1,500 to $6,000 CAD when it is charged separately, and nothing at all when it is included in the original engagement, which it should be. The catch is the window: most firms include a retest only within 30 to 90 days of the report, and most remediation takes longer than the team promised at the readout. Miss the window and you buy the retest at day rate, or worse, you hand your customer a report full of open high findings.

What remediation verification actually is

A retest is a short, targeted engagement in which the original tester attempts the same attack again against the fixed system. It is not a fresh test and it is not a rerun of the whole scope. The tester works from the finding list, reproduces each issue in the same way it was originally proved, and records one of three outcomes.

Closed

The original proof of concept no longer works and the tester could not find a variation that does. This is the outcome that changes the report status and that an auditor will accept.

Partially remediated

The exact request no longer works but a small change to it does. Common where a fix was applied at one endpoint rather than at the authorisation layer, and it is the most useful thing a retest produces because it catches a fix that would have failed the next test anyway.

Risk accepted

You decided not to fix it and said so in writing, with the reason and who approved it. An auditor is generally content with a documented acceptance at the right level of seniority and unhappy with silence.

A retest is not a re-scan. Verifying closure by running the scanner again and diffing the output only works for findings a scanner found in the first place. The findings that matter, the authorisation flaws and the business logic problems described on assessment versus test, have to be attempted by hand. No tool knows what your application was supposed to allow.

Why this is the evidence auditors chase

Buyers assume the report is the artifact. It is half of it. A SOC 2 or ISO 27001 auditor expects to see a test, and examines what happened next. A control that identifies vulnerabilities and never remediates them is a control that does not operate. The evidence set they ask for is consistent across firms.

1. The report, dated, naming the scope and the firm.
2. A ticket for each finding above your own severity threshold, created within days of the report rather than weeks.
3. A remediation date on each ticket, and the target implied by your own policy. An SLA you wrote and then missed is worse evidence than no SLA.
4. The retest letter or memo, naming which findings were confirmed closed and on what date.
5. A written, approved acceptance for anything left open.

The gap between step one and step four is where audit findings come from, and it is why the retest is the part of the engagement worth negotiating hardest. What each framework expects is covered on SOC 2 penetration testing, ISO 27001 penetration testing, and for card environments PCI DSS, which is explicit that exploitable vulnerabilities must be corrected and testing repeated to verify the correction.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

The window, and how buyers lose it

Almost every included retest is time limited. The clause is one line in the statement of work, read after the deadline has passed. The report lands, the readout happens, engineering agrees the fixes, a release goes out, a customer escalation eats three weeks, and by the time someone asks about the retest the ninety days are gone.

The retest planner works out the dates from your report date and your window, and tells you the latest day the fixes can land and still be verified for free.

Planning remediation so the window is enough

Assume engineering capacity for security findings is smaller than everyone believed at the readout. Two things fix that without more capacity. Agree a severity threshold before the test, so nobody is negotiating which mediums matter while the clock runs. Book the retest date at the same time as the test, which turns a vague intention into a date other people plan around.

0 of 0 done · Reset

• Retest window and its start date confirmed in writing
• Retest date booked with the firm before testing starts
• Severity threshold for mandatory fixes agreed internally
• A ticket raised per finding within five working days of the report
• Named owner on every high and critical finding
• Release plan checked so fixes ship before the retest date
• Written acceptance drafted for anything you will not fix
• Retest letter requested in a form you can share with customers

The retest letter, and who you can send it to

The output of a retest should be a short document you can hand to somebody outside the company. It names the original engagement and its date, states which findings were retested, gives the outcome of each, and confirms no new testing was performed. That last line stops a reader treating the letter as a fresh clean bill of health.

Send the letter, not the report. A full penetration test report is a map of how to attack you, and the version of it that includes open findings should never go to a prospect's procurement inbox. Which document to send to whom is set out on report versus attestation letter.

Where retesting stops being enough

A retest verifies fixes against a snapshot. If you ship weekly, that snapshot is out of date almost immediately. An annual test plus a retest is usually still the right shape for the evidence, but the security value comes from testing closer to the release cadence. The models are compared on pentest as a service, including where a subscription substitutes for a scoped annual test and where it does not.

Common questions