The other half of a risk score
Two employees, yet only a single number
An intern and the CFO both click on a phishing simulation, and both ignore a Data Loss Prevention (DLP) warning later that month. The behaviors are identical… the risk really isn't.
When we talked to security leaders at the companies we work with, the same frustration kept surfacing: the risk scores they look at today would give these two employees the same score. But security teams read these scores as an answer to two questions at once. First, how likely is someone to engage in risky behavior? And second, how much does it cost the organization if they do? Most scores today only model the first seriously. The second falls onto the plate of the security admin trying to make sense of the score, who has to look at the number, cross-reference role and access in their head, and decide whether it actually matters. Half the job of the risk score ends up adding work for teams that are already under-resourced and overworked.
That bothered us enough to build ours so those teams can actually use it to measure employee risk and reduce it. Cimento's risk score models both and lets you decide how they come together.
What a risk score should compute
If a risk score is going to answer both questions, it has to be built out of two parts. We started being intentional about that split.
Propensity: how likely is this person to engage in risky behavior? This is the part that gets built from what people do: phishing clicks, reports, training completions, DLP warnings, whatever else flows in through our signals pipeline.
Exposure: How much does it cost the organization if they do? This is the part that depends on who they are within the org: role, access, which data they can access, which agents are tied to their identity, etc.
The decomposition isn't a new idea. Actuaries split frequency from severity. CVSS splits base severity from environmental context. The instinct shows up everywhere risk gets quantified seriously. It just hasn't shown up in human risk scoring yet.
Modeling propensity
The first thing we had to deal with was that the data is sparse. We pull signals from across the security stack, think: phishing simulations and reports we run ourselves, DLP warnings, training behavior, unexpected logins and access patterns from the rest of the integrated tools, threat intelligence on credential exposure and known-bad activity from external feeds, etc. But even with all of that, per-user per-signal data points are few. A typical employee might see a handful of phishing simulations a quarter, generate a DLP hit or two a year, trigger a single unusual sign-in once. If you treat any of those rates as a frequency, you get absurd numbers fast: someone who clicked 3 out of 5 phishing simulations isn't 60% likely to click everything. Five trials are barely enough to say anything.
What works for sparse data is a Bayesian setup: start with a prior belief about how likely a typical person (given what we already know about them) is to engage in a given risky behavior, update it as new evidence comes in, and carry forward the uncertainty around the estimate. The math here is old and tested, and it's the right tool when you're making individual estimates from small samples against a population baseline.
That choice leads to an additional interesting result.
The score carries its own uncertainty. Five observations on the employee Alice and fifty observations on the same Alice might produce the same estimate, but, depending on the context of the business, these might need to be treated differently. The score we surface isn't just a number; it's a live distribution with a credible interval around it. A security admin looking at a 70 sees how confident we are in that 70, and a high-confidence 70 and a low-confidence 70 can route to different responses.
Modeling exposure
The reason exposure is harder is that it depends on facts that live inside the customer's organization. Role, access, what systems someone can reach, what data they can touch, what they're authorized to move, who they can impersonate. We can get a long way from integrations (IDP, cloud, the rest of the security stack we're pulling signals from). But some facts about blast radius only the customer knows: that the engineer on a special project shouldn't be treated like the rest of engineering this quarter, that the finance manager who just got temp wire-approval authority needs more weight, that the new hire in legal won't actually have sensitive access for another six weeks, that the AI agent operating with the CFO's delegated credentials inherits the CFO's blast radius even though no human is at the keyboard.
So exposure ships with informed defaults and is configurable everywhere it touches. The weights we compute from integrations are just that: defaults, not commitments. Customers can override them, adding the knowledge that only they have.
Composing the score
When the security admin wants the composed view, propensity flows into the exposure lens, and the two come together into a single number.
What's different about how we do that isn't the math of combining them. It's that exposure is actually modeled. At Cimento, we believe the composition has to be explicit and intentional: propensity feeds the exposure model as another input, exposure does its own work on top, and any final score can be decomposed back into the parts that produced it. One never has to wonder whether exposure is contributing, and they never have to do it in their head.
Everything around the composition is configurable. Which inputs feed which view, what weights apply where, how propensity gets layered in.
A risk score you can't take apart isn't a tool… it's a verdict.
And that is what we built: a Bayesian propensity model that handles sparse, mixed signals from across the security stack; an exposure model that ships informed defaults from integrations and stays configurable wherever the customer has knowledge we don't; and a composition that's explicit about how the two come together. The pieces are decomposable end-to-end. No part of the final number is doing work totally in the dark.
The point of all of this isn't the math. It's that security teams looking at a Cimento risk score can see what's in it, trust what it's saying, and act on it without first having to do half the modeling themselves in their heads. A risk score should give time back to the security teams using it, not take it. That's the bar we're holding ourselves to.
