From Report to Resolved: Remediation and Retesting After a Pentest

The day a penetration test report arrives, risk has not gone down at all. It has only been described. Risk falls when findings are fixed, and you only know they are fixed when someone checks. Many organisations spend weeks preparing for a test and very little time planning what happens afterwards. This guide sets out a process that gets you from report to clean retest without drama.

Step one: debrief and triage

Book a debrief call with the testers within a few days of receiving the report. Bring the engineers who will fix things, not just the security lead. Ask testers to walk through the highest-severity findings and any attack chains, and to explain anything in the report that is unclear.

Then triage. For each finding, decide:

• Is it valid in our environment? Occasionally a finding depends on a condition that does not apply in production.
• Who owns the affected system or code?
• What is the right fix, and is there a quick interim mitigation?
• Does it appear elsewhere? A missing check in one endpoint often means the same gap in its neighbours.

If you disagree with a severity rating, raise it during the debrief. Our CVSS v4.0 guide explains how scores are built and how environmental context can change them.

Step two: set owners and deadlines

Every finding needs one named owner and a target date. Put findings into the same ticketing system your engineers already use, so security work competes fairly with feature work rather than living in a forgotten spreadsheet.

These timings are examples. Set your own in policy, and check whether your regulator, customers or a framework such as PCI DSS expects specific timelines.

Step three: fix the cause, not the instance

Testers work under time limits, so a report shows examples, not always every occurrence. If an authorisation check is missing on one API endpoint, review every endpoint built the same way. If one service account has a weak password, review them all.

Good remediation usually means one of three things:

1. A shared control. Move the check into middleware, a framework setting or a central policy so new code inherits it.
2. A configuration standard. Fix the template, baseline or infrastructure-as-code module so new systems start secure.
3. A guardrail. Add a test, linter rule or cloud policy that stops the issue returning.

Ask testers for advice if the right fix is unclear. A short question before you build a fix is cheaper than a failed retest.

Step four: verify internally first

Before booking a retest, have the engineer or a colleague confirm the fix in the same environment the testers used. Use the reproduction steps in the report. Check that the fix is deployed, not just merged. Many failed retests happen because a fix sits in a branch that never reached the tested environment.

Step five: the retest

A retest checks whether specific findings are now closed. It is usually short, often one or two tester-days, because testers already know the system.

What a good retest covers

• Every finding you mark as fixed, retested using the original method
• Reasonable checks around each fix, to make sure it cannot be bypassed with a small variation
• A clear status for each finding: closed, partially fixed or still open

What a retest does not cover

A retest is not a new penetration test. Features added since the original test are not covered. If significant new functionality has shipped, scope a fresh test alongside the retest. Our guide on testing frequency explains how to plan for that.

Timing

Bundle fixes into a single retest window where possible. Retesting one finding at a time costs more coordination than it saves. Many providers include one retest within a set window; check yours in the proposal.

Why retests fail

The most common reasons are predictable: the fix was never deployed to the tested environment, the fix covered one example but not its siblings, input filtering was added where a proper control was needed, or a configuration change was reverted by an automated deployment. Internal verification catches most of these before the testers arrive.

Accepting risk properly

Sometimes the right decision is not to fix something now. A legacy system may be months from retirement, or the fix may break a critical integration. That is acceptable if it is a real decision rather than neglect. Record:

• The finding and its severity
• The reason for accepting the risk
• Any compensating controls in place
• Who approved the decision, with appropriate authority
• A review date

Auditors and customers are usually comfortable with documented, time-limited risk acceptance. They are far less comfortable with findings that stay open without explanation.

Evidence for auditors and customers

Keep the original report, the retest report or letter, ticket references and any risk acceptances together. Together they show not just that you tested, but that you acted on the results. That is what most compliance frameworks are really asking for.

Track two metrics over time: the number of findings by severity, and the average time to close them. Falling time to close is often a better sign of maturity than a falling finding count.

If you are planning the full calendar, our article on how long a penetration test takes shows where remediation and retesting fit.

Frequently asked questions

Need fixes verified? See our retest and remediation validation service or request a quote. PentestProviders proposals include a free retest of fixed findings.