The Anatomy of a Pentest Report: What 394 Public Reports Reveal

We analyzed 394 public penetration test reports to answer a plain question: what does this document actually look like once the testing is done? Public reports are not a random sample of the industry. They’re a highlight reel, published voluntarily by firms confident enough in the work to put their name on it. Even so, the shape of that highlight reel tells us something worth knowing about how the industry produces its core deliverable.

What’s in the box

The corpus spans 82 distinct firms and sources, from one-person boutiques to NCC Group and Trail of Bits. The median report runs 26 pages, but the range is wide, from 1 page to 157, with the middle half of reports (p25 to p75) falling between 16 and 43 pages. A single-page memo and a 157-page dossier both count as “a pentest report” in this corpus. There is no standard page count, because there is no standard report.

What is standard is a narrow core. Scope appears in 88% of reports and findings in 85%, which makes them close to universal: the load-bearing walls of the document. Everything after that erodes in a fairly consistent order: a table of contents shows up in 69% of reports, recommendations in 68%, methodology in 65%, an introduction in 57%.

Past that core, prevalence drops faster than most practitioners would guess. Only 54% of reports carry a section explicitly labeled executive summary, despite being the section written for the reader least likely to read the rest of the document. A conclusion appears in 50%, an appendix in 46%, a disclaimer in 42%. A dedicated tools-used section, the part that would tell a reader what automated scanning versus manual testing actually looked like, appears in just 10% of reports, the lowest of any section we tracked.

Read as a sequence, the pattern is not random: it tracks how directly a section serves the deliverable’s core function. Scope and findings answer “what was tested and what did you find,” and firms rarely skip them. Everything downstream of that, summarizing for a non-technical reader, explaining the process, disclosing the tooling, is treated as optional polish rather than a required part of the format.

A pentest report has a skeleton every firm shares, and a body every firm builds differently. Scope and findings are near-guaranteed. Everything that helps a reader trust, contextualize, or verify those findings is optional, and treated that way in practice.

The tooling tells a story

PDF metadata (the Producer and Creator fields embedded by whatever software generated the file) gives a second, more mechanical read on how these reports get made. It is not a field anyone writes for the reader; it is a byproduct of the export process, which makes it a fairly honest signal of the actual production pipeline behind the document.

Across the corpus, LaTeX accounts for 84 reports, LibreOffice or OpenOffice Writer for 79, Microsoft Word for 55, a Chromium HTML-to-PDF pipeline for 36, Google Docs or Skia for 27, Apple Pages for 16, and Apache FOP (an XSL-FO pipeline that renders structured XML into a finished PDF) for 12. Further down the list, iText or Acrobat accounts for 10 reports and ReportLab for 2. Forty-two reports carry macOS Preview in their metadata, meaning the file was opened and re-saved after its original export, often the fingerprint of a final edit pass before publication.

Add the word processors together (Word, LibreOffice, and Pages) and they total 150 reports. LaTeX, the tool most engineers would guess as the industry default for a document meant to look technical, accounts for 84. Word processors outnumber LaTeX by nearly two to one.

That split is not a stylistic footnote. LaTeX is largely the tool of firms whose work reads closer to a technical paper than a client deliverable: versioned, typeset, built for engagements where the report needs to survive close scrutiny of a protocol or a proof. Word and its cousins are the tools of firms that treat the report as a business document: produced under deadline, in software the whole team already has open. Neither approach determines the quality of the underlying testing on its own. But the tool a firm standardizes on says something about how it thinks about the deliverable it ships: whether the report is treated as an engineering output or as correspondence.

Every firm has a reporting fingerprint

Once you group reports by publisher, the tooling data stops looking like noise and starts looking like a signature. Firms don’t pick a format per engagement. They build one production pipeline and run every report through it.

Cure53, the most prolific publisher in the corpus at 67 reports, is LibreOffice Writer 97% of the time. X41 D-Sec is LaTeX 100% of the time; NCC Group is LaTeX in 90% of its 21 reports; iSEC Partners in 81%. QuarksLab and Hackmanit are each LaTeX 100% of the time as well, a cluster of firms whose engagements skew toward cryptography and hardware, where the report needs to hold up like a technical paper.

