Your SOC Already Has the Data for Quantitative Risk Analysis. You're Just Not Using It.

Most cybersecurity teams can tell you how many phishing incidents they worked last quarter. They can pull malware case counts from their ticketing system, calculate mean time to remediate, and break down incidents by category with reasonable precision. This is operational data they already collect, already trust, and already report on.

And yet, when those same teams sit down to assess risk — to answer the question executives actually care about, "how much could this cost us?" — they abandon all of it. They open a spreadsheet, assign qualitative labels like "high" and "medium," argue about colors on a heat map, and produce an artifact that tells leadership almost nothing about actual financial exposure.

The gap between what security operations teams measure and what risk teams estimate is one of the strangest disconnects in the profession. The data is right there. It's just not being connected to the right framework.

The Framework That Needs Your Data

The Factor Analysis of Information Risk — FAIR — is the most widely adopted open standard for quantitative cyber risk analysis. Published by the Open Group and supported by the FAIR Institute, it decomposes risk into two branches: how often bad things happen (Loss Event Frequency) and how much they cost when they do (Loss Magnitude). Each branch breaks down further into components like threat frequency, vulnerability, and primary and secondary losses.

FAIR was designed for Monte Carlo simulation. Feed it probability distributions for each input, run ten thousand iterations, and you get a defensible range of probable annual losses — not a color on a matrix, but a dollar figure with confidence intervals.

The problem, as practitioners will tell you, is that FAIR's inputs are typically estimated through calibrated expert judgment. Analysts are asked questions like "how many times per year do you think a threat actor will attempt to compromise this system?" and coached through techniques to reduce overconfidence in their answers. This works. It's certainly better than qualitative labels. But it has an obvious weakness: the estimates are still opinions. Informed opinions, but opinions.

What if they didn't have to be?

Mapping SOC Data to FAIR Inputs

What follows is a proposal, not established practice. As far as I can find, nobody has published a formal methodology for mapping SOC telemetry to FAIR input parameters — despite the fact that the mapping is, in several cases, surprisingly direct. The pieces exist independently. They just haven't been connected.

Consider a mid-size enterprise that processed 500 phishing incidents through their SOC last year. That number — 500 — maps directly to what FAIR calls Contact Frequency: the number of times a threat agent interacted with an asset in the relevant time period. It's not an estimate. It's a measurement, pulled from a ticketing system, validated by analysts who actually worked the cases.

An important distinction: "incidents" here means triaged, confirmed security events — not raw SIEM alerts. A typical SOC generates hundreds of thousands of alerts annually, most of them false positives or informational. Using alert counts as threat frequency inputs would massively overstate risk. The relevant data is what survived triage and was confirmed as a genuine threat interaction.

The mapping extends further than you might expect.

Contact Frequency comes straight from your confirmed incident volume, segmented by threat category. Phishing, malware, unauthorized access, business email compromise — each category has its own contact frequency, derived from actual case counts.

Probability of Action — the likelihood that a threat actor proceeds after making contact — can reasonably be set at or near 1.0 for most incident categories. This sounds aggressive, but think about what "incident" means in this context. If a phishing email was reported, investigated, and logged as an incident, the threat actor already acted. Your incident data is post-action by definition. You're not counting emails that bounced or were blocked at the gateway. Setting this near 100% isn't reckless estimation — it's an honest reflection of what the data represents.

Vulnerability — the probability that a threat event becomes a loss event — can be derived empirically as a success ratio. If your SOC worked 500 phishing incidents and 15 resulted in actual credential compromise, your observed vulnerability is 3%. This is more accurate than asking an analyst to estimate threat capability and control strength independently and hoping the interaction between them produces a realistic number. The outcome data already accounts for the interplay between attacker skill and defensive controls. The success ratio is the vulnerability, measured rather than guessed.

