Penetration Test Remediation: What to Do When the Report Arrives

Penetration test remediation means working through the findings in a test report until each one is fixed, mitigated or formally accepted, then proving it with a retest. Start with the executive summary and critical findings, check for signs of real compromise, prioritise by real-world risk rather than score alone, give every finding an owner and a date, and book the retest before the work starts.

This guide covers that process, including what to do when a test has gone badly and you need to recover quickly, and gives you a free remediation tracker template to manage pen test remediation from report to retest.

Key takeaways

• A “failed” test is a list of problems found before an attacker found them. Respond calmly and quickly.
• Check critical findings for signs of real compromise, not just the vulnerability.
• Prioritise by exploitability, exposure and asset value, not the severity score alone. This is the core idea behind continuous threat exposure management (CTEM).
• Every finding needs an owner, a decision (fix, mitigate or accept) and a date.
• Retesting proves a fix works, and PCI DSS requires it.

What should you do first after a penetration test?

Read the executive summary and the critical findings, then check whether anyone else got there first. If the tester found an easily exploitable, internet-facing flaw, review the logs for the affected systems and escalate to incident response if anything looks wrong. Then:

1. Contain the worst issues immediately. Restrict access, disable a vulnerable service or take a system offline if the risk justifies it, while a permanent fix is prepared.
2. Do not look for someone to blame. Findings usually come from process gaps, and blame slows the fix.
3. Tell the people who need to know. Senior management, your QSA if PCI DSS is involved, and customers or insurers if a contract requires it.
4. Agree a remediation plan and a retest date. A credible, dated plan often satisfies a customer or assessor while the work is done.

How do you triage the findings?

Understand the ratings. Most reports use the Common Vulnerability Scoring System (CVSS), often with the tester’s adjustment for context. CVSS v4.0 separates base, threat and environmental metrics, so a score labelled CVSS-BTE has been adjusted for threat intelligence and your environment, while CVSS-B has not. Check which you are looking at.

Ask questions. If a finding is unclear, or you think it is a false positive, ask the tester before spending time on it. Our guide to reading a penetration testing report explains how findings should be written.

Group by root cause. Twenty findings may share one cause, such as a missing hardening standard or an unmaintained server build. Fixing the cause is quicker than fixing twenty symptoms, and stops them coming back.

How do you prioritise vulnerability remediation?

Severity is a starting point, not the answer. Weigh each finding against:

• Exploitability. Is there a public exploit, is the vulnerability in CISA’s Known Exploited Vulnerabilities catalogue, or does it have a high EPSS score? Actively exploited issues go to the top.
• Exposure. Is the system reachable from the internet, from the whole internal network, or only from a restricted segment?
• Asset value. Does it hold card data, personal data or credentials, or control access to other systems?
• Chaining. Did the tester combine several medium findings to achieve something serious? The chain matters more than any single link.

A medium-rated flaw on an internet-facing system holding customer data may be more urgent than a high-rated flaw on an isolated test server.

What are sensible penetration test remediation timescales?

Set vulnerability remediation timelines in your vulnerability management policy so decisions are consistent. The table below is an example to adapt, not a standard, with the fixed deadlines that some schemes impose shown separately.

For Cyber Essentials, the Cyber Essentials requirements set out the 14-day update rule in full, and the Cyber Essentials Plus audit tests for missing updates. For ISO 27001, Annex A control 8.8 covers technical vulnerabilities, and an auditor will expect to see findings tracked to closure.

Should you remediate, mitigate or accept?

Each finding needs one of three decisions, recorded with an owner and a date:

• Remediate. Remove the vulnerability: patch, reconfigure, fix the code or retire the system.
• Mitigate. Reduce the risk while the vulnerability remains, for example with network isolation, a web application firewall rule or extra monitoring. Mitigation should normally be temporary.
• Accept. Formally accept the residual risk, with a written justification, the approval of someone with the authority to give it, and a review date.

Risk acceptance cannot override a mandatory PCI DSS requirement. The equivalent route there is a properly documented compensating control; our guide to PCI DSS compensating controls explains what a QSA will expect, and PCI DSS consultancy can help you build one that stands up.

What should a remediation tracker include?

One row per finding, kept in the same place as your other IT work, so nothing is lost between the report and the retest. A tracker that an auditor or customer can follow needs these columns:

Download the free penetration test remediation tracker (CSV). It opens in Excel or Google Sheets and includes three example rows to replace with your own findings.

What are the common types of fix?

• Patching. Apply vendor updates and confirm they are installed across every affected system, not just the ones in the report.
• Configuration hardening. Disable unused services, remove default accounts, enforce strong protocols and tighten network rules. Update your build standard so new systems start hardened.
• Code fixes. Application flaws such as injection or broken access control need fixing in the code, then in the development process so they do not recur.
• Cloud and identity. Excessive permissions, public storage and weak authentication are common cloud findings. Fix the configuration and review who can change it.
• People and process. If testing showed staff could be manipulated, update procedures and training as well as technology.

Finally, clean up: remove any test accounts, tools or files created for the test.

How does a penetration test retest prove the fixes work?

A penetration test retest repeats the original attack against each fixed finding, ideally by the original tester, who knows exactly how each issue was exploited. A vulnerability scan can confirm a missing patch has been installed, but it cannot confirm that an access control flaw, a logic error or a segmentation weakness has been fixed properly.

If a fix fails the retest, go back to the root cause. The retest report, or a letter confirming closed findings, is the evidence your QSA, customer or insurer will want. For card environments, PCI penetration testing includes the retest evidence Requirement 11.4.4 asks for.

How do you stop the same findings coming back?

• Track findings in the same system as other IT work, with owners and due dates.
• Maintain hardening standards and check new builds against them.
• Run vulnerability scanning services between tests to catch new issues early.
• Build security testing into development and change processes.
• Test at a frequency that matches your rate of change; see how often penetration testing should be done.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. We can help you prioritise findings, retest fixes and, where PCI DSS applies, explain what your assessor will expect to see.

Next step

If a test has not gone well, a clear plan and a prompt retest usually restore confidence quickly. Our penetration testing services UK page covers retesting as well as new tests, and our penetration testing quote form gets you a fixed price for either.