You Have Your Penetration Test Report. Now What?

Introduction

The report lands in your inbox. It is long, it has a colour-coded summary, and somewhere in it is a list of findings with names like "Missing authorisation check" and "Weak password policy". The testers have done their job. What happens next decides whether the engagement was worth the money.

Too often the answer is: not much. The report is forwarded, the critical items are patched, and the rest sit in a spreadsheet until the next test a year later, when several of them appear again. This article explains how to turn a penetration test report into reduced risk, using guidance from the UK's National Cyber Security Centre (NCSC) and what we see in our own engagements.

A penetration test is an audit, not a to-do list

The NCSC's guidance on penetration testing makes a point that is easy to miss. It says penetration testing should be viewed as a method for gaining assurance in your vulnerability assessment and management processes, not as a primary method for identifying vulnerabilities. It compares a test to a financial audit: your finance team tracks income and spending day to day, and an external audit checks that your internal processes are sufficient.

That changes how you read the report. The list of findings matters, but the more useful question is: why did we not already know about these? The NCSC says that any vulnerability you did not previously know about deserves special attention, with the aim of working out how you might spot such issues in future. A finding is a symptom. The process gap behind it is the real problem.

Step 1: Read the report with your own risk in mind

The testers rate each issue, but they rarely have the full picture of your business. The NCSC notes that the test team may not have had access to all the details of a system or the business impact of exploitation, so they may rate issues lower or higher than you would.

Treat the report the way you treat the output of your own vulnerability assessment. Ask:

• What does this system actually do for us? A medium-rated flaw on a payments platform can matter more than a high-rated one on a retired test server.
• Is anything already mitigating it? Network controls, monitoring or compensating processes can change the real exposure.
• Do findings combine? Several low-rated issues can form an attack chain that is far more serious than any one of them. Good reports describe these chains explicitly. If yours does not, ask the testers in the debrief.

The NCSC is clear that this assessment should not be used to downplay issues. It is a way of identifying the risk to your organisation, not of making the report look better.

Step 2: Hold the debrief

Ask for a debrief with the testers. The NCSC recommends one, so the team can run through their findings and you can request more information or clarification. It is also the best chance to ask the questions a written report cannot answer:

• Which finding worried you most, and why?
• What did you try that did not work?
• Where were you blocked by scope, time or access, and what might sit behind those limits?
• What would you fix first if this were your estate?

The answer to the third question is often the most valuable. Every test has boundaries, and a good report records them as limitations. The NCSC notes that when testers find systems outside scope that could affect security, the options are to change the scope or to record the exclusion as a limitation. Either way, someone should decide what to do about it.

Step 3: Choose the fix, not just the patch

The testers will propose a remediation for each issue, but the NCSC points out that their solution may not be the only one. If a tester suggests patching a piece of software, it is worth asking whether the software is needed at all. It may be possible to remove it, to limit exposure with other controls, or to reduce the risk to an acceptable level with additional monitoring.

The same source states that vulnerability risk assessment and mitigation is a business process and should not be wholly outsourced to the test team. The testers advise. Your risk owners decide.

In practice we suggest sorting findings into three groups:

• Fix now: issues that give an attacker a direct route to sensitive data or systems, especially anything reachable from the internet.
• Fix with a plan: issues that need change windows, development work or supplier involvement. Give each an owner and a date.
• Accept or defer, in writing: issues where the cost of the fix outweighs the risk. A named risk owner should sign this off, with a review date. An undocumented decision to ignore a finding is not a risk acceptance.

Step 4: Fix the cause as well as the symptom

For each significant finding, ask what let it exist. The answers usually fall into familiar categories:

• A process gap, such as no asset inventory, patching that skips certain systems, or no review of new internet-facing services.
• A design or coding habit, such as inconsistent authorisation checks. The NCSC says testing of bespoke software should give developers feedback on the coding practices that avoid introducing these categories of vulnerability. If the same class of flaw appears across several applications, that feedback needs to reach the development team.
• A configuration standard that does not exist, so each system is built slightly differently.

Fixing the cause is what stops the same finding returning in next year's report. It is also what lets you tell your board something more meaningful than "we patched the issues".

Step 5: Retest, and keep the evidence

A fix that has not been verified is an assumption. Ask your testers to retest the findings you have remediated. We recommend building retesting into the engagement from the start, and aiming to complete it within 90 days of the report, while the details are still fresh and before the system has changed further.

Keep the outputs together: the original report, the remediation owners and dates, the retest results, and any signed risk acceptances. That pack answers the questions that follow a test, whether they come from a board member, an auditor, a customer's security questionnaire or a cyber insurer. It shows not just that you tested, but that you acted.

Step 6: Feed the result back into everyday security

The NCSC also warns that a penetration test can only validate that your systems are not vulnerable to known issues on the day of the test, and that a year or more can pass between tests. Vulnerabilities can exist for long periods without you knowing about them if the test is your only means of validation.

So use the report to improve what happens between tests. Add the missed issue types to your routine scanning and review. Update your build standards. Add the attack chains the testers described to your threat model. Then, at the next scoping conversation, share your current vulnerability assessment with the testers. The NCSC suggests this so testing can be designed to support a reasonable opinion on the accuracy and completeness of your own assessment.

Practical Insights

1. Read the report as an audit of your processes. Every unexpected finding points to something your own assurance missed.
2. Rate findings against your business, not just the severity label. Context can move an issue up or down, and attack chains matter more than single items.
3. Always take the debrief. Ask about limitations and what the testers could not reach.
4. Consider alternatives to the suggested fix. Removing, isolating or monitoring a component can sometimes reduce risk as well as patching does.
5. Give every finding an owner and a date. Anything accepted or deferred should be recorded, signed off and reviewed.
6. Fix the cause. Feed recurring flaw types back to developers, build teams and process owners.
7. Retest and keep the evidence. Verified fixes are what boards, auditors and insurers want to see.
8. Use the result between tests. A point-in-time test only helps if your everyday controls improve because of it.

Conclusion

A penetration test report is not the end of an engagement. It is the start of the part that reduces risk. The testers have shown you where an attacker could get in. What you do in the following weeks decides whether those routes are closed, monitored or simply forgotten.

Treat the report like an audit finding: understand it, assign it, fix the cause, verify the result and keep the evidence. Done well, each test makes the next one shorter and its findings less surprising.

Don't wait for a real adversary to find the pathway. Contact our team today to discuss a tailored manual assessment for your organisation, including retesting and a debrief to help you act on the results.