Most CISOs know the moment. You're in the room with the CFO or the board, you've walked through the threats you're tracking, you've explained what you're protecting, and then someone asks: "What's our actual exposure? In dollars?" And you don't have an answer. You have a risk register with red/yellow/green ratings. You have a vulnerability count. You have a compliance scorecard. None of that answers the question.
Risk quantification is the practice of translating security risk into financial terms your decision-makers can act on. It isn't a new idea. Most security programs either skip it or implement it so poorly that it changes nothing.
What quantification is, and what it isn't
Quantification is not a single tool or model. It's a structured way of reasoning about probability and impact.
The output you're aiming for reads like this: a ransomware event affecting production would cost between $1.8M and $4.2M, with a 23% probability over the next 12 months. That estimate supports a real conversation about whether a $400K investment in backup infrastructure and detection tooling makes sense. A red cell on a risk matrix cannot.
What quantification is not: a precise prediction of what will happen. Anyone selling you certainty here is overselling. The value of a range estimate isn't that it's exact. It forces you to be explicit about your assumptions, it gives leadership something to react to other than colors, and it lets you compare risks against each other and against the cost of fixing them.
The FAIR model, briefly
FAIR (Factor Analysis of Information Risk) is the most widely used framework for cyber risk quantification. It isn't the only approach, but it has the most practitioner adoption, and it's the one your CFO is most likely to have heard of.
FAIR breaks risk into two components: Loss Event Frequency and Loss Magnitude.
Loss Event Frequency is how often you expect a loss event in a given period. It's itself a product of Threat Event Frequency (how often an actor attempts something) and Vulnerability (how likely they are to succeed when they try).
Loss Magnitude is what a successful event costs. It splits into primary loss (direct costs like incident response, recovery, notification, regulatory fines) and secondary loss (reputational damage, customer churn, litigation, and stock impact where it applies).
You don't need a full FAIR model for every risk. For the risks that could materially affect your business, you do.
Where most programs fail
They start with the controls, not the business
The most common mistake is building a risk register from a framework audit (CIS Controls, NIST CSF, ISO 27001) and treating control gaps as risks. A control gap isn't a risk. It's a potential contributor to one. Whether it matters depends entirely on what that gap lets an attacker do to your specific environment. Two companies can have identical control gaps and face completely different exposure depending on their threat profile, their data, and their architecture.
They use point estimates instead of ranges
If your model outputs a single number, say "our ransomware exposure is $2.3M," someone will ask how you got it, and the answer won't convince them. The right output is a range with confidence intervals. Your P10 is the low end, your P90 the high end. Presenting a range signals that you understand the uncertainty in the estimate, which builds credibility rather than undermining it.
They can't connect the estimate back to controls
If your quantification model lives in a spreadsheet disconnected from your security telemetry, every estimate is a guess dressed up as analysis. The numbers have to be defensible, which means the inputs have to be real: actual patch latency from your vulnerability management tool, actual coverage gaps from your EDR, actual mean time to detect from your SIEM. Without that, you're making up a number and calling it math.
They try to quantify everything
Quantification takes time. Applied to your full risk register, it becomes a project that stalls before it produces anything useful. Start with the five risks that would cause the most business disruption if they materialized. Quantify those well. Build the muscle before you try to scale it.
The inputs that actually matter
A useful quantification needs four things.
Threat profile
Who is likely to target you, and what can they do? A healthcare company faces different actors than a fintech. Nation-state groups have different success rates against different targets than opportunistic ransomware crews. Your threat profile shapes the frequency side of the estimate.
Control effectiveness data
Not whether a control is deployed, but whether it's working. A 94% endpoint coverage rate sounds fine until you realize the uncovered 6% includes three executives with full domain access. Control effectiveness is a KRI problem. The signal has to come from what your tools are actually reporting.
Historical data
Your own incident history, if you have it, is the best input available. If you don't, and most SMBs don't, industry loss data from the Advisen loss database, the Verizon DBIR, or insurance carrier actuarial data can anchor your estimates.
Business context
What would a four-day operational outage actually cost this organization? The security team rarely knows precisely. Your CFO does. That's one of the best reasons to bring finance into the quantification process: it forces the right conversations before something goes wrong.
Communicating the output
The goal is a quarterly risk statement that reads something like this:
Our top three quantified risks this quarter are ransomware affecting production ($1.8M to $4.2M, 23% annual probability), supply chain compromise via a tier-1 vendor ($900K to $2.1M, 14% annual probability), and credential-based account takeover leading to financial fraud ($400K to $800K, 31% annual probability). Across these scenarios, our current control posture reduces annualized expected loss by roughly $1.1M against baseline. Three KRIs, endpoint coverage rate, privileged account review cadence, and vendor risk assessment completion, are in amber and are driving the high end of these estimates.
That statement answers the board's actual question. It gives the CFO something to work with. And it creates accountability for the security team to move those KRI signals.
A word on tools
There are dedicated risk quantification platforms (RiskLens is the most prominent FAIR-native one). They're useful if you're running a large, mature program. For most SMB and mid-market teams, the math fits in a structured spreadsheet or a purpose-built risk intelligence platform that pulls KRI values from your existing controls.
The tool matters less than the inputs. A rigorous spreadsheet running on real control data beats a sophisticated platform running on guesses.
Real inputs, real numbers.
Draxis reads your existing security controls, extracts KRI values continuously, and maps them to financial exposure ranges, so when someone asks what your actual risk is, you have a real answer. No new agents, no rearchitecting. Built for the team that already has a stack and needs to know what it's saying.
Start your risk intelligence assessment →