Many awareness programs reduce each employee’s human risk score to a single figure, how often they fell for a phishing simulation. It is a useful data point, but it tells only part of the story. Someone may have never failed a simulation and still reuse the same password across ten services, ignore alerts from their identity provider, or authorize applications no one ever reviewed. That risk is real. The simulation, on its own, does not see it.
As the person responsible for the platform’s integrations, I talk regularly with security teams that already have the telemetry to see it. The information is there, spread across the identity provider, the endpoint, and the SIEM. Even so, the risk score for people is calculated from a single source, and the rest of the signals sit on a different dashboard.
What is a human risk score, and what makes it reliable?
A human risk score is a per-person estimate of the likelihood that someone’s behavior leads to a security incident. It exists to help you prioritize: who to reinforce first, which areas need a different kind of content, where a policy should be adjusted.
Its reliability rests on three things. The first is the number of sources feeding the calculation, because a single dimension leaves blind spots. The second is how often it updates, since behavior changes and a six-month-old score describes a person who may no longer exist. The third is traceability. The team has to be able to explain why someone has the score they have, without stopping at the number.
When the score is built only from simulation results, it fails the first condition. It measures one specific behavior well and leaves the rest unobserved.
Why aren’t simulations enough on their own?
A phishing simulation measures a specific ability in a controlled moment: recognizing a phishing email and not interacting with it. It is a valuable, actionable signal, and it is the foundation of any serious program. We devote a good part of the platform to keeping that measurement clean, as I describe in how to design a campaign that actually changes behavior.
The limit shows up when that signal is used as if it described a person’s entire risk. Real attacks do not end at the phishing email. According to the Verizon Data Breach Investigations Report, the most frequent causes of breaches continue to heavily involve the human element, including social engineering, stolen credentials, and phishing. Much of that happens outside the reach of a simulation: a login from an impossible location, a second factor rejected several times, a device with a risky configuration.
An employee who passes every simulation may still be behind several of those signals. If the score does not incorporate them, the program sees one face of risk and assumes it is the only one.
What signals do the SIEM and the security stack add to per-person risk?
A SIEM (Security Information and Event Management) centralizes and correlates security events across the whole organization. Together with the identity provider, the endpoint, and XDR solutions, it forms what we usually call the security stack: the set of systems that already observe what happens in the real environment.
That stack produces signals that connect directly to how people behave. On the identity side, anomalous access attempts, authentication factors repeatedly rejected, or logins from inconsistent locations. On the endpoint and XDR side, malware detections, configurations that drift from policy, or connections to suspicious destinations. Each of those signals says something about a person’s risk that no simulation will ever capture.
The awareness signal and the stack’s are added together. The result is a score that reflects both the response to an exercise and the everyday behavior toward the systems the person uses every day.
How do you combine simulation and telemetry without watching the employee’s machine?
This is the part that matters most from a design standpoint, and it is an architectural decision rather than a technical detail. Enriching the score with signals from the stack does not mean installing an agent on each person’s device or watching what they do on screen. It means integrating with the systems the organization already runs and reading the signals those systems already generate.
We solve it through the API. SMARTFENSE connects with the identity provider, XDR platforms, and the SIEM, without asking for anything on the employee’s endpoint. It is the same logic I explain in why we integrate through the API instead of installing an agent, and the one that also underpins identity integration and SSO provisioning. The integration surface lives on the side of the security systems, not the workstation.
That distinction has concrete consequences. It respects the person’s privacy, because you read security events, not their personal activity. It reduces deployment friction, because there is no need to touch thousands of machines. And the signal travels in both directions. The score is enriched by the stack, and at the same time human behavior can feed the detection strategy, a complementary angle that Pablo Abratte covered in what your SIEM does not see.
What changes when the score is multi-source?
The first thing that changes is prioritization. When the score combines the response to simulations with signals from the stack, the list of people to reinforce is no longer ordered only by who failed an email and starts to reflect real risk. In practice, organizations that add the security stack’s signals surface risk the simulation alone did not show, and they also temper cases that looked critical and were not.
The second is the quality of the reinforcement. With a single-source score, the only possible answer is more simulations. With a multi-source score you can target the content to each group’s actual problem, whether that is credential handling, reaction to identity alerts, or device care.
The third is the conversation with leadership. A score that integrates several sources is more defensible in front of a committee, because it does not hinge on a single indicator that rises and falls with every campaign. On how to take that to a board I wrote in board-level reporting in two minutes, and on how to translate it into budget in quantifying human risk for the CFO.
None of this requires starting from scratch. If your organization already has an awareness program and a working security stack, most of the work is integration: connecting what measures behavior with what observes the environment, and letting the score reflect both.
Frequently asked questions
Does a human risk score replace phishing simulations?
No. Simulations remain a core source and the most direct way to measure and train the response to a phishing email. A multi-source score incorporates them and adds stack signals to cover the risk they do not observe.
Do you need to install an agent on devices to read SIEM signals?
No. The integration happens through the API with the security systems the organization already runs, such as the identity provider, XDR, and the SIEM. Nothing is installed on the employee’s endpoint, and their personal activity is not watched.
What security stack signals add to per-person risk?
Anomalous access, repeatedly rejected second factors, logins from inconsistent locations, malware detections, and device configurations that drift from policy. All of them correlate with a person’s behavior.
Is the employee’s privacy respected?
Yes. You read security events generated by corporate systems, not the person’s private activity. The telemetry comes from the security stack, not from watching anyone’s screen.
How often should the score update?
Continuously. Behavior changes, and a score that updates as new signals arrive describes the person as they are today, not as they were during the last campaign.
Want to see how this connects to your environment? The platform’s integrations section shows which systems SMARTFENSE connects with, and the simulation tools section shows where behavior measurement begins.
Leave a Reply