The productized end of the spectrum is just as consistent. Trail of Bits renders 68% of its 37 reports through a Chromium HTML-to-PDF pipeline, and Consensys Diligence does the same for 100% of its output. Radically Open Security goes further still, generating 80% of its reports through Apache FOP: findings authored once in structured markup, the PDF a build artifact rather than a hand-assembled file. And the pattern holds outside the technical clusters too: Doyensec’s reports are Apple Pages 100% of the time, 7ASecurity’s are Google Docs 100% of the time, and both Hacken and IncludeSecurity publish exclusively through Microsoft Word.

This is what tooling standardization looks like when you trace it firm by firm: a decision made once, at the level of the pipeline, that then shows up consistently across dozens of engagements, not a tool chosen per project, but a house standard. Crypto and hardware auditors cluster on LaTeX. Firms that have productized reporting (Trail of Bits, Consensys, Radically Open Security) render from code or markup rather than composing each report by hand. It reflects engineering culture as much as it reflects the writing itself: some firms treat the report as an artifact worth engineering, not just authoring. Given a stack of anonymized reports, the Producer field alone would let you sort most of them back into their firm of origin: the metadata is closer to a house signature than the logo on the cover page is.

What the format quietly omits

The sections that are rare across this corpus are the ones that close the loop between a finding and its resolution. Only 17% of reports include a retest or verification section, meaning for the large majority of public engagements, the deliverable ends at “here is what we found,” with no documented answer to whether it got fixed.

Severity fares similarly. CVSS appears in only 11% of reports by mechanical text search, and a deeper semantic read puts the figure under 8%. A dedicated risk-rating or severity-definitions section, the part that explains how a firm decided “Critical” means what it means, shows up in just 28% of reports. Most firms are not leaving severity unexplained; they’re explaining it in prose, engagement by engagement, in a way that rarely survives comparison across vendors. A “Critical” from one firm and a “Critical” from another are not guaranteed to describe the same level of risk.

The rest of the evidence chain is uneven in the same direction. Reports are reliably good at telling a reader where a problem lives (93% name the affected location precisely) and most include reproduction steps (80%) or proof-of-concept code (67%). Fewer carry the artifact that would let a reader verify the claim independently: a raw request/response or protocol-level trace appears in 33% of reports, and screenshots in just 24%. The report tells you where the bug is and how to trigger it more reliably than it shows you the evidence a reader could check without re-running the test.

None of this reflects sloppy work. These are, by definition, the reports firms chose to publish, from firms confident enough in their output to attach their name to it. That is precisely what makes the gap worth naming: it means that even the best public examples of the format under-document the two things a reader most needs six months later: whether a finding was actually verified as fixed, and why it was rated the way it was.

A methodology note

This analysis is mechanical, not editorial. All 394 reports were processed for physical structure: page counts, section headers, and language. Authoring tool was inferred from the PDF’s Producer and Creator metadata fields, which is reliable for identifying the rendering pipeline but says nothing about who did the underlying testing or writing, and nothing about quality. Section and language detection ran on the 352 machine-readable reports in the corpus and was automated, not hand-verified section by section, so edge cases in labeling or formatting will have been missed. Where we cite a semantic figure (the CVSS-under-8% number, for instance), that comes from an automated large-language-model read of 349 reports: a directional signal, not a certified human audit. We treat these numbers as evidence of a pattern, not as a precise census. The corpus itself is the public-pentesting-reports repository, maintained by Julio Cesar Fort of Blaze Information Security.

What this leaves for us to build

The gap this data exposes isn’t in the testing. It’s in what the format carries forward. Scope, findings, severity reasoning, and retest state are exactly the things a reader needs to trust and act on a report, and they’re also the things most likely to depend on whether a particular writer remembered to include them. We’re building Tandera so that structure is captured as data from the start, scope, findings, severity reasoning, and retest state all recorded as the engagement happens, so it survives into the final deliverable instead of depending on which sections a firm remembers to write.

Tandera is open to everyone from September 1: a free tier, no card required. For launch month, annual plans are 30% off (SOLO $700, PRO $3,500) with a 7-day money-back guarantee, using code ANATOMY30. Until then, join the waitlist: [TODO: waitlist URL].