Scope and fit
A retest narrows the question: did the changed control address the reported issue under the tested conditions? It does not replace ongoing security testing.
Carry forward the original conditions
Keep the finding identifier, affected version, reproduction steps, and original impact. Confirm that the system tested is the same deployment or code path that was changed.
Verify the fix and nearby behavior
Re-run the agreed test and check for regressions or a closely related bypass. If architecture changed, expand scope only with explicit authorization.
Report the limits clearly
State which findings were retested, which were not, and what evidence supports the result. A closed item means the observed issue was addressed in the tested context, not that the application is vulnerability-free.
Decisions and tradeoffs
Use this table as a working review record. Replace assumptions with evidence from the target environment.
| Decision area | Working guidance |
|---|---|
| Carry forward the original conditions | Keep the finding identifier, affected version, reproduction steps, and original impact. Confirm that the system tested is the same deployment or code path that was changed. |
| Verify the fix and nearby behavior | Re-run the agreed test and check for regressions or a closely related bypass. If architecture changed, expand scope only with explicit authorization. |
| Report the limits clearly | State which findings were retested, which were not, and what evidence supports the result. A closed item means the observed issue was addressed in the tested context, not that the application is vulnerability-free. |
Implementation questions
What should the team decide about carry forward the original conditions?
Keep the finding identifier, affected version, reproduction steps, and original impact. Confirm that the system tested is the same deployment or code path that was changed. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about verify the fix and nearby behavior?
Re-run the agreed test and check for regressions or a closely related bypass. If architecture changed, expand scope only with explicit authorization. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
What should the team decide about report the limits clearly?
State which findings were retested, which were not, and what evidence supports the result. A closed item means the observed issue was addressed in the tested context, not that the application is vulnerability-free. Use a named owner and a written acceptance check so this decision can be reviewed after deployment.
Plan, build, verify, operate
Carry forward the original conditions: Keep the finding identifier, affected version, reproduction steps, and original impact. Confirm that the system tested is the same deployment or code path that was changed. Record the result and the next owner before changing the next boundary.
Verify the fix and nearby behavior: Re-run the agreed test and check for regressions or a closely related bypass. If architecture changed, expand scope only with explicit authorization. Record the result and the next owner before changing the next boundary.
Report the limits clearly: State which findings were retested, which were not, and what evidence supports the result. A closed item means the observed issue was addressed in the tested context, not that the application is vulnerability-free. Record the result and the next owner before changing the next boundary.
Deployment checks
Turn the page into a reviewable handover by assigning each check to a person and retaining its result.
What a Penetration-Test Retest Can and Cannot Confirm: decision 1
Write down the boundary, owner, dependency, and proof required for what a penetration-test retest can and cannot confirm before implementation begins.
What a Penetration-Test Retest Can and Cannot Confirm: decision 2
Write down the boundary, owner, dependency, and proof required for what a penetration-test retest can and cannot confirm before implementation begins.
What a Penetration-Test Retest Can and Cannot Confirm: decision 3
Write down the boundary, owner, dependency, and proof required for what a penetration-test retest can and cannot confirm before implementation begins.
Retest the fix and its boundaries
A retest verifies whether a stated remediation addresses the previously reported condition in the agreed environment. Provide the finding reference, affected version or asset, change summary, deployment date, test window, access path, and any constraints. A code change may fix one path while leaving an alternate API, legacy host, cached permission, or configuration boundary unchanged.
Confirm the original proof no longer works using the least disruptive method, then test relevant regression paths. Record the result as resolved, partially resolved, unable to verify, or still present with evidence and scope limits. Do not mark a finding closed solely because a ticket says a fix was deployed.
The customer owns remediation and risk acceptance. DeployOpen can retest the written scope; a retest does not replace broader regression testing or a new assessment after material change.
Handover and ownership
Before handover, name the system owner, support path, access boundary, backup or recovery responsibility, and the condition that pauses a change.
Keep a short record of what was tested, what remains outside scope, and when the review should happen again.
