Your pentest report has 47 findings. Your board has three questions.
You get two findings from the same pentest. The first is a remote code execution vulnerability with a CVSS of 9.8, sitting on an isolated test server with no production data and no path to anything that matters. The second is a weak authentication finding scored 5.3, on a domain controller with admin paths into the ERP system that holds $40 million in annual revenue and falls under SOX scope. During testing, four admin accounts were compromised.
Same scoring system. Same scale. Wildly different business priority. And if the report sorts findings by CVSS descending, finding A goes on page one and finding B gets buried.
This is the translation gap. It is the dominant failure mode of security reporting today, and it is not a tooling problem; it is a methodology problem.
What executives are actually asking
Every executive asks the same question, in some form: are we good? They will not phrase it that way. They will ask about audit readiness, ransomware exposure, board-reportable metrics, or quarterly risk posture. Underneath the phrasing, three sub-questions sit consistently:
What could actually hurt us? How badly? What should we do first?
If a security report does not answer those three questions, it is not actionable. It is a document, and while it may be technically accurate, professionally formatted, and rigorously defensible, it still fails at its job because nothing in it tells the reader what to do.
Three patterns that drive the gap
Volume over clarity: more findings does not mean more action, and a report sorted by CVSS descending tells you the team did thorough work but not what to fix first.
Vulnerability is not risk: a vulnerability is a technical fact, risk is a business judgment, and reports that conflate the two leave the business judgment to the reader.
Severity is not priority: CVSS does not know what your systems do, who uses them, or whether they hold revenue, so CVSS-sorted reports inverse-correlate with business priority more often than they align with it.
You’ve seen each of these in reports you’ve read or written. The paper walks through how they compound into the dominant failure mode of security reporting today, and what it takes to break the loop.
The shift: score for the business, not the system
The fix is not to abandon CVSS, as it is still incredibly useful. The fix is to add three layers of context on top of it before producing a priority recommendation:
- Asset context (what does the system do, who uses it, what data does it touch),
- Business impact (financial exposure, compliance frameworks, stated risk appetite, operational consequences), and
- Environmental factors (compensating controls, real-world exploitability, signs of active exploitation in the wild).
Layered together, these three contexts produce a business priority rating that frequently disagrees with CVSS-sorted ordering. That disagreement is the point. The paper includes a worked example, a scoring cheatsheet with a prioritization decision tree, and three completed sample intake questionnaires across enterprise tech, SaaS, and healthcare profiles.
What changes when reports become decision engines
These shifts compound. When findings get scored for the business and reports get structured around the three questions executives are actually asking, the conversation around security itself changes.
For internal security leaders, the budget conversation gets a different center of gravity. For external assessment providers, the client relationship shifts from transactional to durable. In both cases, security stops being a cost center and starts being a quantifiable cost-saving function.
That last sentence inverts a position the business has held for decades, and the paper walks through what the shift looks like in practice: the specific budget defense that holds up with CFOs, the longitudinal trend data that turns one-time engagements into recurring relationships, and the five failure modes that derail teams attempting the transition.
Where to start
The translation gap is methodology, not tooling. The methodology is more concrete than most teams realize, and more demanding than most teams expect. The paper covers both.
Download “How to talk cyber risk with nontechnical stakeholders.”
