Why your pentest report shouldn't be a PDF graveyard

Every security team has one: a folder of penetration test reports, each opened twice. Once the day it arrived, and once a year later to send to the next auditor. In between, the findings just sit there, aging.

The waste is enormous. Companies pay good money for testing, and then the delivery format quietly guarantees that half the value evaporates. We think the report format is not a detail. It is the difference between testing that changes your risk and testing that documents it.

How findings actually die

Watch what happens to a typical finding after the report lands. Someone skims the PDF and copies the criticals into tickets by hand, usually losing the reproduction steps in the process. The mediums and lows never make the jump at all. Three sprints later, an engineer picks up a vague ticket titled “Fix IDOR in invoices endpoint,” cannot reproduce the issue from the two-line description, and closes it as cannot-reproduce.

The PDF did not fail to communicate. It communicated once, to the wrong audience, in a format that cannot be assigned, tracked, or verified.

Nobody in that chain did anything wrong. The format did.

What we deliver instead

We still produce a document, because auditors, customers, and boards need one. But the document is a summary of the engagement, not the delivery mechanism for the work. The work ships differently:

• Findings as tickets, in your tracker. Each finding lands in Jira, Linear, or GitHub Issues with reproduction steps, evidence, affected assets, and a suggested fix. Assignable on day one, no transcription step.
• Severity in your context. A finding on an internal tool behind SSO is not the same risk as the same bug on your public API. We rate against your architecture and data, and we write down why, so your team can argue with us. Sometimes they win, and the rating changes.
• Same-day criticals. Anything dangerous gets a call the day we confirm it, not a spot in a report two weeks later.
• A retest that is part of the deal. Every engagement includes a retest window. Findings move to a verified-fixed state by us, not by the optimism of whoever closed the ticket.

The uncomfortable metric

If you want one number to judge your testing program by, do not count findings. Count the median time from finding delivered to fix verified. Finding counts reward noisy reports. Time-to-verified-fix rewards exactly what you actually want: closed holes.

When we started measuring engagements this way, our own behavior changed too. Reproduction steps got sharper, because vague findings take longer to fix. Severity inflation stopped, because a report full of criticals that are really mediums destroys the metric. Incentives work on vendors as well.

What to ask your next vendor

You do not need to hire us to benefit from this. Ask any vendor three questions before signing:

1. Can findings be delivered directly into our issue tracker, with reproduction steps intact?
2. How is severity decided, and will you adjust it when our context changes the risk?
3. Is a retest included, and what does “fixed” mean in your reporting?

A vendor with good answers will make your program better regardless of who they are. A vendor who bristles at the questions has told you something useful too.