Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What is a penetration test retest?
Last verifiedA retest is targeted validation that agreed findings were remediated — not a second full pen test. PCI DSS 11.4 expects confirmation of fixes when PCI applies. Scope the window in the statement of work. This page is not legal advice.
Retest, last verified 10 September 2026 against NIST SP 800-115, PCI DSS v4.0.1 Requirement 11.4, and PTES. A retest is narrower than a re-engagement. This page does not start a remediation clock and does not determine that PCI applies to YOU. Not legal advice.
Retest versus re-engagement
Audience: an engineering lead proving closure to auditors and customers. This page is not legal advice. Kind of text: PCI DSS 11.4 is a program requirement only if PCI applies. NIST SP 800-115 and PTES discuss verification as methodology guidance. Industry best practice is a written remediation window and a scoped retest. ShipReady Metrics recommendation: track remediation in vuln management and attach retest confirmation as evidence — the product does not perform the independent retest.
Retest checklist
Walk this before you tell an auditor “it’s closed.” Last verified 10 September 2026. Not legal advice.
| Item | Pass looks like | Kind of text |
|---|---|---|
| Finding identity | Same ID, asset, and original evidence referenced. | Best practice. |
| Fix actually deployed | Production (or agreed environment) shows the change, not only a ticket. | Best practice. |
| Independent confirmation | The tester (or a named equivalent) repeats the exploit path and records fail-to-reproduce. | PCI 11.4 if PCI applies; otherwise best practice. |
| Residual risk | Accepted leftovers are signed, not silently dropped. | Best practice. |
| Scope boundary | Only agreed findings, unless a full re-engagement was bought. | Statement of work / NIST SP 800-115 planning. |
Remediation-window expectations
There is no single statute that sets “30 days to fix every high” for every company. PCI DSS 11.4 expects re-testing to confirm remediation; it does not, by itself, write YOUR internal SLA. Customer exhibits often name 30, 60, or 90 days. Write the window in the statement of work and in YOUR vulnerability policy. This page does not start that clock. Last verified 10 September 2026. Not legal advice.
What to do now
Operational steps. Last verified 10 September 2026. Not legal advice.
- Put retest days and the window in the purchase order, not in a handshake.
- Do not tell customers findings are closed until the retest record exists.
- Keep the original report, tickets, and retest letter together. Open the evidence-retention guide on this site.
- If you already have a session: signed-in app → Compliance → Evidence can hold the confirmation. Vulnerability ingest tracks ongoing issues. Neither is the independent retest.
Checklist
Question list. Not legal advice.
- Is this a scoped retest or a new full engagement?
- Which findings are in the retest scope?
- What environment will the tester hit?
- Who signs residual risk if a finding stays open?
Where this shows up in ShipReady Metrics
Vulnerability management tracks remediation. Evidence review and the met-verdict overlay record retest confirmation. The product does not replace the independent tester and does not start a clock.
Primary sources (last verified 10 September 2026)
NIST SP 800-115 (retesting after remediation). PCI DSS v4.0.1 Req. 11.4 (if PCI applies). PTES reporting / post-engagement practice. Not legal advice.