Defensible Prioritization: A Story CISOs Can Stand Behind
by James Walta, VP of Product//2 min read/
Two instances of the same vulnerability, on two different assets, should almost never get the same priority. That's the starting point James Walta, VP of Product at Brinqa, uses to explain why prioritization keeps breaking down inside large security teams.
A medium-to-high vulnerability on a critical, externally facing asset tied to a core business function is a very different risk than the same CVE on a dev box. The score doesn't change, the exposure does. Walta's point: once you strip away asset ownership, business function, and exploitability, "none of those really survive prioritization." The framework isn't the problem. What's feeding it is.
Where enterprise data actually breaks down
Walta describes a pattern that shows up across Brinqa's largest deployments: the same asset tracked across three different tools, critical findings duplicated into extra noise, ownership that's inconsistent from one source to the next. None of this comes from negligence. It's what happens as environments accumulate scanners, cloud tools, and CMDB sources over years of mergers and team changes.
Brinqa's approach starts by resolving that duplication: connecting findings to one real asset, one real owner, one real business service, so a security team is working from a single account of risk instead of reconciling three.
Turning a score into a decision someone can defend
Once that connective layer exists, prioritization stops being a number and starts being a case a security leader can make to their own leadership: this finding is a known exploited issue, on an externally reachable asset, tied to a business-critical function, owned by a named team. That's the difference between a ranked list and a decision someone can stand behind when asked why.
Where AI fits, and where it doesn't
Walta is direct about AI's limits here: it can speed up enrichment (inferring an unowned asset's likely owner from similar assets in the same subnet or naming convention, for example) but it cannot manufacture context that was never captured. Feed it incomplete or messy data and it will process that bad context faster, not better.
