PentestReportingMethodologyRisk Management

Anatomy of a pentest report that's actually worth something

A list of CVEs with CVSS scores pasted from a scanner isn't a pentest report, it's a nice-looking PDF. Three things separate one from the other: reproducible evidence, severity adjusted to your environment, and remediation a developer can actually apply. How to spot each before you sign.

By Equipe VorvexPublished on August 22, 20266 min read

The report is the only product left over once the pentest is done. The testing hours turn into that document, and it's the document that will circulate between the development team, the leadership, and often an auditor. Even so, a lot of what the market hands over under the name of a pentest report is the same thing: the raw output of a vulnerability scanner, reformatted into a PDF with the vendor's logo. A list of CVEs, each with its CVSS score, sorted by color. No proof that any of it was exploited, no reading of what it means in that environment, no instruction a developer can follow. Whoever buys it to meet a regulatory requirement usually finds this out late, when the document has to survive a real audit and doesn't.

Side by side comparison of two penetration test reports. On the left, a thin report that is just a sorted list of CVE identifiers each with a colored CVSS score badge, clearly a reformatted scanner export. On the right, a thicker structured report showing a reproducible evidence section with request and response, a context-adjusted severity note, and a remediation block addressed to a developer. — On the left, scanner output dressed up as a report: a list of CVEs sorted by CVSS. On the right, a report that proves, contextualizes, and instructs. Same price, different products.

The report is the product, not a side effect of the test

When someone hires a pentest, what they actually buy is the report. The test itself leaves nothing tangible behind: no one at the company watches the tester work, no one keeps the requests they sent. All that remains is the document, and the value of the whole engagement is locked inside its quality. An excellent test described in a bad report is worth, in practice, whatever the report manages to communicate, which is almost nothing. That's why evaluating a pentest vendor by its report isn't a detail: it's looking straight at the only deliverable you're going to receive.

The trouble is that a scanner report and a real pentest report look alike at first glance. Both have a cover, an executive summary, a list of findings with severities, and a recommendations section. The difference lives inside each finding, and it shows up in three specific places: how the finding is proven, how the severity is justified, and how the fix is described. A report that fails all three is a scan in new clothes. Each one is worth knowing, because they're exactly the three you can check on your own before signing a contract.

Element 1: reproducible evidence, not a generic screenshot

The first thing that separates a serious report from a decorated one is the evidence. A finding without proof is an opinion, and an opinion survives neither a pushback from the development team nor a skeptical auditor. A scanner delivers, at most, the signature that matched and a screenshot. A real pentest report delivers the path: the exact request that was sent, the exact response that came back, and the steps to reproduce it from scratch. If the reader can't repeat the finding with what's written down, it isn't evidence, it's a claim.

http

# Achado: acesso a pedido de outro cliente (BOLA)
# Endpoint: GET /api/v2/orders/{id}

# Passo 1 - autenticado como cliente A (id 8842), lendo o proprio pedido
GET /api/v2/orders/8842 HTTP/1.1
Host: app.cliente.com.br
Authorization: Bearer <token-do-cliente-A>
-> 200 OK  {"order_id":8842,"customer_id":8842, ...}

# Passo 2 - MESMO token, pedido de outro cliente
GET /api/v2/orders/8843 HTTP/1.1
Host: app.cliente.com.br
Authorization: Bearer <token-do-cliente-A>
-> 200 OK  {"order_id":8843,"customer_id":8843,"cpf":"***", ...}

# O token do cliente A leu o pedido do cliente B, com CPF.
# Reproduzido 4 vezes com ids sequenciais. Nenhuma versao
# desatualizada envolvida: e falha de logica de autorizacao.

Real evidence: both requests, both responses, and the note that it was reproduced. Anyone on the team can repeat it and confirm. A screenshot doesn't deliver that.

Anatomy diagram of a single reproducible finding entry in a penetration test report. It labels the parts: a title describing the flaw, the affected endpoint, a numbered sequence of steps, the exact request sent, the exact response received highlighted as the proof, and a note recording that the finding was reproduced multiple times. — The parts of a finding that holds up: title, endpoint, numbered steps, the request, the response that proves it, and the record that it was reproduced. Without the real response, the rest is just a claim.

Element 2: severity adjusted to your environment, not raw CVSS

The second element is severity, and it's where the scanner report deceives the most. The tool assigns the base CVSS score of the CVE and stops there. But the base score is calculated for a generic world, with no knowledge of where that asset sits, what data it holds, or whether it's exposed to the internet. The same finding can be irrelevant on an internal test service and critical on a public API that returns personal data. A report that's useful adjusts the severity to your environment and explains the adjustment; one that just copies the tool's number hands you the job of figuring out what actually matters.

bash

# Como o scanner reporta (nota base, isolada do ambiente):
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N  ->  6.5  "Medio"

# O mesmo achado, dois ambientes reais:

# Ambiente 1 - endpoint interno de homologacao, sem dado real,
#   so acessivel na VPN. Risco pratico: baixo.

