Pentest retest: what it is, why auditors expect it and how often to test

The problem: the report shipped, the fix "was done", and nobody proved it

A pentest ends with a list of weaknesses. The real value comes afterwards: the team fixes them, and someone has to prove the fix works. That is what a retest does. Without one, you hold a report saying "there was a problem" and no evidence that it went away.

Picture what happens in practice. The report arrives with twelve findings. The team opens twelve tickets, closes eleven over two sprints and leaves one "for later". Six months on, the auditor asks: "what is the status of those findings?" The honest answer is "we believe they were fixed". To an auditor, belief is not evidence.

Auditors, QSAs and risk teams know this. That is why the retest shows up as its own line in compliance conversations, and why so many reports are found incomplete at exactly this point. This guide covers what a retest is, what it must deliver, which fixes tend to fail, how often to test, and what to ask a vendor before you sign.

What a retest is

A retest is a targeted repeat of the tests behind each finding, run after the team has applied the fix. The pentester reproduces the same attack under the same conditions and records whether it still works.

It is not a new pentest. Scope is closed to the findings already reported: it does not hunt for new vulnerabilities, does not cover features that changed afterwards, and does not replace the annual test. That boundary helps both sides: the client knows exactly what it is paying for, and the vendor knows exactly what it has to prove.

	Pentest	Retest
Goal	Discover what is exploitable	Confirm that what was found has been fixed
Scope	Full application, network or environment	Only the findings of the previous report
Output	List of findings with evidence	Status per finding with new evidence
Typical effort	Days or weeks, depending on scope	A fraction of the original test, proportional to the number of findings
When	Annually and after significant change	After remediation, in an agreed window

The life cycle of a finding

A retest only makes sense inside a cycle. Every finding goes through the same stages, and each stage leaves a record an auditor can follow:

Stage	What happens	Record left behind
1. Discovery	The pentester exploits the flaw and documents the evidence	Finding in the report, with severity and reproduction steps
2. Triage	The team assigns an owner, a deadline and an approach	Ticket linked to the finding ID
3. Fix	Code, configuration or process is changed	Commit, pull request or change request
4. Retest	The pentester repeats the original attack in production	New request, response or log
5. Status	The finding is closed, reopened or accepted as risk	Updated report with status and date

If any stage is missing, the cycle breaks. The most common failure is jumping from stage 3 straight to closing the ticket, skipping stage 4: the flaw disappears from the backlog, but nobody checked the environment.

Why auditors and regulators expect a retest

In PCI DSS 4.0, requirement 11.4 treats pentesting as a cycle, not an event: exploitable vulnerabilities found must be corrected and the testing repeated to verify the correction. See how this fits the report in Pentesting for PCI DSS 4.0.

In the Brazilian financial sector, Central Bank rules expect the institution to act on what testing finds and to be able to show that treatment to supervisors. A documented retest is the most direct proof. Check the current text of the resolutions that apply to your type of institution before building your evidence package.

The logic is the same for ISO 27001 and SOC 2: the auditor does not only want to know you tested, but that vulnerability management closed the loop. It also applies to an enterprise customer’s security questionnaire: "did you fix what the pentest found?" is a question a retest answers with a document, not a promise.

What a retest report shows

A good retest returns, for each original finding:

1. Original identifier and severity, so it traces back to the earlier report.
2. Status: fixed, partially fixed, not fixed or risk accepted (the last one with a written justification and formal sign-off from the company).
3. New evidence: the request and response, screenshot or log showing the original attack now fails (or still works).
4. Date and tester, for the audit trail.
5. New issues introduced by the fix, when evident, recorded separately.

A retest that merely says "all issues were fixed" is not evidence. The reader needs to see what was attempted. The table below summarises what each status needs in order to be accepted by an auditor:

Status	Meaning	Evidence required
Fixed	The original attack and reasonable variations fail	Request and response showing the attack failing, date and environment tested
Partially fixed	The original vector fails, but a variation or instance still works	Evidence of what now fails and of what remains exploitable
Not fixed	The original attack still works	Evidence of the repeated exploitation and current impact
Risk accepted	The company decided to live with the flaw	Justification, compensating control, formal approval and review date
Not applicable	The component was disabled or removed	Proof of removal, not just dropping the finding from scope

When to retest

The best moment is right after the team marks fixes as deployed to production (or the equivalent environment). Retesting in staging can be a useful pre-check, but only verification in the real environment proves the final outcome.

Agree on a window with your vendor: for example, retest requests accepted for a period after the report is delivered. Ask this at contracting time. A window that is too short forces rushed fixes; no window at all turns the retest into a new quote.

