Risk Is (or Should Be) the Business Language of Vulnerability Management
I spent time recently with a CISO whose situation I suspect you may recognize. She came up through vulnerability management and knows the discipline cold. Her team can produce data all day: CVSS scores, exploitability signals, counts of criticals, context on what is internet-facing or holding sensitive data. What she found harder was turning any of that into a conversation her CFO and board would act on. The gap she kept describing was not in her tooling. It was in language. She had the technical facts. She did not always have a shared way to express what those facts meant to the business.
That gap is worth taking seriously, because it is not really hers alone. It is the central communication problem of cybersecurity, and closing it is a skill that any security professional can learn.
Two languages that do not meet
Security speaks in severities. The business speaks in dollars, priorities, and trade-offs. Those are two different languages, and most of the friction between security and the business comes down to the fact that they rarely meet in the middle.
The experience of this CISO made this concrete. At one point she had a tool that produced a likelihood and a cost figure, but the figure came out of a black box. She could not explain how it was calculated, which meant she could not defend it, and she was not going to put a number in front of her business partners or the board that she couldn’t stand behind. So she fell back on proxies: trends in her bug bounty payouts, hard-dollar savings from reducing the cloud storage of her security infrastructure, or anything she could tie to a cost the business already recognized. That instinct is exactly right. She was reaching for the business's language. The trouble is that those proxies only work when a hard cost happens to be visible, and most cyber risk does not come with a price tag attached.
Another problem with emphasizing cost reduction is that it misses the main point of cybersecurity investments: to avoid future costs (or harm) to the business. It positions cybersecurity as a cost center, and not a creator of value. (Indeed, being treated as a cost center is the same frustration many CIOs work so hard to avoid.) Cybersecurity’s biggest value driver is risk reduction, not cost reduction.
Being able to express security work in terms of risk reduction, by showing the reduction in probable frequency and/or probably magnitude of loss, is what transforms cybersecurity into a valued business partner. Indeed, risk is the one language that both cybersecurity leaders and their business partners share because it’s expressed in business terms.
Risk fluency is a skill, not a program
Here is the misconception I most want to dispel. People hear FAIR and picture a large team, Monte Carlo simulations, and dedicated analysts producing precise loss curves. Programmatic quantification at that level does tend to live in larger organizations, and if you have it, wonderful. But treating that as the price of entry gets the whole thing backward. The most valuable part of FAIR is not the simulation engine. It is the structured way of thinking and the shared language that comes with it, and that is a skill, not a budget line.
Jack Jones, who created FAIR, has often made this point about his own early use of it. Long before he was putting dollar figures on anything, he used FAIR qualitatively, as a way to have better, more meaningful conversations with his senior leaders and his line-of-business partners. The taxonomy alone does real work by serving as a shared language. Separating how often a loss event is likely to happen from how much it would cost when it does, or assessing a control’s specific impact on the business’s susceptibility to an attack, sharpens a conversation before a single number is calculated. It gives you a place to put each fact, and it exposes the questions you have not answered yet.
That is the skill worth building, and it is learnable. You do not have to become a certified analyst to speak risk credibly. You have to learn the model well enough to think and talk in it. I would argue that speaking risk is no longer optional for any cybersecurity leader. It’s core to the job.
What this means specifically for vulnerability management
Let’s come back to vulnerability management, which is where my conversation with this CISO was centered. Two payoffs matter most for VM use cases.
The first is justifying investment. Instead of walking into a budget conversation with thousands of critical findings, you frame the few that genuinely matter as a loss scenario the business already worries about. You may not have a defensible dollar figure yet, but even directional framing beats a severity count. Saying that you carry a high likelihood of a serious loss because you run end-of-life systems the vendor no longer patches is a narrative a CFO can follow and challenge. From there, the structure lets you get more precise when a decision warrants it: this exposure represents roughly this much probable loss, mitigation costs roughly this much, here is the trade-off. That is a business case, not a vulnerability report. And when the CFO challenges the logic or any numbers you’ve provided, you can lean on the structure of your analysis. If you need to dig deeper into those numbers, the FAIR methodology makes it possible.
The second is aligning priorities with your business partners. Vulnerability management runs at machine scale, across thousands of findings. The business cares about a handful of big scenarios, usually the ones a board member has already asked a pointed question about. The scenario lens is what connects the two. It lets you translate a technical finding into the language of a breach scenario leadership already has in mind, and it forces the one question only the business can answer, which is how large the harm would actually be. How much does an hour of downtime cost? How bad is the loss of a particular set of records? You cannot read that off a scanner. When you ask the business to supply it, they not only own the data, they start to own the decision. That is where the principle we teach, that the business owns the risk and security advises them, stops being aspirational and becomes real. You stop being the department of no and become the partner who framed the choice in the business's own language and let them make the call.
Reserve risk quantification for the decisions that deserve it
Speaking risk does not mean quantifying everything. That would destroy the speed and scale vulnerability management depends on, and it would be a waste. Most findings should be handled fast and automatically, patched across the fleet or fixed in the delivery pipeline before they ship. The value of the language shows up on the exceptions: the systemic problem that appears everywhere at once, or the control decision that is really a business trade-off. The CISO I spoke with rarely needs a dollar figure to justify patching, because when her team calls something critical, the organization moves.
Where she struggles is the harder call, like tightening authentication in a way that adds friction for customers. That is not a vulnerability question at all. It is a risk question, a weighing of the cost of friction against the cost of the harm it prevents, and it is exactly the kind of decision the language of risk was built for. I have seen financial-services firms use the same reasoning to push back on a mandated control by showing that the added friction outweighed the residual risk it was meant to address.
The language we should be speaking
The CISO I talked with had the technical mastery for her job. What will help her most now is the language to justify technical decisions to the people who hold the budget and own the risk. That is the gap I see across our profession, and it is not a resourcing problem. It is a skills and language problem, and skills can be built.
Risk should be the default language of cybersecurity, the common tongue between the people who find and fix the problems and the people who decide what they are worth. We are not there yet as an industry, but nothing stands between a security leader and learning it. The FAIR Institute publishes the standards openly, and there are many very accessible books on the topic. Great examples of the latter are Jack Jones’ Measuring and Managing Information Risk: A Fair Approach (coauthored with Jack Freund) and our good friend Tony Martin-Vegue’s From Heatmaps to Histograms: A Practical Guide to Cyber Risk Quantification.
Speed and scale keep the vulnerabilities in check. Fluency in the language of risk is what turns that work into decisions the business will fund and own. It is a skill worth building, and it is well within reach.
