Skip to content
All Writeups
For Leadership

How to read a penetration test report as a product leader

A findings list isn't a to-do list. A framework for triaging pentest output by business impact instead of CVSS score alone.

February 27, 20267 min readBy Sakil Ahamed Gayen
ReportingProduct LeadershipRisk

A penetration test report is not a to-do list in the order it was written. Findings are typically ordered by discovery, or by CVSS score — and CVSS, useful as it is, was never designed to encode your product's specific business risk.

When I hand a report to a product leader, I ask them to sort findings a second way, alongside severity: by blast radius. A critical finding in an internal admin tool used by three trusted employees is a very different risk conversation than a medium finding in a public-facing checkout flow touched by every customer.

The second axis worth tracking is exploit complexity relative to your actual threat model. A finding that requires a sophisticated, multi-step chain is a different priority than one exploitable by anyone who notices a predictable URL pattern. Good reports should already separate these for you — but leadership shouldn't hesitate to ask the tester directly: 'if you were a realistic attacker against us specifically, which three of these would you use first?' That question, more than any score, is what should shape the remediation order.