What a real pentest report looks like

The "two-page test" problem

We frequently inherit clients from other consultancies. The handover artifact is usually a "pentest report" that consists of a CVSS-sorted list of automated findings exported from a vulnerability scanner, with a one-paragraph executive summary saying "X high, Y medium, Z low; please remediate." The first time we see one of these, we ask the client what they paid. The answer is usually €8,000–€25,000.

This is not a pentest report. It is a vulnerability scan that someone rebranded.

If you are buying penetration testing services, here is exactly what to demand from a real engagement.

1. An executive summary that names business risk

The first page should answer "what does this mean for my business?" in plain English. Not "5 highs, 12 mediums, 8 lows." Something like:

"An unauthenticated attacker with internet access could withdraw funds from any user account within four hours, given current authentication controls. The chained vulnerabilities behind this are described in findings 1, 4, and 7. We estimate the worst-case financial impact at €2.4M based on current liquid balances. Recommended action: implement the fix described in finding 4 within five business days."

If your last report did not contain a sentence like that, you bought a scan, not a pentest. The executive summary is the only page your CEO will read. It must tell the truth about business risk.

2. Chained-exploit narratives

Real attackers don't think in CVSS scores. They think in chains: "X gets me Y, which gets me Z." A real pentest report should contain at least one narrative section showing how individually-medium findings combine into a critical impact.

A good chained-exploit section looks like this:

Chain 1 — Unauthenticated funds withdrawal

Step 1: Public sign-up endpoint allows unverified email domains
        (finding 7, severity Medium).

Step 2: Verification-bypass via predictable token in password reset
        (finding 4, severity Medium).

Step 3: KYC enforcement skipped for users created before 2023-01-01
        due to migration code path (finding 1, severity Medium).

Combined impact: Critical — unauthenticated attacker can create
                 an account, take over it, bypass KYC, and initiate
                 withdrawals. End-to-end exploit takes ~4 hours.

Individual findings get a Medium because they're "just" data exposure or "just" a token issue. The chain is what makes them existential. Report quality is measured by how clearly the chains are written.

3. Reproduction steps a developer can follow

For each finding, the report should contain:

• The exact endpoint, parameter, or sequence
• The exact payload or command (often as curl or as a code block)
• Screenshots of the request and the response
• The expected behaviour and the actual behaviour, side by side
• The exact commit / build hash that was tested (so you can correlate to a fix)

If your developer cannot reproduce a finding without messaging the tester, the report is incomplete. The reproduction section should also indicate whether the issue is reliably exploitable or race-dependent / probabilistic — these get different remediation plans.

4. Remediation guidance that is code-level, not policy-level

"Implement proper input validation" is not remediation guidance.

"Change db.query('SELECT * FROM users WHERE id = ' + req.params.id) to use a parameterized query as shown in the snippet below" is.

Bad remediation guidance has phrases like:

• "Adopt secure coding practices"
• "Implement defence in depth"
• "Apply principle of least privilege"

Good remediation guidance has:

• The exact file, function, and line number where the change should land
• A code diff or pseudocode showing the change
• A test you can run to verify the fix
• A statement of what other places in the codebase may have the same bug

The good version takes more effort to write. That's the work you're paying for.

5. A retest commitment

The vulnerability is not closed when the report is delivered. It is closed when the fix is validated against the same TTP, by the same hand that found it.

Every report should come with a free retest within 30 days. If your provider charges extra for the retest, ask why their original finding wasn't testable as-delivered.

We include a retest in every penetration test we sell.

6. A purple-team debrief (for bigger engagements)

For engagements above ~5 days of work, the report alone is not enough. The most valuable deliverable is often the debrief call with your blue team — a one-hour session where the tester walks through every TTP they used, every detection that fired (or didn't), and exactly what your defenders should add to catch the same attack next time.

A red engagement that doesn't end in a purple session is half the value. Insist on it.

What to do before you sign

Before you commit to a vendor, ask:

1. "Can I see a redacted sample report?" — read the first page. If the executive summary names business risk, you're talking to a serious shop. If it lists CVSS counts, walk.
2. "Who exactly will be testing?" — name and seniority. Avoid firms that won't tell you because they shuffle juniors onto contracts.
3. "What's your retest policy?" — should be 30 days, included.
4. "Do you do business-logic testing?" — if they say "we run Burp Suite and Nuclei", you bought a scan.
5. "Can we get a purple-team debrief?" — if they say no, walk.

Most penetration testing buying mistakes are made because the buyer doesn't know what good looks like. Now you do.

If you want a redacted sample of our reports, reply to a scoping call invitation and we'll send one over before the call. No NDA needed.