Why Unlimited Retests Must Be the Standard

Short answer: Unlimited retests are essential because a pentest without verified remediation is an incomplete security exercise. If your vendor charges extra to confirm that a critical vulnerability was actually fixed, you are incentivized to skip that confirmation — leaving your organization exposed and your compliance evidence hollow.

The Retest Problem Nobody Talks About

You commissioned a penetration test. The report came back with 23 findings — three critical, seven high. Your developers spent six weeks remediating. Now what?

If your pentest vendor charges per retest, you face a real-world decision: pay again to verify each fix, or trust that the remediation worked. Most organizations, under budget and time pressure, choose to trust. The vulnerability gets marked "remediated" in a spreadsheet, the auditor sees a closed ticket, and the actual attack surface goes unverified.

This is how security theater is built, one skipped retest at a time.

The problem is structural. Traditional penetration testing firms treat the engagement as a discrete project: scope agreed, test executed, report delivered, project closed. Retesting is a new scope item — billed separately, scheduled separately, often handled by a different team member who lacks the original context. Even when clients want retests, the friction is enough to discourage thorough verification.

The result: the security loop never closes. A penetration test is only useful if it leads to verified remediation. Without a retest, you have a list of known vulnerabilities, not a confirmation of fixed ones. Those are very different things.

Why Unlimited Retests Matter

1. Closing the Security Loop

NIST SP 800-115, the technical guide to information security testing and assessment, emphasizes that the goal of a penetration test is not merely to find vulnerabilities — it is to support risk reduction. Risk reduction requires verified remediation. Without confirmation that a fix actually works, the finding remains a live risk regardless of what the ticket tracker says.

The Penetration Testing Execution Standard (PTES) similarly frames the post-exploitation and reporting phases as feeding directly into remediation, with the implicit expectation that testers can validate fixes. When retests carry a cost, that expectation becomes a budget negotiation.

Unlimited retests remove the financial barrier to closing the loop. Developers can push a fix, request a retest, get a result, and iterate — the same way software testing works in any mature engineering team.

2. Developer Confidence and Faster Remediation

Security teams often struggle to get developer buy-in on remediation. One underappreciated reason: developers don't trust that a rushed fix will satisfy the security team, and they don't want to open a back-and-forth that drags on for months.

When retests are unlimited and fast, the dynamic changes. A developer can submit a fix with confidence that it will be validated quickly. If the first attempt doesn't fully address the issue, they get specific feedback and try again — without each cycle generating a new invoice. The security engagement becomes collaborative rather than adversarial.

3. Compliance Evidence That Actually Holds Up

PCI DSS Requirement 11.3.2 is explicit: after vulnerabilities identified during penetration testing are remediated, the penetration test must be repeated to verify the fixes. This is not optional for organizations seeking PCI DSS compliance — it is a mandatory control.

SOC 2 auditors increasingly ask the same question: how do you know the vulnerabilities were fixed? A pentest report with open findings and no retest documentation is a gap finding waiting to happen.

Unlimited retests mean you can produce a complete audit trail: original finding → remediation → verified fix, for every item in scope. That documentation is the difference between passing an audit and explaining why you trusted a spreadsheet.

Vendors That Charge Per Retest vs. Vendors with Unlimited Retests

The practical impact of retest policy goes beyond cost. It shapes security outcomes.

Dimension	Charge-per-retest model	Unlimited retest model
Verification rate	Partial — high cost discourages full verification	Complete — every fix can be confirmed
Security posture	Known vulnerabilities may remain unverified	Remediation is proven, not assumed
Developer cycle	Fix once, hope it passes, avoid extra cycles	Iterate freely until the issue is resolved
Compliance evidence	Gaps between findings and verified closures	Full audit trail per finding
Total cost of engagement	Lower sticker price, hidden cost in risk exposure	Predictable, higher-value spend
Auditor risk	Potential gap findings in SOC 2 / PCI DSS audits	Clean remediation documentation
Vendor incentive	Vendor profits from unresolved findings	Vendor incentivized to help you fix fast

The last row deserves emphasis. A vendor that bills for retests has a financial interest in findings that require multiple retest cycles. That is not a good alignment of incentives. A vendor with unlimited retests is incentivized to write clear, actionable findings so remediations succeed quickly — their margin depends on scope efficiency, not retest volume.

Real-World Use Case: The Cost of Skipping Retests

Consider a mid-sized SaaS company that completes an annual penetration test and receives a report with four critical findings. Their vendor charges $200 per hour for retests. The security team estimates that verifying all four findings would require approximately 16 hours of tester time — a projected retest cost of $3,200. Under budget pressure, the team decides to mark all four findings as "remediated" based on developer sign-off, without commissioning retests.

