Let me tell you something that will make pentesters uncomfortable. Most penetration test reports are useless.
Not because the testing was bad. Not because the findings weren't real. But because the report, that 80-page PDF with a red/amber/green table and a CVSS score nobody asked for, ends up sitting in a shared drive collecting digital dust while the vulnerabilities it describes stay wide open.
I've been on both sides of this. I've written the reports. I've watched them get ignored. And after 10 years in the field, I've started being very honest with clients about why this happens and what to do instead.
Here's the uncomfortable truth.
1. Nobody reads 80 pages
I don't care how good your writing is. An 80-page technical report will not be read by the people who need to act on it.
The CISO might skim the executive summary. The developers who need to fix the SQLi in your login endpoint will never see it. The sysadmin who needs to patch that misconfigured SMB share is two helpdesk tickets deep and hasn't opened their email in three hours, and probably wants to avoid Outlook at all cost.
Reports written for everyone are read by no one.
The fix: Write three documents, not one. A one-pager for the board using risk language and business impact. A technical summary for security and IT leadership. Individual fix tickets for each finding, addressed directly to whoever owns the asset.
If your pentest vendor delivers a single 80-page PDF, ask for more. And while this may not be possible for all pentest vendors, most will be flexible on the way the report is outlined if you ask. I can only talk for myself, but I will happily put in some extra effort in specializing a report to a client if it means a higher likelihood of the report being used internally later.
2. CVSS scores don't reflect your reality
A Critical CVSS 9.8 on a server that's air-gapped and only accessible from your internal network is not your biggest problem. A Medium CVSS 5.3 on your public-facing customer portal that handles payment data might be.
CVSS scores measure vulnerability severity in a vacuum. They don't know your environment. They don't know what's internet-facing. They don't know which systems hold your crown jewels. The same goes for the severity on your vulnerability scans. No, "SSL Version 2 and 3 Protocol Detection" from Nessus is likely not as critical on an internal service as the plugin wants you to think.
I've seen clients burn through their remediation budget patching Critical CVSSs while the actual attack path, a chain of Medium-severity misconfigurations that leads straight to domain admin, goes untouched.
The fix: Ask your pentest team to prioritise findings based on your specific attack surface and business context, not generic severity scores. What's the actual impact if this gets exploited? What's the likelihood, given your environment? That's the conversation worth having.
3. The report is a snapshot, not a programme
Here's something vendors don't advertise. The moment your pentest report is delivered, it starts going out of date.
New code gets deployed. Infrastructure changes. A developer pushes a dependency with a known vulnerability. A cloud misconfiguration sneaks in during a Friday afternoon sprint.
A point-in-time pentest tells you where you were vulnerable in January. It says nothing about March.
Companies that treat penetration testing as an annual checkbox are not running a security program. They're running a compliance exercise.
The fix: Build continuous testing into your security posture. Combine annual full-scope engagements with continuous automated scanning, quarterly targeted tests on high-risk areas, and red team exercises that simulate real attacker behavior. The goal is to know your current exposure, not your exposure six months ago.
4. Remediation has no owner
The report gets delivered. Everyone nods. And then nothing happens. Because nobody explicitly owns the remediation. The security team thinks IT will handle it. IT thinks it's a developer problem. The developers are three sprints behind and nobody flagged it in Jira.
Penetration testing without a remediation process is just an expensive way to document your problems.
The fix: Before the engagement starts, agree on a remediation workflow. Every finding should have a named owner, a deadline, and a ticket in whatever system your teams actually use. Not a PDF finding. A real ticket. Treat it like a bug, because it is one.
5. You never verified the fixes worked
Developers patch things. Infrastructure gets updated. But security misconfigurations have a way of coming back through configuration drift, re-deployments, or copy-pasted code from the old vulnerable version.
Without a retest, you don't know if you fixed the problem or just changed it.
The fix: Build retest time into the engagement budget. It doesn't need to be a full retest. Targeted retesting of the specific findings that were remediated is usually sufficient. Some vendors include this; if yours doesn't, ask for it.
What good looks like
A penetration test that actually improves your security looks like this:
- Scoped to your actual risk: not just "test everything", but focused on what matters.
- Delivered in a format your teams can act on: not a single PDF, but actionable outputs per audience.
- Prioritized by business impact: not CVSS score.
- Tracked through remediation: findings in your ticketing system, with owners and deadlines.
- Retested: because patching and fixing are not the same thing.
- Repeated: because your environment changes faster than your annual pentest cycle.
Security is a process, not a report. The penetration test is the start of that process, not the end.