Low click rates can reflect familiarity with a repeated simulation rather than safer behaviour. If the test is predictable, staff may pass it without becoming harder to fool in real attacks. Teams should combine simulation results with behavioural signals, role context and follow-up outcomes before treating the metric as evidence of reduced 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.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Security Events | Phishing simulations are a monitoring signal that must be interpreted with other evidence. |
| GV.RM-01 — Risk Management Strategy | Risk metrics need context so leadership does not overread a single KPI. | |
| Recommendation — Correlate simulation outcomes with broader monitoring signals before concluding risk has fallen. Define how human-risk metrics are combined with behavioural and role-based evidence. | ||
| CIS Controls v8 | CIS-14 — Security Awareness and Skills Training | The topic is about interpreting awareness-training results and their limits. |
| Recommendation — Measure training effectiveness with multiple indicators, not click rate alone. | ||
| NIST SP 800-53 Rev 5 | AT-2 — Awareness Training | Training programs require outcome measures that go beyond test clicks. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Follow-up analysis of simulation and response outcomes is central to the judgment. | |
| Recommendation — Evaluate awareness training using behaviour and reporting outcomes, not only simulation clicks. Review simulation data alongside reporting and escalation records to validate risk reduction. | ||
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?