Eleven months later, during the next annual assessment, the new testing team discovers that two of the four critical findings were never actually fixed.

The first is a stored XSS vulnerability in the admin panel. The original developer patched the user-facing input validation, but left the admin import tool — a separate code path — completely unpatched. The second is an IDOR (Insecure Direct Object Reference) vulnerability in the API. The fix was correctly applied to v2 API endpoints, but the deprecated v1 endpoints — still active and reachable in production — were never updated.

Both findings had been marked "closed" in the tracker for 11 months. Both were live vulnerabilities during that entire window. Because the application handles Protected Health Information (PHI), exposure through either vector would have triggered mandatory HIPAA breach notification under 45 CFR § 164.400–414.

The avoided retest cost was $3,200. HHS Office for Civil Rights (OCR) settlements for HIPAA violations involving PHI exposure are documented in the HHS enforcement database and range from hundreds of thousands to over a million dollars in individual cases — not counting legal fees, remediation costs, or reputational damage. The math is not close. Skipping retests is not a budget decision; it is a risk transfer decision, and the organization rarely understands the full magnitude of what it is accepting.

How to Negotiate Retest Terms in a Contract

If the vendor does not offer unlimited retests by default, several contract modifications can close the gap before you sign.

Ask for a fixed-price retest block. Rather than accepting hourly retest billing, negotiate a fixed number of retest hours — for example, 20 hours included within the engagement window. A fixed block is predictably budgeted and removes the per-event cost friction that discourages verification. It is a meaningful improvement over open-ended hourly billing, even if it falls short of a true unlimited policy.

Define "retest" precisely in the contract. Without a formal definition, vendors may interpret a retest loosely — running automated scans against the same target does not constitute a retest. The contractual definition should specify: the same tester reviews the remediated item, tests the specific attack path documented in the original finding, confirms whether the fix is complete, and documents the outcome in writing. Anything less is not a retest.

Require written retest documentation. Verbal confirmation from a developer that something is fixed is not an audit artifact. Contract language should specify that each retest cycle produces a written outcome document — marked verified closed, partially fixed, or still vulnerable — with tester name, date, and methodology notes. This documentation is what satisfies PCI DSS 11.3.2 and gives SOC 2 auditors something concrete to review.

Set a remediation window that fits your development cycle. Most vendors offer retests within 90 days of report delivery. If your development sprints and release schedules require a longer window to implement and test fixes properly, push to extend that window to 120 or 180 days during contract negotiation. Vendors will often agree to this as a goodwill term.

Ask about escalation retests explicitly. The critical question is this: if a retest reveals that a finding is still open, is an additional retest included to verify the second fix attempt? Vendors that say "yes, unlimited" to this question have a genuine unlimited policy. Vendors that hesitate, or say the second cycle requires a new authorization, are offering limited retests dressed in unlimited language. This single question separates real policy from marketing copy.

What "Unlimited" Really Means in Practice

Before assuming that "unlimited retests" is a marketing phrase, ask vendors to define it. The meaningful version looks like this:

Scope boundary: Retests cover the original engagement scope. Adding new systems or attack surfaces is a scope change, not a retest.
Timing window: Retests are included within a defined engagement window (e.g., 90 days post-report). Remediation that drags on for a year may fall outside the included window.
Communication channel: You have a direct line to the tester who found the vulnerability — not a generic support queue.
Turnaround time: Retest results are delivered within a stated SLA (e.g., 5 business days), not "when we have availability."
Documentation: Each retest produces a written confirmation of the outcome — verified fix, partial fix, or still vulnerable — suitable for audit purposes.

If a vendor says "unlimited retests" but cannot answer these questions, the policy is likely theoretical.

How to Evaluate Retest Policies When Comparing Vendors

Use this checklist when speaking with pentest vendors:

Vendor Retest Evaluation Checklist

If a vendor hesitates or gives vague answers on items 1–5, treat that as a red flag. Retest policy is a practical operational question, not a negotiation item — mature vendors have clear, documented answers.

Industry Standard vs. Best Practice

To be direct: per-retest billing is still common in the traditional pentest market, particularly among firms that operate on a pure project basis. It is the industry norm — but it is not a best practice.

The shift toward continuous and PTaaS (Penetration Testing as a Service) models has raised expectations. Organizations that have moved to continuous testing programs understand that verification is part of the service, not an add-on. The analogy to software development is apt: no engineering team would ship a bug fix without running the test suite. Penetration testing should work the same way.

