What a penetration test report should actually contain

If you are commissioning a penetration test for the first time, you are in an awkward position: you are paying for a document you have never seen, produced by a process you cannot evaluate, to find problems you do not know exist. Quotes vary by a factor of ten and every provider's website says the same things.

So here is the honest version. The report is the product. Everything else — the testing, the tooling, the credentials on the provider's website — only matters insofar as it produces a document your team can act on. Judge providers on their reporting and you will judge them correctly.

Ask for a sample before you buy

Any provider should be able to show you a sanitised sample report. If they cannot, that tells you something. Mine is here — a fictional target, but real in every other respect.

Read it the way your engineers would. Could they fix the first finding from the report alone, without a call?

What a good report contains

An executive summary that a non-technical person can act on

The first page should tell someone who will never read the rest what the risk actually is, in business terms. Not "3 high, 5 medium." Something closer to: anyone on the internet can take over any customer account, including administrators, in about forty seconds.

If the summary is a severity table, it was written for the provider's convenience, not yours.

An explicit statement of what was not tested

This is the section that separates honest reports from marketing. Scope limitations are inevitable — staging differs from production, a WAF is configured differently, credentials for one role arrived late. A report that pretends complete coverage is more dangerous than one that admits gaps, because you will make decisions believing you are covered.

My reports state limitations in the scope section and repeat them in the appendix. If a rate-limiting control could not be assessed, the absence of a rate-limiting finding must not be read as safety.

Findings ranked by impact, not by scanner severity

CVSS is a useful input and a terrible output. A technically "medium" issue that exposes your whole customer table is not a medium. A technically "high" issue sitting behind three other controls is not a high.

A good report adjusts for your context and says that it has done so, with reasoning you can disagree with.

Reproduction steps that actually reproduce

Every finding should contain enough detail that one of your engineers can trigger it themselves. Exact request, exact response, exact conditions. If a finding cannot be reproduced from the report, it cannot be verified as fixed, and you are taking the fix on faith.

Remediation your engineers can implement

Not "implement proper access control." Something like:

-- scope the query, do not filter after fetching
SELECT * FROM orders WHERE id = $1 AND customer_id = $2;

And where the same class of bug will recur, guidance on preventing recurrence — usually a test rather than a code-review habit.

What went right

A report that is exclusively bad news is a sales document. Real assessments find things done well, and recording them matters: it tells you where your engineering practice is sound, and it stops the report reading as an argument for buying more services.

An attack chain, where one exists

Individual findings understate risk. Three medium issues that compose into full compromise are, together, a critical. Good reports show the path explicitly, because that is what determines your fix order.

What a retest is, and why it should be included

A finding is not closed because a fix was deployed. It is closed because the original reproduction steps no longer work. Any provider should retest and re-verify — and it should be in the price, not an upsell. An engagement that ends with unverified fixes has not reduced your risk; it has only documented it.

Questions worth asking a provider

• Can I see a sample report?
• Is retesting included, and how long do I have to use it?
• Will manual testing be performed, or is this a scan with a review pass?
• Who writes the report — the person who did the testing?
• What happens to my data and your evidence after the engagement?

The last one matters more than people expect. Ask what is retained, where, and for how long.

The uncomfortable truth about cheap tests

There is a tier of the market — and it is a large tier — where a scanner is run, the output is reformatted, and a logo is applied. It is fast and cheap and it will satisfy a compliance checkbox.

It will not find the authorisation flaw in your order API, because scanners do not understand which customer should be allowed to see which order. That determination requires someone to hold your application's logic in their head. This is the entire difference, and it is why price and value diverge so sharply in this market.

If a compliance checkbox is genuinely all you need, buy the cheap one and spend the difference elsewhere. Just know which one you are buying.

---

If you want a straight answer on scope and price for your own systems, the estimator gives you a range in about thirty seconds, or book fifteen minutes and I will tell you honestly whether you need a test at all.