Penetration Testing Remediation and Retesting: What Happens After Your Report

Penetration testing remediation is the work of fixing the vulnerabilities a test uncovered. Retesting is what proves those fixes actually hold. Skip the second half and you’re left with a report full of ticked boxes that nobody has verified. Do both properly and a pen test stops being a compliance exercise. It becomes evidence that your defences work.

Most organisations understand the first half. A report lands. Findings get assigned to whoever owns the affected system. Patches or config changes go out. The second half gets skipped far more often: retesting the same vulnerabilities to confirm the fix closes the gap, rather than just moving it somewhere else.

What does penetration testing remediation actually involve?

Remediation is any corrective action taken in response to a finding in the pen test report. That covers a wide range of work. It might mean applying a vendor patch, tightening a misconfigured firewall rule, or revoking excess account permissions. It might mean rewriting a piece of vulnerable code, or adding input validation to a form that accepted anything a tester threw at it.

A good report separates this work by severity. It gives enough technical detail that an engineer can act without needing the tester on a call. If your reports don’t do that, penetration testing remediation stalls before it starts. Nobody is quite sure what “fix the SQL injection on the login form” is supposed to look like in practice.

How should you prioritise what to fix first?

The UK’s National Cyber Security Centre is clear on this. A severity score on its own is not enough to decide what gets fixed first. As its vulnerability triage guidance puts it, “it’s essential that you consider business impact and risk for your organisation” rather than treating a CVSS number as the final word.

In practice, that means sorting findings into three buckets: fix now, acknowledge and schedule, or investigate further before deciding. Internet-facing systems jump the queue, along with anything touching critical infrastructure. A critical finding on an internal test server, one nobody outside the network can reach, is not the same urgency as an identical finding on a public login page.

A workable rhythm for most small and mid-sized businesses looks like this. Close anything critical or high within a matter of weeks. Deal with medium findings within a couple of months. Fold lower-severity items into your normal patch cycle rather than treating them as a fire drill.

What is retesting, and why bother?

Retesting means the tester goes back and attempts the exact attack that worked the first time. If the SQL injection no longer returns data, the finding is closed. An outdated application patched to a safe version closes the same way, as does an exposed admin panel that now demands authentication before letting anyone in. When none of that has happened, you find out before an attacker does, rather than after.

This matters because a fix that looks right on paper doesn’t always hold up under actual testing. A patch might land on one server in a cluster but miss another. A firewall rule might block the specific payload used in testing while a near-identical variant slips through. Auditors and regulators who ask for evidence of penetration testing remediation usually want that evidence to come from someone other than the person who applied the fix. A developer confirming their own patch works is a weaker guarantee than an independent retest.

How soon after remediation should you retest?

There’s no single legal deadline. Most UK providers build one retest into the original engagement, usually within 30 to 90 days of the report. Anything still open when that window closes typically needs a new round of testing, often at extra cost, because the environment has moved on since the original scope was agreed.

Waiting too long has a cost beyond the invoice. Our own guide on penetration test frequency covers why annual testing is a floor, not a strategy. The same logic applies here. The longer a known vulnerability sits open, the longer the window an attacker has to find it too, whether through their own scanning or because the flaw turns up in a public vendor advisory.

Does compliance require a retest?

Some frameworks say so explicitly. PCI DSS Requirement 11.3.1 states plainly that vulnerabilities found during a penetration test “should be corrected, and tests should be repeated to verify the corrections,” according to the official PCI DSS Requirement 11 guidance. If your business handles card payments, this isn’t optional. Our PCI DSS penetration testing checklist sets out exactly what Requirement 11 obliges you to buy.

ISO 27001 and Cyber Essentials Plus are less strict about a formal retest. Assessors still want to see that flagged risks were actually closed, not just logged. A retest is the cleanest way to prove that. It also saves you explaining to an auditor why a finding from six months ago is still open.

Who should carry out the retest?

Ideally, the same tester who found the issue. They already know the exact conditions that triggered it. They can also spot a partial fix that a fresh pair of eyes might accept at face value. For higher-stakes audits, some organisations ask for an outside reviewer instead. That removes any doubt that the original tester is just confirming their own work. A well-written report, of the kind our guide to what a good penetration test report looks like describes, makes either approach easy. The evidence trail is clear enough for anyone to follow.

What does a retest cost?

Many UK providers, including Aardwolf Security, include one retest of critical and high findings within the price of a standard penetration testing engagement, provided it happens within a set window after the report. Retests requested well outside that window, or a second retest after the first one still finds issues, are usually billed separately. That extra cost is often a fraction of the original price, since the scope is narrower.

If you’re planning a testing programme, ask your provider directly during scoping how penetration testing remediation and retesting fit into the overall cost and timeline. Don’t just assume it’s automatically included.

What happens if you skip retesting?

The most common outcome is simple. A finding you believed was closed reappears in next year’s test, sometimes with a note that it was reported previously and never actually fixed. That’s an awkward line for a board or an auditor to read. It also undermines confidence in every other “fixed” item on the list. Skipping the retest doesn’t save time in the long run. It just moves the discovery of an unresolved problem to a worse moment.

Frequently asked questions

Do all findings need a retest? Focus retesting on critical and high-severity findings first. Low-severity issues can often be checked at the next scheduled test instead of a dedicated retest, depending on your risk appetite.

Can we retest internally instead of using the original tester? You can run your own verification scans. But for compliance purposes, an independent retest from the original testing provider, or another qualified third party, carries more weight than an internal check.

How long should penetration testing remediation itself take? There’s no fixed rule. Many organisations target two to four weeks for critical and high findings, then fold medium and low findings into normal patch cycles over the following months.

Does a retest count as our annual penetration test? No. A retest only re-examines the specific findings from the previous report. It isn’t a substitute for the broader annual or post-change testing your compliance framework requires.

What if we can’t fix everything before the retest window closes? Talk to your provider before the window expires. Most will retest what’s ready and note what’s still outstanding, rather than forcing an all-or-nothing retest.

If you’re weighing up penetration testing remediation timelines for a recent report, or need a retest scoped properly, Aardwolf Security’s team can talk it through. Get in touch and we’ll tell you plainly what needs doing first.