Many awareness programs reduce each employee\u2019s 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.<\/p>\n
As the person responsible for the platform\u2019s 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.<\/p>\n
A human risk score is a per-person estimate of the likelihood that someone\u2019s 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.<\/p>\n
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.<\/p>\n
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.<\/p>\n
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<\/a>.<\/p>\n The limit shows up when that signal is used as if it described a person\u2019s entire risk. Real attacks do not end at the phishing email. According to the Verizon Data Breach Investigations Report<\/a>, 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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\u2019s risk that no simulation will ever capture.<\/p>\n The awareness signal and the stack\u2019s 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.<\/p>\n 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\u2019s 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.<\/p>\n We solve it through the API. SMARTFENSE connects with the identity provider, XDR platforms, and the SIEM, without asking for anything on the employee\u2019s endpoint. It is the same logic I explain in why we integrate through the API instead of installing an agent<\/a>, and the one that also underpins identity integration and SSO provisioning<\/a>. The integration surface lives on the side of the security systems, not the workstation.<\/p>\n That distinction has concrete consequences. It respects the person\u2019s 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<\/a>.<\/p>\n 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\u2019s signals surface risk the simulation alone did not show, and they also temper cases that looked critical and were not.<\/p>\n 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\u2019s actual problem, whether that is credential handling, reaction to identity alerts, or device care.<\/p>\n 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<\/a>, and on how to translate it into budget in quantifying human risk for the CFO<\/a>.<\/p>\n 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<\/a>: connecting what measures behavior with what observes the environment, and letting the score reflect both.<\/p>\n Does a human risk score replace phishing simulations?<\/strong> Do you need to install an agent on devices to read SIEM signals?<\/strong> What security stack signals add to per-person risk?<\/strong> Is the employee\u2019s privacy respected?<\/strong> How often should the score update?<\/strong> Want to see how this connects to your environment? The platform\u2019s integrations<\/a> section shows which systems SMARTFENSE connects with, and the simulation tools<\/a> section shows where behavior measurement begins.<\/p>\n","protected":false},"excerpt":{"rendered":" Phishing simulations measure only part of human risk. How to enrich the per-person score with real signals from your SIEM and security stack.<\/p>\n","protected":false},"author":4,"featured_media":43803,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[3,686],"tags":[454,2127,2063,448,2131,2103],"class_list":["post-43786","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-ciso-en","tag-integracion-siem","tag-riesgo-humano","tag-security-awareness","tag-siem","tag-simulaciones-de-phishing"],"acf":[],"yoast_head":" \nWhat signals do the SIEM and the security stack add to per-person risk?<\/h2>\n
How do you combine simulation and telemetry without watching the employee\u2019s machine?<\/h2>\n
What changes when the score is multi-source?<\/h2>\n
Frequently asked questions<\/h2>\n
\nNo. 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.<\/p>\n
\nNo. 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\u2019s endpoint, and their personal activity is not watched.<\/p>\n
\nAnomalous 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\u2019s behavior.<\/p>\n
\nYes. You read security events generated by corporate systems, not the person\u2019s private activity. The telemetry comes from the security stack, not from watching anyone\u2019s screen.<\/p>\n
\nContinuously. 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.<\/p>\n