How to Read a Penetration Test Report

A usable penetration test report is one your leadership can skim and your engineers can act on. It restates the scope you agreed, explains how testing was done, and lists each confirmed finding with a severity, evidence, business impact in plain language, and remediation a developer can follow. This post shows how to read that report using one annotated hypothetical finding. A penetration test is not a compliance certification, and the report is part of how you judge whether the engagement was usable.

Short answer

Read the executive summary for the picture, then read each finding as if you have to assign the fix. A usable finding names where it was observed, includes steps a developer can follow, shows evidence of what was confirmed, ties impact to a business asset, and recommends a concrete change. If those parts are missing, the readout is where you ask for them.

What a report usually contains

Layouts vary. These parts are the ones buyers actually use. If one is thin or missing, that is a signal, not a style preference.

• Executive summary. A short section for leadership: what was tested, how many confirmed findings sit at each severity, and which issues need a decision first. Check that it matches the technical findings. The counts and the top issues should not disagree.
• Technical findings. The body of the report. Each confirmed issue should stand on its own so a developer can pick it up without reading the rest of the document.
• Severity method. How ratings were assigned, for example a named scale such as Critical, High, Medium, and Low, and what those labels mean in this engagement. Context matters: the same class of bug can be High in one system and Medium in another. A critical-severity issue is one the tester treats as urgent, often by contacting the named person during testing rather than waiting for the report.
• Evidence. What the tester observed, such as a response, a screenshot description, or a log line, that shows the issue is real. Scanner output on its own is not enough.
• Business impact. What it means for your customers, data, or operations, written so someone who does not test systems for a living can follow it.
• Remediation. The change that would close the issue, specific enough to implement or to ticket.
• Methodology notes. Scope, testing window, authorization, what was in and out of scope, and any limits, for example no denial-of-service testing. Confirm this matches what you agreed before testing started. Authorized testing only happens inside that written scope.

How to read one finding: an annotated illustrative example

This is an illustrative scenario, not a real client or case study. Example Corp, staff.example.com, and app.example.com are placeholders.

Service pages on this site show how an engagement runs from scope to readout. This section is different: it is one finding, annotated so you can see what to look for when you open a report. The issue is hypothetical. A real report covers every confirmed finding in the same shape.

In this example, Example Corp asked for an authorized test of its customer application at app.example.com and the staff console at staff.example.com. Support users can view a customer workspace to help with tickets. The tester confirmed that the link used for that view kept working after the support session ended.

GET /support/resume?token=EXAMPLETOKEN HTTP/1.1
Host: app.example.com

HTTP/1.1 302 Found
Location: /workspace/example-corp
Set-Cookie: session=...

A weak write-up of the same issue might say only “Broken authentication, High, improve session management.” That does not tell a developer where to look, how to confirm it, or what to change. If a finding in your report is a title and a severity with nothing under them, ask for the missing parts in the readout rather than guessing.

Severity labels only make sense next to the method the report names. This tiny table is illustrative for the same hypothetical report. It is not a universal scale.

When you read your own report, check that the rating on each finding matches the impact paragraph beneath it. A High title with Low impact text, or the reverse, is a cue to ask about the method in the readout.

What to ask in the readout

The readout is the call after the report is delivered. Bring the people who will fix the issues, not only the people who bought the test. Use the time to resolve anything a developer would get stuck on.

• Walk us through this finding's evidence again, in the same environment we will use to fix it.
• What would you fix first, and why that order rather than severity order alone?
• Which agreed systems were not fully covered, and what stayed out of scope?
• If we make the change as written, what nearby behavior should we re-check?
• Who on your side answers questions while we implement the fix?
• For any critical-severity issue, when were we told during testing, and what had already been done by the time the report arrived?

You do not need to replay every step on the call. You do need enough shared understanding that a ticket can be written without guessing.

Retest and what “fixed” means

Retest terms set in the statement of work.

A retest usually means the tester returns to the original confirmed findings, in the agreed scope, and tries the same steps again. “Fixed” in that sense means the original issue could not be reproduced as written. It does not mean every related path is gone, and it does not mean the rest of the system is free of other issues. Anything found after the testing window, or outside the agreed scope, is a different conversation.

A penetration test is not a compliance certification. The report can be one input to a vendor review or a broader security program. It does not certify that you meet a standard.

If you want to see how we write findings for a scoped engagement, read about web application security testing or network penetration testing. Contact us to agree a scope.

Frequently asked questions