Best practice is unlimited retests within the engagement scope and window, documented per finding, with a clear SLA and a direct tester relationship. That is what serious security programs demand, and what serious vendors deliver.

Frequently Asked Questions

Does PCI DSS explicitly require retesting after remediation?

Yes. PCI DSS Requirement 11.3.2 states that if significant vulnerabilities or changes to the environment are identified, penetration testing must be repeated to verify that the vulnerabilities have been remediated. This requirement is not advisory — it is a mandatory control assessed during a PCI DSS audit. A pentest report that shows critical findings with no corresponding retest documentation is a direct gap finding. For organizations scoped under PCI DSS, the retest is not a vendor option or a budget item; it is a compliance obligation. The documentation produced by that retest — including the tester's written confirmation that the specific attack path is no longer exploitable — is what satisfies the requirement.

What is the standard turnaround time for a retest?

There is no single industry standard, but common SLAs in mature security programs range from three to seven business days for a finding-level retest. The variability depends on engagement complexity, tester availability, and how the vendor manages scheduling. Some PTaaS platforms guarantee retest results within five business days as a contractual commitment. Hourly-billing firms with no dedicated retest capacity may take two to four weeks to schedule and complete the work. When evaluating vendors, ask specifically for the retest SLA in writing — "when availability allows" is not an SLA, and it is not a number you can hold the vendor to during an audit.

Can I do an internal retest instead of using the original vendor?

Technically, yes — but it carries risk, particularly in regulated environments. An internal retest conducted by the organization's own security team can verify that a fix was applied. What it typically cannot provide is the same independence and adversarial perspective as the external tester. For PCI DSS purposes, Requirement 11.3.2 does not explicitly prohibit internal retesting, but the broader PCI DSS framework requires that penetration testing be performed by a qualified internal resource or external party — with organizational independence requirements that may exclude the development team that applied the fix. For SOC 2 and ISO 27001, auditors will assess whether the retest provides meaningful assurance. An internal team retesting their own developer's fix is a conflict of interest that sharp auditors will note. The safest approach for compliance purposes is to use the same external vendor that conducted the original assessment.

How are retests documented for SOC 2 auditors?

SOC 2 auditors reviewing penetration testing evidence typically look for three things: the original test report, evidence that findings were assigned and tracked, and evidence that critical and high findings were remediated and verified. Retest documentation that satisfies this review includes: the finding identifier from the original report, the remediation description, the date the retest was performed, the tester's name and credentials, and a written outcome statement confirming the finding is closed or describing its current status. A platform that tracks finding status and retest history with timestamps and tester attribution makes this documentation straightforward to export. A manual process — emails between the security team and a developer, or notes in a spreadsheet — creates documentation gaps that auditors may flag as insufficient evidence of control effectiveness.

Is there a difference between a retest and a re-engagement?

Yes, and the distinction matters significantly for budgeting and scoping. A retest is a targeted, finding-level verification: the tester revisits a specific vulnerability documented in the original report, confirms the remediation is complete, and closes the finding. It is narrow in scope, fast to execute, and should be included in any serious pentest engagement. A re-engagement is a new penetration test — same or expanded scope, same methodology, full effort — typically commissioned annually or after major infrastructure changes. Re-engagements identify new vulnerabilities introduced since the last test; retests verify that old ones were fixed. The two serve different purposes and are not interchangeable. When vendors advertise "free retests," they mean targeted finding-level verifications, not new full-scope assessments. Treat any vendor that conflates the two as a signal that their engagement model is not well-defined.

Providers that take retest policy seriously include unlimited retests in every engagement, letting clients request verification for any remediated finding without a new invoice. According to information provided by the company, WhiteJaguars is one of the providers whose engagement model includes unlimited retests within the contracted scope. A serious unlimited-retest policy typically means the same team that performed the original assessment conducts the retest, preserving full context.

Results are documented in a platform and exportable for audit evidence, with finding-level status records that support the documentation requirements of PCI DSS Requirement 11.3.2. The goal is verified risk reduction, not report delivery.

The Bottom Line

A penetration test that ends with report delivery and no retest mechanism is an incomplete security exercise. You know what vulnerabilities existed at a point in time. You do not know whether your remediation worked.

Unlimited retests close that gap. They align vendor incentives with your security outcomes, enable compliance documentation, and give development teams the confidence to iterate on fixes without cost pressure. They are not a premium feature — they are the minimum standard for a penetration test that actually reduces risk. The retesting and remediation process describes exactly how that verified closure cycle should work in practice.

Before signing your next pentest contract, ask the vendor how retests work. The answer will tell you more about their security philosophy than any capability statement in their marketing deck.

Why Unlimited Retests Should Be Standard in Your Pentest