Two scheduling tips help a lot. First, batch the fixes instead of requesting a retest per finding: the vendor works more efficiently and you go through fewer rounds. Second, work backwards from your audit or supervision deadline: if the updated final report has to be ready by March, the remediation window ends well before that.

Common mistakes when fixing

These are the patterns that most often bring a finding back as "not fixed":

• Fixing the symptom, not the cause. Blocking the test payload instead of fixing the validation. The pentester changes one character and the flaw is back.
• Relying on a WAF alone. A WAF rule lowers immediate risk but does not remove the vulnerability from the application. It counts as a temporary mitigation and should be recorded as one.
• Validating on the client only. Hiding a button or checking a field in the browser does not stop anyone who calls the API directly. The rule has to exist on the server.
• Fixing one instance and missing the class. The same authorization flaw on five endpoints, fixed on one. Broken object-level authorization in APIs is the classic example: the right fix is a central control, not five patches.
• Introducing a regression. The fix breaks another protection, or a later release brings the flaw back. An automated test for the fixed case keeps the finding from returning.
• Changing scope to make the finding disappear. Removing a system from the report is not a fix, and the auditor will spot it from the network diagram.
• Fixing without recording it. Without a ticket, commit or changelog, the team cannot explain what changed.

How often should you pentest

The market norm, and what PCI DSS and most auditors expect, is at least once a year and after any significant change: a new critical feature, a cloud migration, a change of authentication provider, a third-party integration, an architecture change. For Central Bank-regulated institutions in Brazil, the minimum frequency comes from the applicable rule; confirm the current text and treat annual as a floor, not a ceiling.

If you sell to enterprise customers, the report has to be recent. A 2023 pentest presented in 2026 after two migrations is usually rejected.

A risk-based cadence tends to work better than a fixed date on the calendar:

Situation	Suggested cadence
Baseline	Full annual pentest, with a retest after fixes
Significant change (authentication, payments, data exposure, new architecture)	Focused test on the change, before or right after launch
High-risk assets (public APIs, cardholder environment, sensitive data)	Shorter cycles, set by the company’s risk analysis
Between tests	Continuous scanning and automated tests in CI to catch regressions

Automated tooling in the pipeline complements the pentest but does not replace it. It finds known classes of flaws quickly; manual testing finds business-logic flaws and chained attacks no scanner sees. The difference is covered in Scanner, pentest or bug bounty.

What to ask your vendor

Before signing, get these answers in writing:

• Is the retest included in the price or billed separately?
• How many retest rounds are included? One is usually enough if fixes are done well; two give real margin.
• What is the window to request the retest, and what happens after it closes?
• Is the final report updated with each finding’s status, or is the retest a separate document?
• Is the retest done in production, with new evidence for each finding?
• Who runs it: the same team as the original test?
• How are findings that the fix left partly open handled?

What drives the cost of a retest is usually the number of findings, how hard each one is to reproduce and the number of rounds, not a universal fixed amount. That is why it pays to get the policy in writing rather than compare only the price of the initial test. More questions for comparing proposals are in 10 questions to ask before hiring a pentest, and how retesting affects price is covered in How much does a penetration test cost.

How Pentest Machine handles retesting

The retest is included in our packages. Each finding comes back with a status and fresh evidence, and the final report is updated to reflect the post-fix state. If your audit or supervision is on the calendar, the best moment to agree scope and retest window is before testing starts. Request a quote and tell us your compliance deadline.

Frequently asked questions

Is a retest the same as a new pentest?

No. A retest verifies only the findings already reported, using the same method. A new pentest looks for new weaknesses across the whole scope. They complement each other: the pentest discovers, the retest proves the fix.

How long after the fix should I retest?

As soon as fixes are in production. Agree a request window with the vendor so you do not miss the deadline, and batch fixes to reduce the number of rounds.

How many retest rounds do I need?

It depends on the number of findings and the quality of the fixes. Ask how many rounds are included and what happens if a fix fails. One round is usually enough for well-made fixes; a second gives room for adjustments.

Is a WAF enough to consider a finding fixed?

Usually not. The WAF mitigates, but the vulnerability remains in the application. The report should record it as mitigation, not correction, and the finding stays open until the cause is addressed.

Can my internal team do the retest?

It can, as a pre-check. For audit and compliance, though, what counts is a retest run by whoever did the original test or by an independent third party, with documented evidence. The people who fixed the flaw should not be the only ones validating it.

What happens to a finding the company decides not to fix?

It becomes accepted risk, with a justification, a compensating control, formal management approval and a review date. The retest records that status instead of pretending the finding was resolved.

How often should I run a pentest?

At least once a year and after significant changes to the application or infrastructure, with a retest after each round of fixes. Regulated environments should confirm the frequency in the applicable rule.