After a penetration test: from finding to verified fix

First understand what was demonstrated.

Discuss findings with the tester and the people responsible for the application or environment. Ask which steps demonstrate the weakness, what access is needed and which data or functions are affected. Also clarify what was not assessed.

Keep uncertainty visible. A suspicion, a reproducible issue and demonstrated access to data are different outcomes. Make sure the remediation work matches the evidence in the report.

Give every finding a next step.

Combine technical severity with your context: internet exposure, sensitive data, required permissions and existing controls. A severity score helps the discussion but does not replace that assessment. Name who decides priorities and accepts risk.

• Reference to the finding and affected system.
• Discussed risk, priority and decision owner.
• Proposed fix, implementer and agreed schedule.
• Acceptance criteria and how the fix will be checked.

Fix the cause and check side effects.

The change may involve code, configuration, infrastructure or permissions. Check whether the same issue exists elsewhere. If one function lacks access control, for example, review related functions too.

Check normal operation as well as security. A fix that blocks a necessary user action may need adjustment. Record temporary mitigations separately: they may reduce risk while the permanent change is being built.

Close with a scoped retest.

Agree which findings will be retested, against which version and in which environment. Keep the link to the original report. OWASP explains how a retest report can show earlier findings and their updated status.

Record what was fixed, what remains open and what could not be checked. A retest of known findings is not a complete new penetration test. Larger changes may need additional assessment.

PolderLabs can help implement technical changes and verify remediation. We agree who makes the changes, who reviews them and what evidence you receive.