# Ambiente 2 - MESMA falha, mas na API publica de producao que
#   retorna CPF e historico de compra do cliente. Dado sensivel
#   sob LGPD, exposto na internet. Risco pratico: alto.

# A nota base 6.5 nao muda entre os dois. O risco real, sim.
# O relatorio serio classifica pelo ambiente 2 e explica por que.

The CVSS base score is the same in both scenarios; the real risk is not. A useful report classifies by context and shows its reasoning, instead of dumping the tool's generic number.

Adjusting severity isn't inflating a score to scare or squeezing it to reassure. It's making the reading the tool can't make, because it doesn't know your topology, your data, and your exposure. An honest report sometimes downgrades a finding the scanner marked as critical, because in your environment it reaches nothing, and explains why. That ability to move severity up and down with justification is one of the most reliable signs that people were thinking, not just a tool running.

Element 3: actionable remediation, written for the person who'll fix it

The third element is remediation, and it's the most wasted. Plenty of reports close a finding with a generic recommendation like "implement proper access control" or "apply security best practices." That isn't remediation, it's the title of the problem repeated. The person who's going to fix it is a developer, and they need to know where in the code, what exactly to change, and how to confirm the fix worked. Good remediation is written for the person at the keyboard, not just for the one presenting the summary to the board.

bash

# Remediacao generica (colada do scanner) - nao acionavel:
"Implemente controle de acesso adequado (OWASP A01)."

# Remediacao acionavel - escrita pra quem corrige:
# No handler de GET /api/v2/orders/{id}, depois de autenticar o
# token, validar que orders.customer_id == token.sub ANTES de
# retornar o objeto. O mesmo controller expoe PATCH e DELETE em
# /orders/{id}: os tres herdam a falha, corrigir os tres.
#
# Teste de regressao: token do cliente A pedindo pedido do B
# deve retornar 404 (nao 403 - o 403 ja confirma que o objeto
# existe). Adicionar esse caso na suite pra nao regredir.

Two sentences about the same finding. The first repeats the problem's name; the second says where, what to change, the forgotten side effect, and how to test. Only the second turns into a commit.

Diagram contrasting two remediation styles for the same finding. On one side, a vague one-line recommendation aimed at a boardroom summary. On the other, a detailed remediation addressed to a developer at a keyboard: the exact location in code, the specific check to add, related endpoints that share the flaw, and a regression test to confirm the fix. — The same fix, two audiences. The vague recommendation is for the boardroom slide; the detailed remediation is the one a developer can turn into a commit the same day.

Why this fails a real audit

More and more companies hire a pentest because a regulation started requiring it. In the financial sector and in supplementary healthcare, among others, periodic security testing became a compliance item, and the report is the proof that it happened. The detail many people discover late is that having the PDF in hand isn't the same as having proof that holds up. A competent auditor doesn't count how many findings the document lists; they ask how each one was proven and what was done afterward. That's where the reformatted scanner report falls apart.

A document that just lists CVEs with CVSS scores doesn't show that a penetration test happened, it shows that a tool ran, which anyone can do on their own. Without reproducible evidence, the auditor has no way to confirm the flaw was real and not a scanner false positive. Without severity adjusted to the environment, there's no way to justify why one finding was treated as a priority and another wasn't. Without traceable remediation, there's no way to link a finding to the fix that came after. The three elements that make a report useful day to day are exactly the three an audit demands, and that's no coincidence: both want the same thing, evidence that the risk was understood and addressed, not a list showing it was merely listed.

How to evaluate the report before you sign the contract

The good news is you can check all of this before closing. Ask any vendor you're evaluating for a sample report (anonymized), a normal request that a serious vendor will honor, and read one full finding with these points in hand.

Each serious finding carries the real request and response, or the exact steps to reproduce, not just a screenshot and the signature that matched. If you couldn't repeat the finding reading the report, it isn't evidence.
Severities are justified by your environment (where the asset sits, what data it holds, whether it's exposed), not just the CVSS number copied from the tool. A report that moves the score up and down with an explanation had people thinking.
Remediation says where and what to change, and how to test the fix, in language a developer applies. "Implement proper control" isn't remediation, it's the problem repeated.
Business-logic findings show up (improper object access, flow bypass, escalation through a combination of permissions), not just outdated versions and misconfigurations. A report that's 100% version CVEs is a scan with a cover.
The report distinguishes what was tested by hand from what was tool-assisted, and states scope and hours. A pure scan has no such distinction to make.

Hiring a pentest without looking at the report format is buying blind the only product you'll receive. Before you pick a vendor, ask for the deliverable template and press on the three elements: reproducible proof, severity in your context, and a fix the developer applies. If you're evaluating or verifying a vendor and want a report that survives an audit instead of just satisfying the requirement, talk to us at vorvex.com.br/orcamento: the conversation starts with what you'll receive at the end, not with the color of the cover.

← Back to blog