Why do low click rates not always mean lower human risk?

Why a low click rate can look safer than it really is

Low click rates are a useful signal, but they are not a direct measure of how hard people are to deceive. In a repeated simulation, staff can learn the pattern, recognise the style, or simply anticipate that “another test” is coming. That can reduce clicks without changing the underlying judgment that drives real-world exposure.

What matters is whether the exercise still tests attention, judgment and escalation under believable conditions. If the scenario becomes predictable, the metric starts measuring familiarity with the test rather than resistance to phishing, social engineering or other human-targeted attacks.

A good low rate therefore needs interpretation. One team may show genuine improvement, while another may only have trained people to spot the simulation format. The same number can describe two very different realities.

Why click-rate metrics can miss the real human-risk signal

Click rate is a single outcome measure, so it can hide the steps that matter most. A user may avoid clicking but still fail by replying, forwarding, reporting late, entering credentials elsewhere, or delaying escalation. It can also miss the difference between a cautious response and a response that still creates business risk.

Role context matters as well. A low overall rate can conceal concentration risk if a small number of high-value roles, privileged users, or high-impact teams remain vulnerable. In security terms, the question is not only “how many clicked?” but “who was targeted, what action did they take, and what could that action have exposed?”

The metric is also sensitive to how the simulation is run. If users know the cadence, content style or sender patterns, they may adapt to the test itself. That means the apparent improvement can be a testing artefact unless you look at follow-up behaviour and outcomes after the exercise.

What to use instead of click rate alone

Use click rate as one input in a broader view of human risk. The stronger signal comes from combining simulation results with behavioural evidence, such as report rate, time to report, escalation quality, repeat susceptibility, and whether users who “pass” still make risky decisions in related scenarios.

It also helps to compare results by role, function and exposure. A consistent pattern of safe behaviour across the whole population is more meaningful than a low aggregate number driven by a few low-risk groups. For recurring programmes, the more important question is whether the test is still discriminating between careful and careless behaviour.

Where possible, connect the exercise to real outcomes. If people who never click still mishandle attachments, approve unexpected requests, or delay reporting suspicious activity, the risk remains material even when the headline metric looks good.

Risk and Threat Considerations

Low click rates can create false confidence if the programme is predictable, because the apparent improvement may reflect test awareness rather than resilience to real attacks. That matters when decisions about training, controls, or exception handling are based on the metric alone.

Failure mechanism: Repeated simulations condition users to the test pattern, suppressing clicks without materially changing susceptibility to believable phishing, social engineering, or follow-on risky actions such as delayed reporting or unsafe response.

Impact: Organisations may underinvest in training, miss exposed roles, and assume human-risk reduction that has not actually occurred, leaving real attack paths open.

Practitioner Guidance

What to prioritise: Treat predictability as a measurement problem. If the same simulation family is reused too often, rotate scenarios, vary lures, and examine whether the metric changes when users cannot easily recognise the exercise.

What to verify: Look beyond the click outcome and verify reporting behaviour, escalation timing, and role-based exposure. If a low click rate is not accompanied by faster reporting and safer downstream decisions, do not treat it as evidence of reduced risk.

Practitioner takeaway: The useful question is not whether people clicked less, but whether they became harder to exploit in ways that matter operationally.

Related resources from NHI Mgmt Group

• Why do lower bug rates not always mean lower security risk in AI-generated code?
• Why do organisations need more than phishing click rates to manage human risk effectively?
• Who is accountable when human risk training does not translate into lower incident rates?
• Why do rooted or jailbroken devices not always mean higher fraud risk?