Early in my security engineering career, I watched a CISO present vulnerability findings to the board in a format that had been translated three times: scanner output → engineering summary → security program update → board slide. By the time it reached the board, "we have 847 open critical findings" had become "our exposure risk remains within acceptable thresholds with remediation on track." The board nodded. The engineering team was drowning.
The translation wasn't dishonest. It was a genuine attempt to communicate the right level of abstraction to the right audience. The problem was that the translations were lossy in different directions for different audiences, and there was no shared artifact that let both groups work from the same underlying truth.
That disconnect — CISO needs board-ready risk narrative, engineers need precise actionable tickets — is where most vulnerability programs stall. This post is about building a translation layer between those two modes that doesn't require anyone to lie, simplify dishonestly, or maintain two completely separate realities.
What CISOs Actually Need to Report Upward
CISOs present to board risk committees, audit committees, and executive teams. The questions those audiences ask are consistently a small set:
- Are we more or less exposed than last quarter?
- Are there specific risks to the business we should be concerned about right now?
- What are we doing about it, and is the program working?
- How do we compare to peers? (sometimes asked, rarely answerable honestly)
Notice what's absent: CVE IDs, CVSS scores, scanner coverage rates, finding counts. Boards are not equipped to reason about whether 847 critical findings is a lot or a little. They need trend, severity of business consequence, and evidence that the security program is functioning.
The CISO's job is to translate technical risk into business consequence language: "We have 12 findings in our payment processing cluster that are actively targeted in the wild. We're on track to remediate 9 of them by end of month. The other 3 have compensating controls in place and are scheduled for the next patch window." That's board-appropriate. It's also completely derived from the technical finding data — no fiction required.
What Engineers Actually Need to Act
The engineer assigned a vulnerability remediation ticket needs the opposite: maximum specificity, minimum narrative. What they want:
- Exact asset: hostname or IP, not "payment processing cluster"
- CVE reference and a one-line description of the vulnerability class
- Fix instruction: which package to upgrade to, which config parameter to change, or what compensating control to apply
- Why this one first: asset criticality, exploit status, SLA deadline
- Verification step: how to confirm the fix worked
What engineers do not need: a paragraph explaining the business risk in board language. They trust that the prioritization is correct. They want to close the ticket and move to the next one. Every sentence that isn't actionable is friction that slightly increases the probability the ticket stays open longer than it should.
The Shared Layer Neither Audience Sees Directly
The problem isn't that CISOs and engineers need different formats. That's fine and expected. The problem is when the two formats aren't derived from the same underlying data model, which means they can drift.
Consider a scenario: a security team at a growing cloud-infrastructure company with about 1,800 assets. The CISO's weekly report said "20 critical findings open." The engineering remediation queue showed 34 critical-severity tickets. The discrepancy wasn't fraud — the CISO was reporting from a filtered view that excluded findings tagged as "accepted risk," while the engineering queue showed everything unresolved. Both views were legitimate. Neither team knew the other was looking at different numbers, and nobody had explicitly aligned on what "critical findings open" meant in a shared definition.
The fix isn't a new meeting. It's a shared underlying metric with explicit, documented filter logic. "Critical findings open" means: severity Critical or High, not in accepted-risk status, first seen more than 7 days ago, on assets with business function tag not equal to dev/test. Both the CISO view and the engineering queue are derived from this same filtered set, just displayed at different levels of aggregation.
Building the Translation Layer in Practice
The translation layer has three components: a shared finding classification, a risk narrative template, and an escalation trigger.
Shared finding classification. Every finding in your system should have at least two classification dimensions beyond CVSS: business function of the affected asset (customer-facing, internal tooling, data storage, build infrastructure), and exploit status (no known exploit, PoC available, active exploitation in the wild per CISA KEV or threat intel). These two dimensions let you generate both the engineer's ticket context ("this asset is customer-facing, exploit kit active") and the CISO's board narrative ("3 findings on customer-facing assets with active exploitation") from the same underlying record.
Risk narrative template. The CISO view doesn't need to be hand-written every week. It can be generated from the finding data with a consistent template: "As of [date], [N] findings are open on customer-facing assets, of which [M] have confirmed active exploitation. [X] findings closed this week, reducing our Vendrsec Risk Score from [A] to [B]. [Top 3 specific findings or finding classes by business impact]." The template forces specificity without requiring engineering to explain context the CISO already has.
Escalation trigger. The translation layer needs a mechanism for findings that require both audiences simultaneously: an actively exploited critical CVE on a business-critical asset. These can't go through the normal weekly reporting cycle. They need a direct CISO notification and an immediate engineering ticket, generated at the same time from the same event. The SLA for this class should be measured in hours, not the standard 30-day remediation window.
Where This Breaks Down
We're not claiming the translation problem fully disappears with good tooling. There are genuine tensions that can't be normalized away.
The first is organizational: if the security team lacks sufficient headcount to remediate at the rate new findings arrive, no reporting framework makes that disappear. The posture drift score will trend upward, the CISO will have to report a deteriorating trend, and the translation layer will faithfully communicate that. This is actually a feature, not a failure — honest reporting forces the resource conversation rather than burying it in abstracted metrics.
The second is timeliness: boards meet quarterly. Critical findings need remediation in days. The translation layer can produce a quarterly summary, but the actual risk management happens at a cadence that's invisible to board-level reporting. This is fine. Board reporting should focus on trend and program health, not real-time operational status.
The shared underlying data model is what lets both conversations be honest. Engineers work in CVEs and tickets. CISOs work in business risk narratives. As long as both are derived from the same source of truth, the translation is just formatting — not spin.