Most penetration test reports are too long and say too little. The tool output gets pasted in, every informational notice becomes a "finding", and the one issue that would actually let somebody into your database sits on page 94 between a missing security header and a TLS warning.
A report is a working document for two different audiences, and it has to serve both without pretending they want the same thing.
One page for the people who decide
Whoever signs off the budget needs four things, and they need them before any technical detail: what was tested, whether an attacker could have got in, what the worst realistic outcome was, and what to fix first. That is a page, not a chapter.
It should be readable by somebody who has never heard of SQL injection. "An
unauthenticated visitor could read every customer record in your billing database" lands. "SQLi in
the id parameter, CVSS 9.1" does not, to that reader.
Scope, written honestly
The scope section should say what was not tested as clearly as what was. If the mobile app was out of scope, if testing ran only in business hours, if a WAF was left on, if credentials for one role never arrived - all of that changes what the report means. A reader six months later, or an auditor, has no way to know unless it is written down.
Findings that can be reproduced
Each finding needs enough for a developer to see it happen on their own machine:
- The exact request, including method, path, headers and body
- The response that proves it worked, with the sensitive parts redacted
- Step-by-step reproduction, numbered, with no steps assumed
- What an attacker gains - not the category, the actual consequence here
- A fix that fits the stack in front of them, not a link to a generic article
If a finding cannot be reproduced from the report alone, it will be argued about instead of fixed.
Severity that reflects your business
CVSS gives a common language and it is worth including. It is not the whole answer. The same stored cross-site scripting scores identically whether it sits on an internal admin page two people use or on the public checkout. Say which, and rate accordingly.
Where our rating differs from the raw CVSS number, we show both and explain the gap. Hiding the disagreement helps nobody.
An order to fix things in
Thirty findings with no order is thirty arguments waiting to happen. A good report ends with a sequence: these three this week because they are reachable from the internet without a login; these next, once the first lot are closed; these when the code is next touched anyway.
What does not belong
Raw scanner exports as appendices. Findings nobody verified. Pages of background on what a firewall is. Severity inflated to make the engagement look worth the money. Every one of those makes the real findings harder to find, and a report that is hard to read does not get acted on.
And then the retest
A report is a snapshot. Until somebody has verified the fix, your risk has not changed - you simply know about it now. Ask whether a retest is included before you sign, because a fix that silently failed is worse than knowing the hole is open.
Judging a report
What should we ask to see before we sign?
A redacted sample report from a real engagement, not a template. Look at how the executive summary is written, whether every finding carries reproducible evidence, and whether the scope section says what was not tested. A firm that will not show you one is telling you something.
Is a retest normally included?
With us, yes. Elsewhere, ask before you sign. Until somebody has verified the fix your risk has not changed - you only know about it. A fix that silently failed is worse than an open hole you are tracking.
How long should a report be?
As long as the findings need and no longer. A hundred pages of scanner output pads the invoice and buries the one issue that matters. We would rather hand you twenty pages you read than two hundred you file.
Can we share the report with a customer or an auditor?
Share the closure summary freely; it states what was tested, when, and that the findings were resolved. The full technical report is a working document for your engineers and contains reproducible attack steps, so it should go to as few people as the job requires.
Want this done on your own systems?
We scope the work in writing first, so you know exactly what will be touched and when.
Book a free consultation Back to the blog