How to Read a Penetration Testing Report: Contents, Priorities, and Follow-Up

Short answer: read a penetration testing report in three layers. Management reads the summary: what was breached and what it means for operations. System owners read the list of findings by severity to set priorities and deadlines. Technical teams use the attack path and reproduction steps to fix the flaws, then ask for a retest until every finding is declared closed.

A penetration testing report often ends up in a shared folder, read once, then forgotten until the next test finds the same flaw. The problem is rarely the content of the report, but how it is read: everyone reads everything, or nobody feels responsible for any part. This article explains the sections of a report and who should read what.

Sections of a penetration testing report

Section	Contents	Main readers
Management summary	What was breached and what it means for operations, without technical terms	Directors, management
Scope and method	Assets tested, period, approach (black box, grey box, white box), limits	System owners, auditors
Attack path	The sequence of steps from the entry point to the data or access obtained	Technical team, system owners
List of findings	Each flaw with its severity, evidence, and impact	System owners, technical team
Reproduction steps	How to repeat a finding, so it can be confirmed independently and tested after it is fixed	Technical team
Fix recommendations	Fix steps per finding and the order of work	Technical team, vendors
Retest results	The status of each finding after it is fixed	All parties

Reading the management summary

The summary answers the questions that matter most to decision makers: can an attacker get in, what can they reach, and what is the impact on operations and customers. From this section, management decides two things: who is responsible for the fixes, and whether extra resources are needed, for example a development vendor that must be brought in.

A good summary also states what was not tested. Anything outside the scope is not necessarily safe, it just has not been examined.

Reading the list of findings and severity

Each finding is given a CVSS score and grouped into the critical, high, medium, or low level. An explanation of the score ranges is in the article What Is a CVSS Score and How Do You Read It?. What to remember when reading this list: the score is a starting point, not the final decision. A medium finding on a system that stores customer data can be more urgent than a high finding on an isolated test system.

Also watch for findings that are linked to each other. An attack path often shows that several small flaws, chained together, produce a large impact. Fixing one link can break the whole chain.

Turning the report into a remediation plan

1. Assign an owner to every finding. One name per finding, not “the IT team”.
2. Set deadlines by level. For example, critical and high findings within days, medium within a few weeks, low in the next fix cycle. Adjust to what your team can do, but write it down.
3. Use the reproduction steps to confirm that a fix really closes the flaw, rather than merely hiding the symptom.
4. Ask for a retest once the fixes are done. A finding counts as finished only after it has been retested and declared closed.
5. Record the lessons. A flaw that comes from a development habit, such as inconsistent input validation, probably exists elsewhere in the system too.

Example of reading one finding

Imagine a high-level finding that reads: an ordinary user can open another user’s data by changing the number in the page address. Here is how to read it:

• Impact: anyone with an account can see other people’s data. If the data is personal, this touches data protection obligations.
• Evidence: a screenshot, or a request and response, showing that data belonging to another account was opened.
• Reproduction steps: a sequence your team can follow to repeat the finding in a test environment.
• Fix: an access rights check on the server side for every data request, not just hiding the link in the interface.
• Scope: if one page is flawed because of a certain pattern, check the other pages that use the same pattern.

This example is a general illustration, not a client finding. The pattern applies to any finding: understand the impact, confirm the evidence, fix the root cause, then check whether the same pattern exists elsewhere.

Keeping the report confidential

A penetration testing report is a map of your system’s weaknesses. Limit who receives it, send it through an encrypted channel, and do not forward it by ordinary email to many people. For outside parties who ask for proof of testing, such as clients or partners, provide a summary or a closure statement, not the full technical report.

How Legia does it

Legia’s Penetration Testing report contains five parts: a management summary, the full attack path, reproduction steps per finding, severity based on CVSS, and a retest. High-risk findings are reported immediately without waiting for the final report. The report is handed over through an encrypted channel only to the recipients you designate, along with two explanation sessions. A retest after fixes is included in the package and ends with a statement confirming the flaws are closed. The approaches used during testing are explained in the article Black Box, Grey Box, or White Box.

Frequently asked questions

Sources

• OWASP Web Security Testing Guide, Reportingowasp.org
• FIRST, Common Vulnerability Scoring Systemfirst.org

Asked to hand over security test results for an audit or a release? See Legia cybersecurity services, or schedule a consultation through the contact page.