What a Penetration Test Report Contains

Report structure varies between firms, but a report you can act on and hand to an auditor carries the same eight parts. Each one below says what goes in it and why it is there, and links to that part of the real report further down this page.

The report is not an afterthought to the testing. NIST SP 800-115, the US National Institute of Standards and Technology guide to security testing, places reporting in Section 8 under post-testing activities, next to mitigation recommendations and remediation, and notes that a report may need more than one format because it has more than one audience. That is why the document below opens with an executive summary written for leadership and then repeats the same findings in reproducible technical detail for engineers.

01

Document control and revision history

What is in it: Report title, client, engagement type, version number, issue date, classification, and the named assessors. Plus a revision table showing what changed between versions.

Why it exists: Whoever reads this later needs to know which version they hold and whether it predates the fixes. A report with no version and no date cannot be used as evidence in an audit or a security questionnaire.

See document control
02

Executive summary

What is in it: An overall risk rating, the finding counts by severity, the business impact in plain language, the top priorities, and a recommendation on sequencing the work.

Why it exists: The people who approve budget and release schedules often read this page and nothing else. If the summary is only a count of findings, leadership has no basis to act on it.

See the executive summary
03

Scope and methodology

What is in it: Severity rating definitions, the in-scope targets, the environment tested, the testing window, the testing approach and access provided, the standards followed, the tools used, and an explicit out-of-scope list.

Why it exists: This is where the plan agreed before the engagement is carried into the report, so a reader can check the work against what was authorised. It is usually the first section an auditor reads, because it establishes whether the test covered the system inside the audit boundary.

See scope and methodology
04

Findings summary

What is in it: One row per finding: identifier, title, severity, CVSS score, CWE, OWASP category, affected endpoint, and current status.

Why it exists: This is the table engineering triages from and the table a reviewer scans first. It should be readable on its own, without opening a single detailed finding.

See the findings summary
05

Detailed findings

What is in it: For each finding: a description, the affected endpoint, severity with the full CVSS vector, numbered steps to reproduce, the raw request and response as evidence, the business impact, and remediation guidance.

Why it exists: This is where a report stops being a list and becomes reproducible. If your engineers cannot reproduce a finding from the report alone, they cannot confirm the fix worked either.

See a detailed finding
06

Retest results

What is in it: Every original finding re-checked after the fixes, with a remediated or still-open status, notes on what changed, and evidence captured in the fixed state.

Why it exists: Closes the loop. A finding marked resolved with no retest evidence behind it is the client word, not a verified result, and that is exactly the gap an auditor or an enterprise security reviewer probes.

See the retest trail
07

Compliance control mapping

What is in it: Each finding mapped to the SOC 2 trust services criteria and the ISO/IEC 27001:2022 Annex A controls it touches, with the evidence reference.

Why it exists: Turns findings into filed audit evidence instead of a narrative your compliance lead has to translate by hand. Included on the Growth plan.

See the control mapping
08

Appendix and disclaimer

What is in it: Tools used, assessor credentials, the report distribution list, a glossary of terms, and a statement of what the testing could not cover.

Why it exists: Testing is time-boxed and scope-bound. A report that does not say so in writing is overclaiming, and the disclaimer is what a reviewer looks for to judge whether the firm is being straight with them.

See the appendix

The document below is the worked example. It runs in that order, from cover page to disclaimer, exactly as it was delivered.

Confidential

How Severity Is Scored in a Penetration Test Report

Every finding in the report above carries two labels that look similar and answer completely different questions. Getting them the wrong way round is the most common reason a report gets triaged badly.

CWE answers what kind of weakness this is

The Common Weakness Enumeration is a catalogue of software weakness classes, each with a stable identifier. The first finding above is CWE-639, Authorization Bypass Through User-Controlled Key.

It is an identifier, not a score. Its value is that the same class of problem is named the same way across reports, tools and advisories, so your team can recognise a repeat rather than treating it as new.

CVSS answers how serious this instance is

The Common Vulnerability Scoring System, maintained by FIRST, rates a finding from 0.0 to 10.0. Critical is 9.0 to 10.0, High is 7.0 to 8.9, Medium is 4.0 to 6.9, Low is 0.1 to 3.9, and Info is 0.0.

The number on its own is an assertion. The vector string underneath it is what makes the number checkable, because it records every assumption the score was built from.

What to check on a finding

