How to Read a Penetration Test Report

A penetration test report can run to dozens of pages. It has severity labels, scores, screenshots, request logs and remediation advice. If it’s your first one, it’s easy to skim the coloured labels, panic at the word “critical” and miss what the report is really telling you.

This guide explains how a typical report is structured, how to read severity ratings, how to judge the evidence, and how to turn findings into a plan your team can actually deliver. Most of it applies to any professional pentest report, not just ours.

How a report is usually structured

Most reports follow a similar shape, because they serve several audiences at once.

Section	What it tells you	Who reads it most
Executive summary	Overall risk, key themes and priorities in plain English	Leadership, customers, board
Scope	What was tested, when, from where, and what was excluded	Auditors, security leads
Methodology	The standards followed and the approach taken	Auditors, technical reviewers
Findings	Each issue with impact, evidence, reproduction steps and fixes	Engineers
Retest status	Which findings are fixed, partly fixed or still open	Auditors, customers, engineers
Appendix	Supporting detail such as tested endpoints and accounts	Engineers, reviewers

You can see how we structure our own reports on our methodology page, or request our sample report to see a full redacted example.

Start with the scope, not the findings

It’s tempting to jump straight to the list of issues. Read the scope first.

The scope tells you what a “clean” result actually means. A report with no critical findings is reassuring only if the important parts of your system were in scope. Check:

• Which systems, environments and user roles were tested. If the admin role or a second tenant wasn’t included, access-control testing between them wasn’t possible.
• The testing dates. Your auditor and customers will look at these. Changes made after the test window are not covered.
• What was excluded and why. Exclusions are normal. Make sure they were deliberate decisions, not accidents.
• Any limitations. For example, accounts that arrived late or a staging environment that was unavailable for part of the test.

If something important is missing, note it now. It may belong in the next test.

Understanding severity ratings

Every finding gets a severity rating, usually Critical, High, Medium, Low or Informational. Behind that label there are normally two things: a standard score and a judgement about your business.

The CVSS score

Most testers use the Common Vulnerability Scoring System (CVSS). We use CVSS v3.1. It scores a vulnerability on factors such as:

• How it can be reached, for example over the network or only with local access
• How hard it is to exploit
• Whether the attacker needs an account or a user’s help
• What it affects: confidentiality, integrity and availability

The result is a number from 0 to 10, plus a “vector string” that records each factor. The vector is useful because it shows why a score is what it is.

Business impact

CVSS is consistent, but it doesn’t know your business. A flaw that exposes test data in an internal tool is not the same as one that exposes customer records in your main product, even if they score similarly.

That’s why a good report pairs the score with plain-English impact. In our reports, the levels mean roughly this:

• Critical: an attacker can cause serious harm now, such as reading other customers’ data or taking over accounts at scale. Fix immediately. You should hear about these during testing, not when the report arrives.
• High: significant harm is possible, but it needs some conditions, such as a valid account or user interaction. Fix as a priority.
• Medium: a real weakness with limited direct impact, or an issue that helps an attacker go further. Plan a fix in your normal release cycle.
• Low: a minor issue that adds little risk on its own but weakens your defences. Fix when convenient.
• Informational: observations and hardening advice that are not vulnerabilities in themselves.

Reading an individual finding

A well-written finding answers five questions. If any are missing, ask the testers.

1. What is the issue? A short, specific description, not a generic paragraph copied from a vulnerability database.
2. Where is it? The exact URL, endpoint, parameter, host or component.
3. What could an attacker do? The impact in the context of your system.
4. How do we know? Evidence: requests and responses, screenshots, or output that shows the issue was confirmed.
5. How do we fix it? Remediation guidance specific enough to act on, with references where useful.

Judging the evidence

Evidence is what separates a pentest finding from a scanner alert. Look for proof that a tester actually confirmed the issue, for example:

• A request using one user’s session that returns another user’s data
• A screenshot of an action performed with a role that shouldn’t allow it
• The exact payload that triggered the behaviour, and the response

Your engineers should be able to follow the reproduction steps and see the issue themselves. If they can’t, that’s worth raising. It may be an environment difference, a step that needs more detail, or something that has already changed since the test.

Chained findings

Sometimes a report describes how several smaller issues combine into a bigger one. For example, an information leak reveals user IDs, and a separate authorization flaw lets anyone use those IDs. Each issue on its own might be Low or Medium. Together they may be High or Critical.

Pay attention to these chains. Fixing any one link can break the whole attack, which often gives you a fast way to reduce risk.

Turning findings into a fix plan

Once you understand the findings, decide what to do and in what order. Severity is the starting point, not the whole answer.

A practical way to prioritise

• Fix critical findings straight away. If they’re in production, consider temporary mitigations while a proper fix is built.
• Break chains early. If one fix removes several attack paths, move it up.
• Look for shared root causes. Ten findings caused by one missing authorization check are one fix, not ten.
• Take the quick wins. Configuration changes such as security headers or cookie flags are often cheap and worth doing together.
• Schedule the rest. Put medium and low findings into normal planning with owners and target dates.

Match your timelines to your vulnerability management policy, if you have one. Auditors often compare the two.

Accepting risk deliberately

You don’t have to fix everything. Sometimes a fix costs more than the risk it removes, or a compensating control already covers it. That’s fine, as long as the decision is:

• Made by someone with the authority to accept the risk
• Written down with the reason
• Reviewed again later

A recorded, reasoned decision is usually acceptable to auditors. An unexplained open finding is not.

The retest: closing the loop

After you’ve made fixes, the testers retest the reported findings. Each one is then marked as fixed, partly fixed or still open, and the report is updated.

This step matters more than many teams expect:

• For auditors, the retest shows you acted on the findings.
• For customers, an updated report or attestation letter is far more reassuring than a list of open issues.
• For engineers, it confirms the fix actually works, including against small variations of the original attack.

A retest is not a new full test. It checks the reported findings, not new features or areas outside the original scope.

Plan the retest early

The most common mistake is leaving fixes until just before a deadline. Work backwards from the date you need evidence:

1. Report delivered
2. Walkthrough and fix planning
3. Fixes built, reviewed and deployed
4. Retest
5. Updated report and attestation letter

If an audit or a customer is waiting, leave real time for steps three and four.

Questions to ask about any report

Whether the report is from us or from someone else, these questions help you judge its quality:

• Does the scope match what you asked for, and are the dates clear?
• Is every finding specific to your system, with evidence?
• Can your engineers reproduce the important findings from the steps given?
• Do the severity ratings explain business impact, not just a score?
• Is the remediation advice specific enough to act on?
• Is there a clear way to get a retest and an updated report?

If the answer to most of these is yes, you have a report you can work from, and one your auditors and customers can rely on.

Next steps

If you’re planning a test, our how we work page explains our process from scoping to attestation. To see how a full report is laid out, request our sample report.