Cybersecurity / Reading a Report
Inside a penetration-testing report
The report is the product — it's what your engineers fix from, what your auditor cites, and what your customers may ask to see. Here's how to read one, section by section, using our own published sample.
The deliverable you should judge before you sign
When a penetration test ends, the testers leave and the report stays. It becomes the remediation worklist for your engineers, the evidence your auditor cites, and the document your enterprise customers ask for in due diligence. Yet most teams buy testing without ever seeing what the vendor’s report looks like.
We publish ours. The walkthrough below follows the actual sections of our redacted sample report — an API vulnerability assessment and penetration test from a real engagement — in the order they appear, with what each section is for, who reads it, and what a good version looks like from any vendor.
The report, section by section
- 01
Cover & redaction note
- What it is
- The sample opens by saying exactly what it is: an API Vulnerability Assessment & Penetration Testing summary report from a real engagement, with client identity, endpoints, and evidence removed. The redaction note tells you the purpose — to show report structure and depth, not to impress you with someone else's findings.
- Who reads it
- Everyone — it sets the terms of what you're reading before you read it.
- What good looks like
- A sample that admits it's a sample. If a vendor's example report doesn't say what was redacted and why, you can't tell how much of the depth is real.
- 02
Assessment overview
- What it is
- One paragraph of ground truth: what was tested, over what period (two weeks, in this engagement), and against which methodologies — NIST SP 800-115 and the OWASP API Security Testing methodology, alongside our own. It also names the phases the work moved through: Planning, Discovery, Attack, Reporting.
- Who reads it
- The auditor first — this paragraph is what gets cited as evidence that testing followed a documented, industry-accepted methodology. Executives read it to confirm what was actually covered.
- What good looks like
- Named public frameworks, not just a vendor logo. An overview that can't name its methodology is describing a scan, and an auditor will notice.
- 03
Scope
- What it is
- A table, not prose: assessment type, targets (API endpoints and Swagger collections, redacted in the sample), the user roles tested (Organization Admin and Organization Member), and the exclusions the client requested — denial of service, and phishing/social engineering.
- Who reads it
- The auditor checks that scope matches the system their audit describes. Engineers check which roles and surfaces were exercised — a finding's absence only means something for surfaces that were in scope.
- What good looks like
- Exclusions in writing. A scope section that lists what was not tested, and why, is a report you can rely on; one that leaves exclusions unstated leaves you guessing at coverage.
- 04
Finding severity ratings
- What it is
- The report's severity model, stated before any findings: five levels — Critical, High, Medium, Low, Info — each tied to a CVSS v3 score band, a definition, and a patch-priority expectation, from 'patch immediately' for Critical down to 'next maintenance window' for Low. Info covers observations and strong controls, not just gaps.
- Who reads it
- Engineers use it to sequence fixes. Executives use it to understand what the counts on the next page actually mean.
- What good looks like
- A published rubric. Severity should be a rule applied consistently, not a mood — and stating the bands up front lets you challenge any rating against the definition.
- 05
Vulnerability summary & report card
- What it is
- The whole engagement on one page: counts by severity (in this representative engagement: 0 Critical, 3 High, 1 Medium, 6 Low, 2 Info) and a table of every finding — ID, severity, one-line description, one-line remediation. The IDs (PT-001 onward) are how findings get tracked through fix and retest.
- Who reads it
- The executive's page — it answers 'how bad is it?' in thirty seconds. Engineers use the table as their remediation worklist; auditors trace finding IDs from here through to retest.
- What good looks like
- Every finding carries a stable ID and a remediation summary right in the table. If the summary page can't say what to do about each finding, the detail pages usually can't either.
- 06
Security rating
- What it is
- An overall grade derived from the count and severity of findings — this engagement graded A, with the primary risks in AI prompt handling and file-upload security. One line of judgment, on top of the evidence, naming where the real risk concentrates.
- Who reads it
- Executives and boards — it's the one-word answer, with the two-phrase explanation of what to worry about first.
- What good looks like
- A grade that names its basis. An overall rating is only useful if the report shows the findings it was computed from — otherwise it's marketing.
- 07
The example finding — the anatomy that matters most
- What it is
- One finding reproduced in full (PT-001, a prompt-injection flaw in an AI processing endpoint), showing the structure every finding carries: Description, Impact, Affected Component, Evidence, and Remediation. The sample also notes why this class matters — prompt injection is invisible to a conventional API scanner and sits outside the OWASP API Top 10 that most tools check.
- Who reads it
- This is the engineer's section. A finding is only fixable if the description says what's wrong, the affected component says where, the evidence proves it's real, and the remediation says what to change.
- What good looks like
- Demonstrated impact, not asserted risk. Read a vendor's example finding before you sign: if it reads like a CVE description pasted under a heading, the real report will too.
- 08
What the full report adds
- What it is
- The sample closes by listing what the complete deliverable includes beyond this summary: an executive summary for leadership, every finding with reproduction steps and evidence, remediation grouped by affected functionality, retest verification once fixes are applied — findings updated to 'remediated and retested' — and an annual-cadence recommendation. In the engagement this sample is drawn from, the client remediated the findings and a follow-up retest returned a clean scan.
- Who reads it
- All three readers: the executive summary for the decision-maker, the evidenced findings for the engineer, and the retest-verified final version for the auditor.
- What good looks like
- Retest closes the loop. The version of the report that outlives the engagement should say 'remediated and retested' — a report that ends at 'reported' leaves your auditor holding open risk.
Read the sample yourself
The sample is a direct download — no form, no contract, no call required. Judge our reporting depth, severity reasoning, and remediation detail before you ever talk to us, and hold every other vendor’s sample to the same sections.
Download the sample report (PDF)
Evaluating vendors? “A sample report — before you sign” is criterion two in our guide to choosing a penetration testing vendor. How the testing behind a report actually runs — frameworks, flow, and retest policy — is documented on our methodology page, and our pentest scoping checklist helps you assemble the scope answers a report like this is built on. For how engagements are structured, see Penetration Testing as a Service.
Ready to scope the work?
A 30-minute call with the engineers who will do the testing — not a sales gate.