There is a caveat worth stating plainly: you can only count what you detect. If your detection coverage has gaps — and every organization's does — your incident counts understate actual threat frequency, and your success ratio may be distorted by the threats you never saw. This is not a fatal flaw; it's a known limitation that should be acknowledged in any analysis and, where possible, bounded using external benchmarks like the Verizon DBIR or the Cyentia Institute's IRIS dataset.

Loss Magnitude is where most organizations have more data than they realize. Mean Time to Remediate, tracked by nearly every SOC, provides a direct basis for primary loss calculation. If a compromised workstation takes an average of 6 hours to remediate, and you know the burdened labor cost of the incident responder, the productivity cost of the affected employee, and the number of systems typically involved, you can calculate primary loss per incident with reasonable precision.

The formula isn't complicated:

Primary Loss = (MTTR × hourly cost per affected system × systems affected) + incident response labor + direct remediation costs

This covers the immediate, tangible impact: the people who couldn't work, the responders who were pulled from other tasks, the reimaging and credential resets and log analysis.

Where Estimation Still Matters

This approach doesn't eliminate estimation entirely — nor should it try to. Secondary losses remain genuinely difficult to derive from operational data. If a phishing incident leads to a data breach involving customer records, the downstream costs — regulatory notification, legal exposure, reputational damage, customer churn — don't correlate neatly with MTTR or ticket volume. A two-hour incident involving 100,000 records can generate secondary losses that dwarf anything in the primary calculation.

For secondary loss estimation, FAIR's traditional calibrated judgment approach remains appropriate. Reference external benchmarks — the IBM/Ponemon Cost of a Data Breach report, the Cyentia Institute's IRIS dataset, or your own cyber insurance actuarial tables if available — and model secondary losses as a separate distribution with appropriate uncertainty ranges.

There is also a deeper methodological question worth noting. Research by Maillart and Sornette has shown that cyber losses follow heavy-tailed power-law distributions — meaning extreme events are far more probable than standard distributions like Beta-PERT or lognormal would suggest. For most operational risk scenarios (the phishing incidents and malware cases that make up your daily caseload), standard FAIR distributions work well enough. But for modeling catastrophic tail risk — the breach that makes the news — more sophisticated approaches from extreme value theory may be warranted. That's an area where the field is still evolving.

The point isn't to eliminate all estimation. It's to confine estimation to the areas where you genuinely don't have data, rather than applying it uniformly to inputs you could be measuring.

Why This Matters More Than Methodology

There's a practical argument here that transcends the FAIR framework specifically.

Security teams spend enormous effort collecting, validating, and reporting operational metrics. Boards and executives spend enormous effort asking for financial risk quantification. These two activities happen in parallel, in different meetings, using different vocabularies, producing different artifacts — despite the fact that the first activity generates most of the raw inputs the second activity needs.

Connecting them isn't a technical challenge. The math is straightforward. A Monte Carlo simulation over empirical distributions is something any data-literate analyst can implement in an afternoon with open-source tools like pyfair. The challenge is organizational: getting the SOC team that owns the incident data into the same conversation as the risk team that owns the quantification models.

When that connection happens, the results are compelling. Instead of presenting a heat map that says "phishing risk is HIGH," you present a distribution that says "based on our incident data, we project annualized phishing losses between $180,000 and $2.1 million at the 90% confidence interval, with a median of $640,000." One of those statements invites debate about whether "high" should be "medium." The other invites a conversation about whether the risk justifies a specific investment — which is the conversation leadership actually wants to have.

Getting Started

If you want to test this approach, start with a single threat category — phishing is ideal because volumes are high enough to produce stable frequencies. Pull twelve months of confirmed incident data from your ticketing system. Calculate your contact frequency, your success ratio, and your mean time to remediate. Feed those into a FAIR model with appropriate distributions (Beta-PERT works well for bounded inputs), run the simulation, and see what the numbers tell you.

You may be surprised by two things. First, how much more confident you feel in the results compared to traditional estimation. Second, how much data you've been sitting on all along.