Element What it tells you What its absence tells you
CWE identifier The weakness class, in language that matches other reports and tools Findings cannot be grouped, compared or tracked across engagements
CVSS score How serious this instance is, on a scale everyone reads the same way Severity is the assessor's adjective, and adjectives do not sort
CVSS vector string The inputs behind the score, so you can reproduce it in a public calculator The score has to be taken on trust, and cannot be challenged or corrected
Severity band definitions What the report itself means by Critical or High Two reports from two firms cannot be compared at all
Affected endpoint Where in your application the problem lives Engineering cannot start without first reproducing the discovery

Severity is not the same as remediation priority. A CVSS score rates the vulnerability. Priority also has to account for how reachable the issue is in your deployment, what the fix costs, and what ships next. In the report above, priority is set in consultation with the client and the two are kept as separate columns on purpose, because collapsing them hides the reasoning.

Why two CVSS versions appear. Findings above are scored under both v3.1 and v4.0, with full vectors for each. v3.1 is what NVD, CISA KEV and most vendor advisories still publish, so it is the version your other tooling speaks. v4.0 has been the current FIRST standard since November 2023 and separates the impact on the vulnerable system from the impact on systems downstream of it. The severity bands are identical in both. The scores are not, so a finding CAN move band between the two versions. CS-2026-001 in this report is the example: 9.1 Critical under v3.1 and 7.2 High under v4.0, because v4.0 separates impact on the vulnerable system from impact on subsequent systems and removes the old Scope metric that inflated it.

How to Tell a Real Penetration Test Report From Scanner Output

Plenty of documents sold as penetration test reports are an automated scan with a cover page on it. Both cost money, only one of them survives contact with an auditor or an enterprise security review. Six things separate them, and you can check all six in about two minutes without a security background.

A named tester, not a tool version

A real report says who tested and what they hold. Scanner output credits a product and a scan engine build number. In the report above the assessors are named on the cover and their credentials are listed in Appendix B.

Reproduction steps against your application

Look for numbered steps plus the exact request and response that triggered the issue, on your endpoints. Scanner output gives a generic description of the vulnerability class and a link to a public advisory, which your engineers cannot act on directly.

Business impact written in your context

A real finding names the data, the users, or the revenue at risk in your product. Boilerplate impact text that would read identically for any customer is the tell that no human considered your system.

Authorisation and business logic findings

Automated tools cannot reason about who should be allowed to do what, so they do not surface an IDOR in a billing flow or a token refresh that never expires. If every finding is a missing header, an outdated library or a TLS setting, the application logic was never tested. The two critical findings above are exactly the class scanners miss.

Findings chained together

A tester shows how two medium issues combine into one high-severity path. A scanner scores every finding in isolation because it has no view of the others and no ability to try the combination.

An honest statement of limits

A real report says what was out of scope, what the time-box did not cover, and that testing is a snapshot. A tool cannot write that section because it does not know what it was not pointed at.

A finding count is not a quality signal in either direction. Automated output usually carries far more rows because nothing in it has been validated by hand, and a validated report is shorter for exactly that reason.

What an Auditor Checks in a Penetration Test Report

If the report is going into a SOC 2 or ISO 27001 file, or into an enterprise customer security review, it stops being a technical document and becomes evidence. Evidence gets checked differently. Seven things get looked at, usually in this order.

  1. Date and version. Is this the current version, and does a revision history show what changed between issues? An undated report cannot be tied to a point in the audit period.
  2. Scope match. Do the targets named in the report match the system inside the audit boundary? A report covering a different application, or a staging environment with no statement that it mirrors production, leaves the control open.
  3. Named methodology. Does it cite a recognised standard rather than describing an in-house process? OWASP WSTG v4.2, OWASP ASVS 5.0.0, OWASP API Security Top 10 2023, PTES and NIST SP 800-115 are the ones auditors recognise on sight.
  4. A published rating scale. Every finding needs a severity, and the report itself needs to define what each severity band means. CVSS scores with the vector shown let the rating be reproduced rather than taken on trust.
  5. Status per finding. Open or remediated, on every row, in the version being filed.
  6. Retest evidence. Anything marked closed should be closed because it was re-tested and re-evidenced, not because it was reported as fixed. This is the single most common gap, and it is the one that generates follow-up questions.
  7. Control mapping. For SOC 2 and ISO 27001, each finding tied to the control it affects, so the report files as evidence instead of being read as a narrative your compliance lead has to translate by hand.

The report above carries all seven. The SOC 2 and ISO/IEC 27001:2022 Annex A control mapping in Section 6 is included on the Growth Pentest plan; Startup plan reports are identical in every other respect. To be explicit about what we are: we do audit preparation work. We are not an audit firm and we do not issue certifications.

See it in a real report

Everything above is easier to judge against an actual document. Our sample report is a full engagement, findings, evidence, retest and compliance mapping included, with nothing gated.

Read the sample report