The anatomy of a finding worth paying for

A penetration test produces one durable artefact: the report. Everything else, the access, the tooling, the fortnight of work, exists to produce it. Which makes it strange how many reports contain findings an engineer cannot act on.

The failure is rarely technical accuracy. It is that the finding was written for the person who found it rather than the person who has to fix it.

The five parts that matter

A finding an engineer can pick up on a Monday morning contains all of these, and a finding missing any one of them will generate a follow-up email.

1. What is wrong, in one sentence. Not the vulnerability class. The specific broken thing in this specific system. "The export endpoint does not scope mandates to the authenticated tenant" beats "Broken Object Level Authorisation" every time
2. How to reproduce it. The exact request, the account used, the expected response and the actual response. If a developer cannot reproduce the issue from the report alone, the report has outsourced the hard part back to them
3. What it lets an attacker do. Concretely, in the language of the business. "Read every customer's payment mandates" not "may lead to unauthorised information disclosure"
4. Why the severity is what it is. Show the reasoning, not just the score. A CVSS vector with no explanation is a number the reader has to take on faith, and they will argue with it precisely because they cannot see how you got there
5. The change to make. Name the fix. "Apply the existing tenant-scoping helper to this route" is remediation. "Implement proper access controls" is a restatement of the finding wearing a different hat

The tells of a padded report

Length is the usual disguise. A few things worth looking for when you are evaluating a firm's sample report:

• Findings that are really scanner output. Missing security headers listed as four separate findings is one finding and a configuration change
• Severity inflation. If everything is high, nothing is. Check whether the criticals genuinely have a short exploitation path and a real blast radius
• Generic remediation. Advice copied from the vulnerability class rather than written for the system tested
• No negative results. A good report says what was tested and found solid. Without that, you cannot tell the difference between a clean area and an untested one

Why we write them twice

Every engagement we deliver includes a technical report and a separate executive summary, because the two audiences need genuinely different documents rather than the same document at two lengths.

The engineer needs reproduction steps and the specific change. The board needs to know what could have happened, what it would have cost, and whether it is fixed now. Trying to serve both in one document reliably fails both.