What a penetration test report looks like
A 19-page illustrative example, free and ungated. Every section explained, including how the weak version fails.
Illustrative, built from synthetic findings. Not a client report: no real company, person or intellectual property appears in it. No email required and no follow-up.
Sorami Consulting publishes this report so a buyer can see the deliverable before commissioning one. Most people evaluating a penetration testing quote have never seen a finished report, which makes it hard to tell a thorough test from an expensive scanner run until the invoice has been paid. The table below is the section-by-section standard we hold our own reporting to, and the third column is what the weak version of each section looks like in practice.
What each part is for.
| Section | What a usable version contains | What a weak version looks like |
|---|---|---|
| Executive summary | What the business is exposed to and what to do first, in language a non-engineer can act on. | A restatement of the finding count by severity. A count is not a summary: it does not say what it means for this organisation. |
| Scope and limitations | The assets, roles and access provided, the method followed, the test window, and what was deliberately out of scope. | A single line naming a tool. If the scope section does not say what was not tested, the report cannot tell you what the result does not cover. |
| Methodology | The standard followed and how it was applied to this system, including where manual investigation went beyond tool coverage. | A logo grid of tool names. Tools do not have judgement, and a tool list does not tell you what the tester actually did. |
| Technical findings | Each finding with the affected asset, reproduction evidence, impact, likelihood, and a severity rationale you can argue with. | Scanner output pasted in with the vendor description left intact and no indication anyone verified it. |
| Remediation guidance | The specific change to make: the controller, the ORM call, the IAM policy. Specific enough for the engineer who has to do it. | Generic advice to sanitise inputs or apply least privilege, which is true of every application and actionable in none of them. |
| Retest record | What was retested, what is confirmed fixed, what is partially addressed, and what remains open. | Absent entirely, so the report describes a moment that has already passed and cannot evidence that anything was fixed. |
Ask for a redacted sample.
Any firm can show you a redacted sample of its own reporting, and the ones that hesitate are telling you something. Read the findings section first: if you cannot tell from a finding what to change on Monday, the report will not survive contact with your engineering team. The longer version of this argument is in what a penetration test report should contain, and scoping the test that produces it is covered in how to scope a penetration test.
Practical answers.
Is this a real client report?
No. It is illustrative, built from synthetic findings. No real company, person, system or intellectual property appears in it. Sorami does not publish client work, redacted or otherwise.
Do I have to give you my email?
No. The download is ungated and there is no follow-up. If you want to talk afterwards you start that conversation, not us.
Can I use it as a template?
You can use the structure. The findings are synthetic and the wording is written for this example, so copying the text would produce a report that describes a system nobody owns.
What length should a real report be?
However long the evidence takes. This example is 19 pages for a scope of one application. Page count is a poor proxy: a long report full of unverified scanner output is worth less than a short one with reproducible findings.
Every free artefact is listed on resources. For the engagement itself, see penetration testing.
Want a report like this for your own system?
Send the assets in scope and your reason for testing. We confirm the approach, fee and schedule in writing before anything starts.
Last reviewed: