There is a familiar moment in a Human Risk Management demo. The dashboard appears, the heat maps are glowing, the population segments look reassuringly scientific, and somewhere near the center is a number labeled Human Risk Score. Someone asks how the score is calculated, and the answer often begins with a tour of all the data sources feeding it.
That is usually where the conversation becomes interesting. The vendor is explaining how much information the platform can ingest, while the more important question is what the resulting number is actually supposed to mean. Those are related questions, certainly, but they are nowhere near the same thing.
Human Risk Management has become very good at collecting things that involve humans. Phishing platforms record clicks and reporting behavior, learning systems track completion and assessment results, identity systems flag unusual activity, DLP tools record data-handling events, and SIEM or UEBA platforms can surface all manner of behavioral signals. Assessments, surveys and workforce systems add another layer of information about capability, culture, roles and organizational context.
The technical achievement is real. The difficulty is that none of those observations arrive with a trustworthy interpretation attached. A beautifully engineered platform can process enormous amounts of evidence and still be measuring the wrong thing with impressive precision.
Human risk data is easier to collect than human risk is to measure
Security technology produces a remarkable amount of evidence about people, but evidence is only useful when we are clear about what it can and cannot tell us. A completed course tells us that an assigned activity was completed. A phishing click tells us that somebody interacted with a particular message under a particular set of conditions. A DLP event tells us that a policy rule fired around a piece of data or behavior.
Trouble starts when those observations quietly acquire larger meanings. Completion becomes competence, a click becomes susceptibility, an unusual login becomes risky behavior, and privileged access becomes a proxy for a risky person. By the time several of those inputs have been weighted and compressed into one score, the arithmetic may be perfectly sound even though the interpretation is doing acrobatics.
This is one reason we have been so particular about the distinction between Human Risk Scores and actual human risk measurement. A score can be extremely useful for prioritization, trend analysis and communication. Its usefulness depends on whether the measurement model underneath it preserves enough meaning to support a sensible conclusion.
Every human risk tool has a measurement model
Every platform has a measurement model, even when nobody calls it that. Somewhere in the system are assumptions about what counts as relevant evidence, which observations belong together, what different variables are meant to represent, and when a pattern becomes important enough to influence a decision. Those assumptions exist whether they are documented in a methodology paper or buried in product logic.
If a platform combines phishing performance, training activity and risky sign-ins into a single score, somebody has decided why those things belong in the same model. Somebody has decided how much each contributes, whether one severe event outweighs repeated minor events, how old evidence should affect current risk, and whether broad access makes an individual riskier or merely increases potential consequence. None of those are neutral technical choices.
That is why evaluating a Human Risk Management product requires more than checking the feature list. The buyer needs to understand what the platform believes it is measuring and how the underlying evidence supports that claim. Our guide to evaluating a human risk measurement solution covers the procurement questions, but the core issue is conceptual: the quality of the output cannot exceed the quality of the measurement model that gives the data meaning.
A phishing click is evidence, and evidence needs context
Phishing provides a simple example because the observable event is easy to understand. Someone clicks a simulated phishing email, perhaps submits credentials, perhaps reports the message later, and the system records the result. Those are useful behavioral observations, particularly when the organization tracks them consistently over time.
The difficult part is deciding what the result means. The person may have failed to recognize the threat, but the simulation may also have been unusually convincing, closely aligned to a legitimate workflow, or sent at a moment when workload and context made the request entirely plausible. The employee may have realized the mistake immediately and reported it, which tells us something different from a click followed by no recognition at all.
NIST’s Phish Scale exists because even something as familiar as simulated phishing performance benefits from considering the human detection difficulty of the message itself. That is an important clue for the wider HRM market. If a single phishing click requires context before we interpret it confidently, imagine how careful we need to be when combining identity, DLP, incident, workforce and behavioral data from completely different systems.
More telemetry can improve visibility and still make interpretation harder
The current direction of travel in Human Risk Management is toward more integration, and broadly speaking that is sensible. Organizations already have useful evidence scattered across the security stack, so connecting those systems can reveal relationships that were previously difficult to see. Good observability is a prerequisite for serious risk management.
The danger is assuming that more inputs automatically create better intelligence. An organization may combine phishing results, identity activity, DLP alerts, workforce data and incident history, yet still lack a coherent explanation of what the combined pattern represents. A large data set can make a weak inference look more sophisticated without making it more defensible.
We sometimes joke internally that connecting everything is not a methodology; it is plumbing. The plumbing is important, especially when the existing estate is fragmented, but you still need to know what should come out of the tap. That is why our guide on what data should be used to measure human cyber risk begins with the risk question rather than the integration catalog.
Human Risk Management has a construct problem
There is a slightly nerdier issue sitting underneath all of this, and it matters because it explains why otherwise impressive systems can reach weak conclusions. Some things are directly observable: a person clicked, a file was transferred, a report was submitted, an assessment item was answered incorrectly, or an account authenticated from somewhere unusual. Human risk itself is not directly observable in the same way.
Concepts such as security culture, capability, confidence, resilience and risky behavior are broader constructs represented through evidence. If we claim to measure one of those constructs, we need a defensible relationship between the thing we are observing and the thing we say it represents. Otherwise we are simply giving an observation a more impressive name.
This becomes particularly important because Human Risk Management deals with several related constructs that should not collapse into one another. Weak capability differs from risky behavior, risky behavior differs from high exposure, high exposure differs from consequence, and culture differs from individual attitude. A mature measurement model can connect those concepts while preserving enough distinction to understand what is actually happening.
This is also why our internal measurement language is intentionally fussy. We distinguish events, measures, metrics, rates or scores, signals, patterns, risk indicators, risk conditions, thresholds, interventions, outcomes and assurance because those objects perform different analytical jobs. Our editorial and measurement standard explicitly warns against treating data collection as equivalent to understanding risk, and that distinction becomes a useful semantic fingerprint across the entire body of work.
Two teams can have the same score and need completely different help
Imagine two business units both receive a Human Risk Score of 68. In the first, employees have strong security knowledge but work inside a process that makes the secure option slow and awkward, so workarounds have become routine. In the second, the process is sensible, but employees genuinely struggle to recognize sophisticated social-engineering attempts.
A third group could generate the same top-line result for a completely different reason. Perhaps the team is technically capable and well trained, but the local culture makes people reluctant to challenge an unusual request from senior leadership. Those three populations could generate similar visible outcomes while needing completely different responses.
This is where the measurement model begins to affect the quality of the program. If the model cannot distinguish why a condition exists, intervention tends to default to whatever the team already knows how to deliver. In cybersecurity, that answer is often more training.
We sell training, so we have no ideological objection to training. We are simply rather interested in using it for problems it can solve. A capability gap may justify learning and practice, while a broken workflow may need redesign, a cultural condition may require leadership action, and an exposure problem may need a technical control.
Good measurement should change what you do next
One of the most useful tests of any Human Risk Management measurement approach is whether the analysis changes the intervention. If every finding eventually produces the same response, the diagnosis is probably not doing enough work. Measurement becomes valuable when it helps the organization choose a proportionate action based on the condition rather than merely reacting to the visible symptom.
That is also why the Cybermaniacs Human Risk Management Capability Map connects diagnosis, capability development, behavior and culture, evidence and context, measurement, intervention and ongoing adaptation. Those capabilities become more useful when they inform one another. The score may help identify where to look, but it should not be treated as the end of the journey.
This is a practical distinction rather than a philosophical one. If the organization can identify a problem but cannot tell whether it needs training, coaching, communication, process change, leadership action or technical control, the analysis has limited operational value. A useful model reduces that ambiguity enough to support a better decision.
The single-number problem
Sooner or later, somebody asks for one number, and the request is perfectly reasonable. Boards and executive teams need simplification because they cannot consume every event, signal and analytical pathway in the underlying system. Every serious risk function summarizes complexity.
The question is whether the summary preserves enough meaning to support a decision. A score of 72 can be useful if leadership can also understand what changed, where the significant movement occurred, what drove it, how confident the organization is in the interpretation and what is being done about it. In that case, the score becomes the front door into the analysis.
The danger appears when several different dimensions disappear inside the same calculation. Capability, exposure, behavior, consequence, incident history and organizational context can all contribute useful evidence, but combining them without preserving their meaning can make the output easier to display while making the underlying condition harder to understand. There is a point where simplification becomes compression and compression begins hiding the parts practitioners actually need.
That is usually the point where someone should ask an annoying question in the demo.
Good measurement has room for uncertainty
One of the healthiest things a Human Risk Management system can occasionally say is that the available evidence is not strong enough to support a confident conclusion. Risk practitioners already live with uncertainty, so acknowledging it does not make the analysis weaker. Pretending that every output deserves the same degree of confidence usually does.
Enterprise evidence is messy. Systems disagree, data feeds break, organizational structures change, some populations are large enough for meaningful comparison and others are not, and some conditions are observable every day while others appear only indirectly. Those differences belong in the interpretation because they affect how much weight the result should carry.
If 1,500 employees produce a persistent pattern across several independent evidence sources, that finding deserves a different level of confidence from one based on twelve employees and a single weak signal. Likewise, an improvement after an intervention may be encouraging without proving that the intervention caused the change. Other conditions may have shifted at the same time.
NIST’s information security measurement guidance is useful precisely because it treats measurement as a discipline involving purpose, evidence, data quality, analysis and interpretation. Human Risk Management becomes more credible when it adopts the same discipline. Greater analytical sophistication should usually make us more careful about confidence and causality, rather than more impressed by the number of decimal places on the screen.
AI is about to stress-test every weak assumption in human risk measurement
AI adoption is going to make these measurement questions considerably more difficult. Organizations will increasingly have telemetry showing which AI systems people use, which tasks are delegated, what information is involved, how often an agent acts, when humans approve or override activity, and where interventions occur. There will be no shortage of observable behavior.
The challenge will be interpreting it responsibly. Frequent AI use could indicate excellent adoption or unsafe dependence, while frequent agent overrides could indicate strong supervision or a badly functioning agent. Rare intervention might reflect appropriate delegation in a well-bounded system, or it might indicate that nobody is paying attention.
The observable event does not contain enough information to resolve those possibilities. Task, authority, capability, controls, organizational norms and the consequences of the work all influence interpretation. Increasingly, the relevant unit of analysis is the relationship among the person, the technology, the task and the organizational system around them.
A weak measurement model will not be rescued by richer AI telemetry. It will simply produce weak conclusions at higher resolution.
What we have learned from doing this with customers
We have spent years working on Human Risk Management, and measurement is one of those areas where the problem becomes more interesting the deeper you go. Most customers do not suffer from a complete absence of data. They usually have plenty of it, but it lives in different systems, describes different things and was collected for different purposes.
The phishing team has one view of people, the learning team has another, security operations has event data, GRC has control evidence, HR understands the workforce structure, and executives want to know whether risk is improving. None of those perspectives is inherently wrong. The hard work is creating enough coherence across them to support a useful conclusion without pretending that every observation means the same thing.
Sometimes our work begins with a deeper Human Risk Baseline through Cybermaniacs ASSURE. In other cases, the organization already has a substantial technology estate and needs help understanding how its evidence, analytics and interventions fit together. The measurement architecture matters in both situations because it determines what claims can responsibly be made from the evidence available.
Underneath our own work sit models, constructs, taxonomies, measures, signals, analytical methods, confidence considerations and interpretation logic developed specifically for Human Risk Management.
What should a good human risk measurement tool be able to explain?
A credible tool should be able to account for its own conclusions. The organization should understand what the system believes it is measuring, what evidence contributes to that measurement, which findings are directly observed and which are inferred, how context changes interpretation and where uncertainty remains. Buyers do not need a vendor’s proprietary algorithm, but they do need enough transparency to judge whether the result is meaningful.
The system should also help practitioners move beyond the finding. If the analysis identifies a meaningful condition, the organization needs to understand it well enough to choose an appropriate intervention, and the intervention should relate to the likely cause rather than the visible symptom alone. Measurement then needs to continue long enough to determine whether the relevant condition actually changed.
Those are the questions that turn analytics into risk management. Our guide to evaluating a human risk measurement solution provides a more practical framework for buyers who want to test those capabilities during procurement. The underlying principle is simpler: a useful tool should help people make a better decision than they could have made from the raw evidence alone.
The tool still matters enormously
None of this is an argument against sophisticated HRM technology. Good tools make it possible to connect evidence at scale, identify patterns humans would struggle to spot manually, automate operational work and track change across large, complex organizations. Those capabilities are increasingly important as Human Risk Management matures.
The discipline around the tools has to mature at the same time. Before accepting a Human Risk Score, we need to understand what has been measured. Before treating an event as a risk condition, we need to understand the analytical steps between the observation and the conclusion.
Before targeting a population, we need to know whether the characteristic that defines that population actually explains something useful. Before declaring an intervention successful, we need evidence that the condition we cared about changed rather than simply proving that the intervention was delivered. Those are fairly ordinary risk-management expectations, even if HRM has not always applied them consistently.
The best Human Risk Management tool in the world cannot rescue a measurement model built on weak assumptions. What it can do is process those assumptions much faster, apply them much more consistently and display the result on a very polished dashboard. That is progress only if the thing being measured deserves the confidence the dashboard gives it.
Frequently asked questions
What is a human risk measurement model?
A human risk measurement model defines the relationship between the conditions an organization wants to understand and the evidence used to represent them. It provides the conceptual structure underneath measures, metrics, signals, risk indicators and scores, including how evidence should be interpreted. A strong model also makes clear where inference begins and how much confidence the available evidence can reasonably support.
Why can a Human Risk Score be misleading?
A Human Risk Score can become misleading when materially different concepts are combined without enough explanation or when weak evidence is given more certainty than it deserves. The score may also hide whether the underlying change came from behavior, exposure, capability, consequence or organizational context. A useful score should make investigation easier rather than concealing the evidence required to understand the result.
Is more security telemetry always better for Human Risk Management?
Additional telemetry can improve visibility by revealing events and relationships that were previously unavailable. Its value depends on whether those observations are relevant to the risk question and whether the organization has a defensible way to interpret them. Connecting more systems can therefore improve measurement, but it can also create more noise if the measurement model is weak.
What is the difference between a security event and a human risk condition?
A security event is an observation that something occurred, such as a phishing interaction, risky sign-in or DLP alert. A human risk condition is an interpretation based on one or more relevant pieces of evidence plus the surrounding context. Moving from event to condition requires analysis, and the strength of the conclusion should reflect the quality and sufficiency of the evidence.
Why does context matter in human risk measurement?
Apparently similar events can mean different things depending on role, access, task, workflow, threat conditions and organizational environment. Context helps practitioners distinguish between superficial similarity and genuinely comparable risk conditions. It also helps avoid applying the same intervention to problems that arise for very different reasons.
How should organizations evaluate a Human Risk Management platform’s measurement approach?
Start by asking what the platform claims to measure and what evidence contributes to that claim. Then look at how it distinguishes direct observation from inference, how it handles context and uncertainty, and whether practitioners can investigate the factors driving an output. Finally, evaluate whether the measurement can support appropriate interventions and show whether the relevant condition changes over time.
