Reporting that gets things fixed
A penetration test only reduces risk when someone changes the system because of it. That change starts with your report. This lesson shows you how to structure a report for two audiences at once, write a single finding that a developer can act on, rate it with CVSS without pretending to a precision you do not have, rank by business risk, and close the loop with a de-brief and a retest.
By the end you can
- Structure a report so leaders and engineers each find what they need
- Write one finding with a title, affected assets, reproducible evidence, business impact, likelihood and a concrete fix
- Read a CVSS vector and map a base score to a severity band, and say which version you used
- Rank findings by business risk, not raw CVSS, and avoid false precision and duplicates
- Run a de-brief, retest each finding as fixed, partially fixed or open, and track fixes to closure
The everyday picture
Think of a building inspector who walks through a new apartment block. During the walk she notices many things: a loose stair rail, a gas pipe with no shut-off valve, a fire door propped open, a cracked tile. If she handed the owner a shoebox of photos and said "it is all in there", nothing would get fixed. The photos prove what she saw, but they do not tell the owner what to do first.
So she writes a report instead. The first page tells the owner, in plain words, that the block is safe to occupy once two serious problems are fixed, and roughly what they will cost. The body gives the site manager each problem with a location, a photo, why it matters, and the exact repair. Then she comes back a week later and checks each item again, marking it fixed, half fixed or still open. A pentest report is the same job. The evidence proves the finding, but the structure, the plain-language summary and the retest are what turn a list of problems into repairs.
The report is the product
By the time you write the report, the hard technical work is done. You scoped the engagement (Ethics, law and scoping), mapped the attack surface, and found real weaknesses in the practice systems. But the client did not hire you to find weaknesses. They hired you to help them reduce risk, and they can only do that from what you hand over. A brilliant finding that no one understands, or that sits in a wall of text no manager reads, changes nothing. The report is the deliverable the client pays for, and the only part most of the organisation ever sees.
A good report serves two very different readers at the same time. A leader, the person who signs off budget and accepts risk, needs to know in two minutes how exposed the business is, whether anything must be fixed before a launch, and what it will take. An engineer needs enough detail to reproduce each problem, understand why it matters, and fix it without a second meeting. Write for only one of them and the other stops reading. The structure below lets both find their level without wading through the other's.
One habit underlies the whole document: every claim is backed by evidence, and every piece of evidence stays inside the lab. You show the vulnerable pattern, not a weaponised exploit, and you redact anything that would let a reader attack a live system. The report is written to get a fix built, not to teach an attack.
Quick check
Your test of the practice Partner app found eight issues. You are short on time before the deadline. Where should your effort go?
The report is what the client acts on, and leaders decide from the summary while engineers fix from the detailed findings. Raw tool output without analysis is noise, and a count of findings is not a measure of value. A ninth low-severity issue helps far less than making the important issues clear and fixable.