No items found.
Back
Link Copied!
Copy link
June 1, 2026
0
min reading time
Smiling woman in a light blouse reading a brochure with a chart, surrounded by colleagues in a bright, modern office.

You've ordered a penetration test and received a 60-page report. Now what?

It's easy to feel overwhelmed the first time. The report contains technical terms, lengthy appendices, and findings that can be difficult to translate into practical action. This guide explains what each section is for, how to interpret severity ratings, and how to prioritize when it's time to solve the issues.

Report structure — what you'll find where

Most penetration test reports follow a similar structure, regardless of the testing company. Here are the most common sections:

Executive summary — a concise overview of the key findings, written for decision-makers without a technical background. This is where you start.

Scope — exactly what was tested. Which systems, IP addresses, applications, and environments were included. It's important to verify that the scope matches what you ordered.

Methodology — how the test was conducted. Black box, grey box, or white box. Which phases were included. Read this section if you want to understand how thorough the test actually was.

Findings — the main body of the report. Each vulnerability is listed with a description, severity rating, evidence, and remediation recommendation. This is where you'll spend most of your time.

Recommendations — sometimes consolidated in a separate section, sometimes embedded per finding. Describes concretely what needs to be done.

Appendices — technical details such as payload examples, screenshots, and request/response logs. Intended for the people who will carry out the fixes.

Executive summary — for leadership

It's tempting to jump straight to the findings list, but always start with the executive summary. It's written to give you and your leadership team a quick picture of the current situation without having to work through 60 pages of technical detail.

A good executive summary should be able to answer three questions:

How serious is the situation? It should clearly communicate whether the organization has critical vulnerabilities requiring immediate action, or whether the overall picture is more manageable.

What are the worst findings? The most severe vulnerabilities should be highlighted with a brief explanation of what could happen if they were exploited.

What happens if we do nothing? The consequences of inaction, described in practical terms.

If the summary is vague, full of generic statements about "security issues" without concrete examples, or lacks a clear risk assessment, it's a sign that the report as a whole may be superficial.

Understanding severity ratings (CVSS)

Most reports use CVSS, the Common Vulnerability Scoring System, to classify findings. It's a standardized scale from 0 to 10 that divides vulnerabilities into five categories:

  • Critical (9.0–10.0) — Vulnerabilities that can give an attacker full control of the system with no authentication or user interaction required. Examples: remote code execution with root privileges, SQL injection giving access to the entire database.
  • High (7.0–8.9) — Serious flaws that require some interaction or authentication to exploit, but can still cause significant damage. Examples: privilege escalation, exposure of sensitive data.
  • Medium (4.0–6.9) — Flaws with limited impact on their own, but potentially dangerous in combination with other findings. Examples: information disclosure, misconfigurations.
  • Low (0.1–3.9) and Informational — Best practice recommendations, with no directly exploitable risk.

One important thing to understand: CVSS measures a vulnerability in isolation. It doesn't account for your specific environment, your exposure to the internet, or the business value of the affected system. A Critical finding in a system that isn't reachable from outside is a different matter than a Critical in your public payment platform. Always read the tester's own risk commentary — it factors in what the CVSS score doesn't capture.

Prioritizing remediation based on risk and effort

The report has been delivered. Now you need to prioritize. A simple rule of thumb is to work from two axes: severity and how complex the finding is to fix.

Start with findings that are Critical or High and also straightforward to fix. This might mean updating a software version, closing a port, or correcting a misconfiguration. These give you the greatest security improvement for the least effort.

The next step is Critical and High findings that require more work — for example, architectural changes or code rewrites. These need to be planned with adequate resources, but shouldn't be put off.

Medium findings should be addressed within the quarter. Low and Informational can be handled as part of regular maintenance.

A good penetration test report gives you not just a list of findings but concrete remediation recommendations for each vulnerability. It should be clear what needs to be done, not just what's wrong. If the report lacks this, ask the tester directly.

What to do if you don't understand a finding

It happens to everyone. Penetration test reports are technical documents, and some findings assume knowledge of network security, application development, or cryptography that you may not have in-house.

That's completely normal, and it's exactly why the post-delivery review exists. Always ask for a walkthrough with the tester where you can ask questions — not just about what was found, but what it actually means for your organization and what you need to do.

At Cyloq, a post-delivery review is always included. Developers, IT managers, and decision-makers can all attend and ask questions directly to the person who conducted the test. Some of the most valuable insights tend to come out of that conversation.

After remediation — retesting

Once you've addressed the most important findings, order a retest. The purpose is to verify that the fixes actually closed the vulnerabilities and that no new issues were introduced as an unintended side effect.

A retest is not a new full penetration test. It's a targeted test focused on the specific findings that were remediated, which makes it significantly faster and cheaper. A retest typically costs 20–30 percent of the original test.

Retesting is especially important for Critical and High findings, where the consequences of an incomplete fix are greatest. It gives you independent confirmation that the remediation holds.

For more on costs, see our article on what a penetration test costs.

Take action

Want to go through your report with us? Book a review

A report is a starting point, not an end goal. If you'd like help interpreting the findings, prioritizing remediation, or planning next steps, you're welcome to book a review with us.

Book a meeting

FAQ

Frequently asked questions about penetration test reports

How long is a typical penetration test report?

A standard report is 40–80 pages depending on scope and number of findings. Technical appendices with payload examples and screenshots can make it longer. The executive summary is always a maximum of 2 pages and written for decision-makers without a technical background.

What does "false positive" mean in the report?

A false positive is a potential finding that, on closer inspection, turned out not to be exploitable in your environment. Good testers filter these out before delivery. If you still see them, question the process. It may indicate sloppy verification.

Do we need to fix every finding?

Not necessarily. Critical and High findings should be addressed immediately. Medium findings should be scheduled within the quarter. Low and Informational are typically best practice recommendations and can be handled through regular maintenance.

What do we do if a finding in the report has already been fixed?

Contact us. It sometimes happens that the report is written while your technical team is simultaneously patching a known vulnerability. We're happy to verify via a retest or quick verification, and it rarely affects the invoice.