Why a penetration test retest is part of the same engagement
A retest verifies that corrections work. It is not a repeat of the full penetration test, and it targets the specific findings that were fixed, along with the controls put in place to address them. Organizations commission retests when a framework, a customer or an insurer asks for evidence that findings were closed, and the request usually arrives after the report has been accepted and remediation is underway or complete. The tester's job is to confirm that each fix addresses the original risk, not to rerun everything from scratch.
The risks a retest addresses are predictable. A fix may be applied to the symptom the tester demonstrated but leave the underlying weakness in place, so the same category of flaw reappears on a neighboring endpoint. A patch or configuration change may break something else, or a later release may quietly reintroduce an earlier defect. Remediation may also be partial, with some affected hosts, accounts or code paths corrected and others forgotten. Before scheduling a retest, confirm with your tester which findings are in scope for verification, how fixes will be evidenced (for example, configuration output, code diffs or updated screenshots), and whether the retest is included in the original quote or priced separately.
Under PCI DSS requirement 11.4.4, exploitable vulnerabilities found in penetration testing must be corrected according to the entity's risk ranking, and the penetration test must be repeated to verify the corrections. The requirement does not prescribe the depth of the repeat, so agree the retest scope in writing and record which findings were verified and how. The PCI SSC's Penetration Testing Guidance also notes that remediation finished long after the original test may call for a new engagement rather than a retest, so set a target date for fixes early and track it against the original report.
How the retest fits the penetration testing phases
The retest is the last phase of the engagement, not a separate project. It closes the loop from planning through reporting by confirming, against the original findings, that fixes actually reduce the risk the tester reported.
Agree retest terms during planning
Planning is where the engagement is defined under NIST SP 800-115: rules are identified, management approval is finalized and documented, and testing goals are set. No testing occurs in this phase. The retest should be written into the same scope and rules of engagement, including which findings are in scope for revalidation, how many retest rounds are included, how the client submits evidence and the timing agreed for retest. Ask the provider to confirm these terms in writing before the first test begins, since retest timing is not something to leave for later.
Discover and attack within the approved scope
During discovery, the tester identifies targets and services. During the attack phase, the tester attempts to exploit weaknesses within the agreed rules, which is where the findings used later for retesting come from. Each finding should record enough detail to be reproduced, such as the affected asset, the conditions required and the evidence captured, so that someone can check it again later. The phase is complete when every in-scope target has been tested to the agreed depth and the tester has logged what was found.
Report findings with ranked severity
The reporting phase produces the findings document. PCI SSC guidance expects the report to explain how severity was derived, typically from a score such as CVSS, with traceable reasoning where the score was adjusted for the environment. Each finding should carry a remediation recommendation and a clear reference to the affected system. The phase closes when the client has received the report and the list of findings is agreed as the baseline for remediation and later validation. Our penetration test report page covers what a complete report contains.
Remediate according to risk ranking
The client owns remediation. Engineering teams fix or mitigate each finding, usually in the order set by the client's own risk ranking. PCI DSS requirement 11.4.4 expects exploitable vulnerabilities to be corrected on this basis. Remediation should be tracked in the client's own system, with each item linked to its original finding ID. The step is complete when the client records a fix, a compensating control or a documented risk acceptance for every finding, and sends that status to the tester with supporting evidence.
Validate fixes against the original findings
Once remediation is complete, the tester repeats the relevant tests against each original finding. PCI SSC guidance says the tester should retest after remediation to confirm that the new controls mitigate the original risk. This is not a new scan of the environment. The tester checks each finding individually, confirms whether it is closed, partially closed or still open, and notes any new issues the fix introduced. Where remediation has been delayed well beyond the original test, PCI SSC guidance indicates a new engagement may be needed instead.
Issue the retest report
The retest report lists every original finding with its status after revalidation, the evidence used to confirm each status and any residual risk that remains. It should reference the original report so an assessor can trace each closed item back to its source. The step is done when the client receives the document and the open or partially closed items are either assigned new remediation or formally accepted. Ask the provider to state the methodology used for the retest, since the retest should match the rigor of the original work.
What a retest can cover and what it cannot
A retest is only as useful as the scope written for it. Each decision below changes what the retester checks, what the closed-finding report can claim and whether the work still counts as a retest or has become a new test. Agree them in writing before remediation work is finished.
Which findings are retested
A retest should cover the findings that were exploitable and rated high risk first, then the remaining items in the agreed list. PCI DSS requirement 11.4.4 expects exploitable vulnerabilities to be corrected according to the entity's risk ranking and the test to be repeated to verify those corrections. Ask the provider to list each finding ID in the retest scope, so that any item left out is visible and the reason is recorded.
Environment changes since the original test
Ask whether the retest checks the system as it stands today or only the exact configuration that was tested. Patches, new releases, infrastructure moves and configuration edits made during remediation can reopen a closed issue or create a new one. The retest scope should say whether these changes are reviewed, and who confirms the version and configuration under test before work starts.
Reuse of original accounts and roles
Decide whether the retester uses the same test accounts and roles as the original engagement. Reuse keeps the comparison direct, but accounts may have been changed, disabled or rotated during remediation. Fresh accounts check the fix from a clean state. Record which accounts were used, with which permissions, in the retest report so the reader can judge whether a closed finding was tested under the same conditions.
Limits to the original targets
A retest normally covers the systems, endpoints and flows named in the original scope. Anything outside that list is a different question. If the team wants a neighboring application or a new segment checked, that belongs in a separate scope with its own rules of engagement. Confirm in writing that the retest will not expand beyond the original targets without a signed change.
New functionality and new code
Features added after the original test are not covered by a retest of old findings. Their exposure needs its own testing. Ask the provider to state clearly whether new functionality is excluded, and if the release is significant, plan a fresh test. Under PCI DSS requirements 11.4.2 and 11.4.3, penetration tests are repeated after significant changes, so a retest alone may not satisfy the requirement.
Significant change triggers a new test
When remediation involves architecture changes, a major platform upgrade or a new segmentation design, the original findings may no longer describe the system. PCI DSS requirements 11.4.2 and 11.4.3 call for penetration tests at least every 12 months and after significant changes. PCI SSC guidance also says remediation that finishes long after the original test may require a new engagement. Agree the threshold for that decision at scoping, not after the report arrives.
When to schedule the retest
When the development or platform team closes findings within days or a few weeks of the report, the original test is still fresh and the environment looks much as it did when the tester worked. In this situation a targeted retest usually answers the question that matters: does the new control mitigate the original risk? The tester re-checks each finding against the same scope, accounts and conditions used in the original work, so the comparison is like for like. Keep the fixes small and documented so the retester can follow each change.
- Same scope and accounts: Retest against the environment and roles used in the original engagement unless the scope has changed.
- Evidence of the fix: Provide change records, configuration diffs or release notes that map each fix to a finding ID.
- Partial closure: Ask whether a fix addresses the root cause or only the symptom the tester reproduced.
- Regression check: Confirm whether the retest also covers nearby functions touched by the fix.
- Report update: Ask for a retest report that lists each finding as closed, partially closed or still open.
Check that the retest is scheduled before the original report is considered final, so the fix window and the retest window do not drift apart.
Some findings cannot be closed inside your own configuration. A flaw may sit in a vendor release, a third-party library or a self-hosted open-source platform that needs an upgrade or a patch from its maintainers. In these cases the remediation timeline depends on the vendor, not your team, and the retest must wait until the new version is deployed. A retest can still be valid here, but only if the test is run against the deployed version and the report records the version under test. Interim compensating controls, such as access restrictions or network segmentation, should be retested too, because they carry the risk until the upgrade lands.
- Version under test: Record the exact product version, build or package hash at both the original test and the retest.
- Compensating controls: Ask the tester to verify interim controls and state that the underlying finding remains open.
- Vendor dependency: Track the vendor's fix date and the date your team deploys it as separate milestones.
- Risk acceptance: Document any accepted risk with an owner and review date, and confirm your risk ranking process allows it.
- Scope drift: Ask whether a major version change alters the attack surface enough to require new testing.
Confirm with your vendor what fix is available, and with your tester whether an upgrade counts as a retest or as a change that triggers new work.
When remediation drags on for months, the retest stops being a simple check. The environment has probably changed through releases, configuration updates and staff turnover, so the original findings may no longer describe the system in production. PCI SSC's guidance says that remediation extending long after the original test may require a new engagement rather than a retest. The longer the gap, the more likely the tester will need to rediscover the environment and assess whether new weaknesses have appeared. Ask the provider early how it would treat a delayed retest, because the answer affects both scope and cost.
- Environment drift: Compare the current architecture and asset list with the original scope before agreeing to a retest.
- Changed findings: Expect the tester to reassess whether the original severity still applies after the environment has shifted.
- New exposure: Ask whether releases since the original test have added internet-facing services or new accounts.
- Ownership: Confirm who owns each open finding and who signs off on closure.
- Standards clock: Check your framework's required testing interval, since a long gap can also create a compliance gap.
Before committing to a delayed retest, ask the tester in writing whether a new engagement is required and what the difference would be.
When fixes arrive inside a major release, the retest is tied to the release rather than to individual findings. A large release can change authentication flows, data paths, infrastructure and dependencies all at once, so verifying each fix in isolation may miss new weaknesses the release introduces. In this case the retest often works best as part of a wider test of the release, scoped around the changed components. PCI DSS treats significant changes as a trigger for penetration testing in their own right, so a major release may require testing regardless of the findings.
- Release scope: Map the release's changed components against the original findings and the scope.
- Significant change: Ask your assessor or compliance lead whether the release counts as a significant change under your framework.
- Timing: Schedule the test to cover the release build that goes to production, not an earlier candidate.
- Combined report: Ask whether the retest findings and new release findings will appear in one report with clear status for each.
- Environment parity: Confirm the test environment matches the production release configuration.
Before the release date is fixed, confirm with your assessor whether the release itself triggers testing and whether a targeted retest will still be accepted as evidence.
What the retest report documents for each finding
A retest report is only useful if each original finding can be traced from the first report to a documented outcome. The cards below cover the fields a buyer should expect for every finding, from the original reference to the statement of limitations. Read them alongside the original full report, not in place of it.
Original finding reference and severity
Each retest entry should quote the original finding identifier, title and severity exactly as it appeared in the first report. This keeps the two documents linked for your auditor. Severity should carry its reasoning forward: PCI SSC expects severity or risk rankings to be traceable, typically from CVSS, with clear reasoning wherever the score was adjusted for your environment. Check that the retest does not silently change the original rating.
Retest date and tester identity
The report should state when the retest was performed and who performed it, including the tester's name or role. An auditor will want the retest date to fall after the remediation date and within the window your compliance framework expects. A retest dated long after the original test may indicate that a new engagement is needed. Confirm that the tester is the same firm or an equivalent qualified team.
Validation method for each fix
For every finding, the report should describe in plain terms how the fix was checked: repeating the original test steps, reviewing configuration, or verifying a compensating control. Clients should be able to describe this method to an assessor without the tester present. A bare statement that a finding is fixed, with no method attached, is not enough to show that the new control mitigates the original risk.
Status with reasoning
Each finding should carry one status: closed, partially closed or still open. The reasoning matters more than the label. A partially closed finding should name what remains, such as one affected host or one vulnerable parameter, and a still open finding should state whether it has a planned fix date and an accepted risk owner. Ask the provider how it decides between partially closed and open.
Residual risk and new issues
A retest should record the residual risk left after each fix and any new issues the tester observed while retesting. Remediation changes can introduce fresh weaknesses, such as a new configuration exposure or a misapplied patch. New findings should be written up with the same fields as the original report, so they can enter your remediation tracking. Ask whether the retest covers only the original findings or includes a check of the changed components.
Statement of limitations
The retest report should restate what the retest did not cover, such as components not retested, test windows, access granted and any changes to scope since the original test. Without this statement, a closed status can be read as a broader assurance than the work supports. Confirm with the provider whether the retest report is accepted by your assessor, since acceptance depends on the framework and the assessor's own requirements.
When a long delay means a new penetration test is needed
A retest checks that fixes work within the scope of the original test, but a long gap between the test and remediation can change the environment enough that the earlier results no longer describe what is running. Once the environment has moved on, the question shifts from "were the findings fixed?" to "does the original test still describe our systems?" The PCI SSC guidance says remediation that extends long after the original test may require a new engagement, so the decision is not automatically a retest. Two fixed points help frame the decision. PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes, under requirements 11.4.2 and 11.4.3. If your last test is approaching twelve months old, a retest of a late fix may not satisfy that cycle. Separately, CIS Safeguard 18.2 expects an external penetration test at least annually and fails the assessment metric if more than twelve months have passed since the last external test. Check which of these frameworks applies to you, and map each to the date of your most recent full test, not the date of your last retest. Document the reason for any delay in writing, including the findings still open, the change that made them harder to fix, and the compensating controls you relied on in the meantime. Then ask your assessor, in writing, whether a retest of the original scope is sufficient or whether a new engagement is needed for the changed environment. Keep that reply with the report and retest records, since it is the evidence an auditor or customer will ask for when the gap is questioned.
What drives the cost of a retest
This table compares the factors that change the effort of a retest and explains how to keep each one under control. Read it before requesting a quote, because the cost of a retest stays well below a new full test mainly when the original scope, targets and environment are unchanged. Scope changes and large numbers of fixes move the effort toward a new engagement.
| Driver | Why it matters | How to scope efficiently |
|---|---|---|
| Number of findings retested | Each finding needs its own verification, evidence capture and status update, so more findings mean more tester time. | Group findings by target and root cause, and ask the provider to quote per finding or per group. |
| Severity and complexity of fixes | Architectural or multi-step fixes need deeper validation than a configuration change, and the tester may need to confirm the control defeats the original attack path. | Share the fix description and the change record before the retest so the tester can plan the validation method. |
| Fixes touching multiple targets | A single fix, such as a shared authentication component, can affect several applications or hosts, each of which must be checked. | Map each fix to the affected systems in advance, and list those systems in the retest scope. |
| Time since the original test | PCI SSC guidance says remediation that runs long after the original test may require a new engagement, so older findings can need re-baselining. | Record remediation dates for each finding and agree in writing when a retest would become a new test. |
| Significant environment changes | New versions, new hosts or new network paths can introduce risks the original test never covered, which expands the work beyond verification. | Provide a change log covering releases, infrastructure and configuration changes since the original report. |
| New functionality included in the retest | Testing new features is new discovery work, not verification, and is usually priced as additional scope. | Keep new features out of the retest scope unless they are quoted separately with their own targets and rules of engagement. |
| Testing knowledge level | PCI SSC notes that a black-box assessment may need more time, money and resources to meet PCI DSS deliverables, so the original approach affects retest effort. | Keep the original grey-box or white-box access and accounts for the retest so the tester does not rebuild context. |
How retests differ by environment
A retest of a web application or API usually re-checks each finding against the same endpoint, parameter, role and flow that the original test used, so the tester can confirm the weakness no longer behaves the same way. The change between the original and the fix is most often in application code, a framework or library upgrade, a validation or authorization rule, or a gateway policy. Payment and authentication flows deserve particular attention because a fix in one place can leave a second route to the same function open. Requirements such as PCI DSS 11.4.4 expect the corrected issue to be verified, not assumed, and the tester needs a build that contains the fix. See the web applications and APIs pillar for how these targets are tested in the first place.
- Build identity: Record the version, commit or build number that contains the fix, and confirm it is the version deployed to the environment under test.
- Same test accounts and roles: Provide the accounts and roles used originally, so authorization findings can be checked from the same privilege levels.
- Changed endpoints: Note any routes, schemas or API versions that were added or removed, so the tester can cover new surface created by the fix.
- Gateway and WAF rules: If a control was added in front of the application, state it clearly, since a retest should show whether the application itself is fixed or only shielded.
- Regression notes: Describe what else changed in the release, so the tester can judge whether nearby functions need a quick check.
Before the retest, confirm with the tester which build, accounts and environment will be used and that each closed finding has a matching change record.
In cloud and Kubernetes environments, many findings are configuration issues rather than code defects. A retest therefore re-checks the resource, policy, role binding or cluster setting that the original finding named, and it checks whether the change has taken effect in the running environment. Infrastructure-as-code repositories, admin consoles and cluster state can disagree, so the tester should compare the live configuration with the declared one. Changes are also easy to revert through automation, which is why a retest often looks at drift as well as the single fixed setting. Testing within each provider's published rules and the shared responsibility model remains important when the fix sits in a managed service. The cloud pillar covers how these environments are scoped and tested.
- Live state, not only code: Provide the running configuration, not just the pull request, so the tester can see what is actually deployed.
- Role and policy changes: List each IAM role, policy, service account or cluster role binding that was modified, with before and after values.
- Network and exposure changes: Note security group, ingress, network policy or public endpoint changes, since these can reopen paths.
- Admission and drift controls: Describe any policy engine or configuration monitoring that now blocks the original misconfiguration, and show its current status.
- Image and version evidence: For Kubernetes, record the image digests or chart versions that contain the fix, and the node or control plane version where relevant.
Confirm before the retest that the environment is in the state you expect, because a fix that was reverted or deployed to only one cluster will fail a fair retest.
Infrastructure and Active Directory findings often depend on how a system is patched, how identities are configured and how network paths are restricted. Retests therefore check the affected host or service, the identity setting or group membership involved, and the path that the original attack chain used. A patch on one server does not close an exposure that is also present on a second host or in a replicated domain object, so the tester should confirm scope against the original inventory. Changes to Active Directory can take time to replicate across domain controllers, and a retest that runs too early may show a stale result. Testing of external and internal networks, hybrid identity, wireless and remote access is covered in the infrastructure and Active Directory pillar.
- Patch level evidence: Record the patch or update identifier and the version now running on each affected system, including any that were excluded from the first fix.
- Identity changes: Document group membership, delegated permissions, password or Kerberos settings, and service account changes, with timestamps.
- Replication window: State when the change was made and confirm it has replicated to all domain controllers before the retest begins.
- Firewall and segmentation rules: Provide rule sets before and after, so the tester can confirm the path is closed rather than only the reported port.
- Compensating controls: Where a fix was not possible, describe the mitigation and its owner, since the retest will assess whether the original risk is actually reduced.
Confirm before the retest that every affected host and domain controller is in scope, and that the change window has passed replication and maintenance cycles.
Self-hosted platforms such as Keycloak, GitLab, Nextcloud, Odoo, Moodle, Drupal, Wazuh and Kubernetes combine a vendor codebase, a deployment configuration and the client's own customizations. A fix may come from an upstream release, a patch, a configuration change in the client's deployment or a plugin update, and each source has a different evidence trail. The retest should confirm which layer carries the fix and that the deployed version matches it. Where a finding relates to a project's own hardening guidance, the retest should be measured against that guidance as published by the project. The self-hosted open-source platforms pillar describes how these assessments are structured.
- Version and patch record: Note the platform version before and after the fix, and any upstream advisory the fix addresses.
- Configuration differences: Provide the deployment configuration files or settings that changed, such as values in
values.yamlor a platform's configuration file, with their history. - Customization and plugins: List custom modules, themes, extensions or scripts that were modified, since these often sit outside the vendor's patch path.
- Hardening guidance reference: Name the project guidance the finding was measured against, and record whether the fix follows it or departs from it with a documented reason.
- Backup before change: Keep a backup or snapshot taken before the fix, so the pre-fix state can be reproduced if a retest or an auditor asks how it was found.
Before the retest, confirm the deployed version and configuration against your change records, since a platform can run a fixed package with a legacy setting still in place.
What to prepare before the retest starts
Before a retest starts, the client's job is to make the fixes easy to find and verify. The most useful input is a remediation log that maps each original finding to the change that addresses it, with the ticket or pull request reference, the owner and the date the change reached the environment. Record the version or configuration that contains each fix, such as the application build, the firmware release, the gateway rule set or the infrastructure-as-code commit, along with the change dates. A tester who knows exactly which build to target spends less time confirming what changed and more time checking whether the original risk is gone. Findings that were accepted as risks, deferred or disputed should appear in the log too, with the reason, so the retest report can state them plainly.
Next, confirm access. The retest should run against the same test accounts and roles used in the original engagement, or against replacements with equivalent privileges, and the client should check that those accounts still work after the changes. Tell the tester about environment changes made since the original test, including new hosts, retired services, identity provider updates, network rule changes and any new integrations. Name one contact who can answer questions quickly during the retest, and agree how evidence will be shared. Ask the tester to confirm which findings they will retest and whether any fix needs a separate check. Where the retest touches production, agree a change freeze or testing window in advance so that deployments do not land mid-test and invalidate results.
Use the rules of engagement as the written reference for these terms. NIST SP 800-115 provides a rules of engagement template in Appendix B, and it is a practical checklist for recording the testing window, contacts, permitted activities, data handling, escalation steps for unexpected impact and the point at which testing stops. Agree on these items before any work begins and confirm that the people who approved the original test still authorize the retest, since the original approval may not cover changed systems or new accounts. A signed, dated set of terms protects both sides if a retest test activity triggers an alert or affects a service.
What to confirm about retest terms before signing
A retest only closes a finding if the terms around it are clear before work starts. The checks below cover price, rounds, format, people, timing and data, and each one decides whether the retest report will hold up with your assessor and your customers.
Included or priced separately
Confirm whether the quote covers a retest of the original findings or treats it as a separate line item. Some proposals fold one retest into the fixed fee, while others quote it after the report is delivered. Ask for the retest price in the same written quote as the original test, so budget and scope are agreed before remediation starts. Ask what happens to the price if new findings need validation during the retest.
Retest rounds covered
Ask how many retest rounds are included and what counts as a round. A round usually means one validation pass after a batch of fixes, but providers define it differently. Clarify whether a finding that remains open after a round triggers another round at no charge, and whether partial retests of individual findings are allowed. Without a stated limit, a long remediation cycle can become a series of unplanned billable visits.
Retest report format and assessor acceptance
Ask for a sample retest report before signing. It should list each original finding, its status (closed, open or partially addressed), the evidence used to verify the fix and the date of the retest. Confirm with your assessor or QSA whether they accept this format as evidence for requirement 11.4.4 or your framework's equivalent. A report the assessor rejects means the verification step must be repeated.
Who performs the retest
Confirm that the retest is performed by the same tester or team who wrote the original findings, or by a tester with equivalent experience on the same technology. The original tester knows the attack paths and the fix context, which speeds validation and reduces disputes. Ask whether the named individuals are employees or subcontractors, and whether the provider will name them in the retest report. Certifications such as OSCP or CREST accreditation indicate skill, but they do not establish experience with your environment, so ask about hands-on work with the same platform.
Time window to request a retest
Ask how long after the original report you can request a retest and whether the window is fixed or open-ended. PCI SSC's guidance says that remediation completed long after the original test may require a new engagement rather than a retest. Confirm the window in writing, along with the date the original test is considered complete, so you know when the retest must be booked. Also ask what changes to the system during remediation would require a fresh scope discussion.
Handling of data from the original test
Ask how the provider stores evidence, credentials, screenshots and test artifacts from the original engagement, and for how long. Confirm whether that data is available for the retest, when and how it is deleted, and whether the provider keeps any of it after the engagement ends. Check that the retest uses the same data handling terms as the original test. The PCI SSC qualification questions cover data handling for the tester, and they are a useful checklist for this conversation.
Questions buyers ask about retesting
Is a retest required by PCI DSS 11.4.4?
Yes, requirement 11.4.4 requires exploitable vulnerabilities found in penetration testing to be corrected according to the entity's risk ranking, and requires the penetration test to be repeated to verify the corrections. The requirement is about proving the fix worked, not just reporting that a ticket was closed. The PCI SSC's Penetration Testing Guidance adds that the tester should retest once remediation is complete to confirm that the new controls mitigate the original risk. Confirm with your QSA or acquiring bank how they expect that evidence to be packaged, because the retest report is usually what the assessor reviews.
How much does a retest cost compared with the original test?
A retest is normally priced from the written scope of the findings being verified, so its cost depends on how many findings are retested, how complex each fix is, and whether the environment has changed since the original test. Retests are usually smaller than the original engagement because the tester is confirming fixes rather than mapping the whole target, but they are not free and they are not a scan. DeployOpen does not publish a price list, so ask for a quote that lists each finding to be retested, the environments involved, the reporting format and whether any findings will be re-exploited or only reviewed. Ask whether the quote is one-time or part of a retainer.
How long after the original test can a retest happen?
The retest should happen once remediation is complete, not on a fixed calendar date. PCI SSC guidance says that remediation extending long after the original test may require a new engagement rather than a retest, because the environment being tested is no longer the one that was assessed. Plan the retest window when fixes are scheduled, and leave room for a test environment or a production change window that the tester can access. Agree the window in the written scope so the retest does not drift past the point where the original test still represents the target.
What do we need to prepare before a retest starts?
Before the retest, you need to provide a list of the findings you claim are fixed, the change records or patch details for each one, and access to the same test accounts and environments used in the original engagement. Include any compensating controls you put in place where a direct fix was not possible, because the tester needs to judge whether those controls mitigate the original risk. Confirm the testing window, named contacts and any change freeze with the tester in advance. Ask the provider what evidence format they require so that remediation records are complete before the work starts.
Can our own team run the retest?
Your team can verify fixes internally, and many organizations do so for low-risk items, but the retest that supports a compliance submission or a customer review should be performed by a party independent of the remediation work. Internal verification is useful for tracking progress, while an independent retest produces the evidence an assessor or customer will accept. If your team retests, document the method, the findings checked, the results and who performed the check, and be prepared for the assessor to ask for a formal report. Agree in advance which outcome your auditor will accept.
When do we need a full new test instead of a retest?
A full new test is needed when the environment has changed enough that the original findings no longer describe it, or when a long gap has passed since the original engagement. PCI DSS requires internal and external penetration tests at least every 12 months and after significant changes, so a major architecture change, a new internet-facing service or a large remediation program may trigger a new test rather than a retest. CIS Safeguard 18.2 also fails if more than twelve months pass since the last external test. Ask your provider to state in the scope which changes would move the work from a retest to a new engagement.
Primary sources on retesting and penetration testing
Start with the PCI SSC Penetration Testing Guidance v1.1 if your retest is driven by PCI DSS. It is the most direct read on how a tester should validate remediation: the guidance says the tester should retest once fixes are complete to confirm that new controls mitigate the original risk, and that remediation completed long after the original test may call for a new engagement rather than a retest. Pair it with the PCI DSS v4.0 SAQ D for Service Providers document from the same body, which sets out the requirement set that drives retesting. Requirement 11.4.4 expects exploitable vulnerabilities to be corrected according to your risk ranking and the penetration test to be repeated to verify those corrections. Confirm with your assessor exactly which requirement versions and self-assessment forms apply to your environment before you agree a retest window.
Read NIST SP 800-115 for the general process behind a retest. Its planning phase covers rules of engagement, documented management approval and testing goals, and those same documents should define what a retest may touch and who authorizes it. NIST does not endorse one methodology over another, so check that your provider's retest method is written down and matches the original test. The PDF version of the same publication is available from NIST if your procurement team needs a copy for the file.
If your retest question comes from a CIS Controls assessment, read the CIS Controls Assessment Specification for Control 18. It shows how external and internal penetration tests are assessed, and it makes clear that an external test older than twelve months can fail the metric, which bears directly on when a fresh test is needed rather than a retest. For application findings, read OWASP ASVS 5.0.0 on the OWASP GitHub repository. It says certifying organizations should disclose their testing methods in the report and that running an automated tool alone is not enough, so ask your provider to show how each retested finding was verified by hand.
How DeployOpen scopes, tests, reports and retests
DeployOpen treats the retest as part of the original engagement, not an afterthought. We agree in writing which findings will be retested, how fixes will be evidenced and when a new test is needed instead, so the closure record is clear before work starts.
How we scope
- Engagements are fixed-scope, so the retest window, included findings and deliverables are written into the agreement before testing begins.
- We confirm which findings are in retest scope, such as exploitable issues, and which are accepted risks that will not be retested.
- We agree how remediation evidence will be shared, for example configuration exports, code references or change records, before the retest starts.
How we build
- We plan the retest against the original findings and the environment as it stands after changes, so each fix is checked where it was found.
- Retest work repeats the original test steps for each finding, then confirms whether the new control reduces the original risk.
- Where fixes changed the architecture or a new feature shipped, we flag that the original test may no longer describe the system.
How we hand over
- The retest report lists each original finding with its status, such as closed, partially closed or still open, and the evidence behind that status.
- Findings that remain open are restated with the reasoning and the remaining risk, so your risk owner can make a decision.
- Ask for the report format in advance, and confirm whether your auditor needs the original report, the retest report or both.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for teams that need retests on a regular rhythm.
- Ask us to confirm in writing how long after the original test a retest remains part of the same engagement.
- If remediation runs long or the system changes significantly, we will advise whether a new engagement is the better fit.
