Penetration test remediation: what counts as closed?

Prioritise by the reachable business operation

A command-execution flaw and a payment-authorisation defect can combine into one attack chain. Explain the chain without collapsing all findings into one owner. Set immediate containment around the reachable operation and assign durable fixes to the teams that control the underlying causes.

Define closure before implementing the change

Write the expected negative and positive test results. For a payment role, that might mean a forbidden beneficiary update fails while an authorised workflow still works. State the identity, object and environment so the acceptance test can be repeated after deployment.

Distinguish replay from retest

Replaying an attack with defenders can improve detection and understanding. It does not automatically prove the original vulnerability was repaired. Keep remediation validation, detection exercises and operational recovery checks as separate records with their own evidence and dates.

Make unresolved risk visible

Record an owner, deadline and interim safeguard for every open item. If a fix needs a supplier release or architecture change, describe that dependency. Management should see which paths remain possible and which controls currently limit them, rather than only a percentage marked complete.

Write acceptance criteria before choosing the fix

Translate the finding into a behaviour that can be observed. For a cross-customer document issue, specify that an unentitled test principal must not retrieve the designated foreign canary document through the affected operation, while the legitimate owner retains access. Identify adjacent interfaces that belong in the retest. This gives engineers room to choose the implementation while preserving the security outcome. “Patch applied” and “ticket completed” describe work, not the resulting control.

Include the service version, environment and test identity in the acceptance record. If a different environment is used for retesting, state the equivalence assumptions and any production validation still required by the owner.

Separate containment from durable treatment

An emergency deny rule, disabled account or temporarily removed feature may reduce exposure before the underlying issue is corrected. Record the interim control, its owner, expiry and operational cost. Do not hide these arrangements inside a closed finding. A durable treatment may need application changes, identity-policy updates and operational review across several teams. Keep the relationship between those actions visible so one completed task is not mistaken for completion of the whole path.

The fintech release retesting guide offers a useful structure for preserving evidence as releases change. A finding that was fixed in one build needs an intelligible relationship to the build the organisation actually deploys.

Give residual risk an explicit decision

When a path remains untested or a fix is deferred, identify the reason, affected service and accountable risk owner. State what compensating evidence exists and what it does not establish. Retesting may reveal a narrower exposure or a different route; explain that change rather than forcing every result into pass or fail. The final record should allow another reviewer to reconstruct what was observed and why the closure decision was reasonable at that time.

For advanced exercises, the DORA TLPT reporting and remediation guide places these technical decisions within a wider closure process. Preserve that distinction: a routine pentest retest does not replace the reporting, coordination and remediation arrangements of a TLPT.

Put the guidance to work

Use the readiness checklist to document assumptions, or inspect the fictional Meridian Group AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.