Click rates alone miss the bigger picture. They do not show whether employees reported the attempt, whether certain roles are repeatedly exposed, or whether weak procedures enabled the scam. A narrow metric can create false confidence, while richer behavioural data helps security teams see whether controls, training, and escalation paths are actually working.
Why click-rate-only testing gives the wrong answer
Click rates are easy to measure, but they are not a reliable proxy for organisational resilience. A social engineering test can produce a low click rate and still leave serious gaps in reporting, escalation, and procedure adherence. For phishing and pretexting scenarios, NIST’s control families around awareness, incident handling, and security monitoring are more useful when the goal is to understand whether people and processes actually detected and contained the attempt. NIST SP 800-53 Rev 5 Security and Privacy Controls gives the broader control context that click metrics alone cannot capture. In practice, many security teams discover reporting failures only after a simulated lure is already circulating, rather than through a clean click-rate dashboard.
What a useful social engineering test should measure instead
Useful testing looks at the whole response chain, not just the first interaction. If an employee clicks a lure but immediately reports it, that is a different outcome from silent compromise or repeated non-reporting. The same is true when a test reveals that certain teams are disproportionately targeted, that managers bypass normal reporting paths, or that a local process encourages people to comply with urgent requests. Those are control and workflow problems, not simply user-awareness problems.
A better assessment usually combines several signals:
- reporting rate and reporting speed
- whether the message was escalated through the right channel
- which roles, business units, or locations were exposed repeatedly
- whether a user followed a risky instruction, not only whether they clicked
- whether mailbox, helpdesk, or approval workflows reduced the chance of harm
This matters because a phishing simulation is meant to test behaviour under pressure. If a program only counts clicks, it can miss weak escalation paths, over-trust training completion, and ignore the process friction that makes users less likely to report suspicious activity. The metric then rewards appearance over detection and response. Where identity proofing or access requests are part of the scam, the issue can also intersect with identity assurance, but only when the test is actually probing authentication or verification behaviour.
That makes click rate a lagging indicator, not a complete measure of control effectiveness. It is useful, but only when paired with other behavioural evidence and control outcomes. Where the organisation cannot observe reporting or escalation, the test loses much of its value and starts measuring guesswork instead of resilience.
Where click-rate-only programs distort the picture
Tighter measurement often increases reporting overhead, so organisations have to balance simplicity against diagnostic value. The main distortion appears when teams compare different business units, because a low click rate can hide weak reporting discipline, while a higher click rate can coexist with strong detection and fast escalation.
One common variation is a test that focuses on executive or finance staff. In those cases, the real question is often whether the person verified the request through a second channel, not whether they clicked. Another edge case is a simulation designed to test a specific procedure, such as payment change approval or document sharing. In that setting, the more important signal is whether the procedure was followed correctly under pressure. Guidance-vs-consensus is still evolving here: many practitioners treat click rate as a baseline hygiene measure, but not as a sufficient maturity metric.
Another gotcha is that highly realistic simulations can suppress clicks without improving resilience if employees become suspicious of every message. That can create a misleading improvement in the number while reducing trust in legitimate internal communication. Teams should therefore treat the metric as one input to a wider control assessment, not as the headline result. The guidance breaks down when a programme cannot distinguish between curiosity, suspicion, reporting, and unsafe action, because then the metric is too blunt to support credible decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 14 — Security Awareness and Skills Training | Click-rate-only testing measures awareness weakly; CIS 14 emphasises training outcomes and behaviour. |
| Recommendation — Measure reporting and escalation behaviour, not clicks alone, to validate awareness effectiveness. | ||
| NIST CSF 2.0 | PR.AT-01 — Awareness and Training Policy and Procedures | The question is about awareness-test meaning and control effectiveness, not a single phishing metric. |
| DE.CM-08 — Vulnerability Scans and User Behaviour Monitoring | Behavioural telemetry from simulations supports monitoring of exposure and response patterns. | |
| RS.CO-02 — Incident Reporting and Communication | Reporting rate and escalation are central to what click-rate-only programs miss. | |
| Recommendation — Use awareness outcomes to assess whether training changes employee response behaviour. Track behavioural responses and response paths to identify repeated exposure and weak reporting. Validate that suspicious messages are reported through the right communication path. | ||
| MITRE ATT&CK | T1566 — Phishing | Social engineering testing models phishing-style delivery and user response. |
| Recommendation — Map simulation outcomes to phishing behaviours and look for reporting gaps after delivery. | ||
Practitioner Guidance
What to prioritise: Measure whether people report, escalate, and verify, not just whether they click. If the programme cannot show those behaviours, it is not testing control effectiveness, only exposure to a lure.
What to verify: Check that the test design captures role-based differences and downstream actions. A meaningful result should tell teams which groups are repeatedly vulnerable, where reporting breaks, and whether the expected workflow is actually usable under pressure.
Common mistake: Treating a lower click rate as proof that awareness has improved. That conclusion is unsafe unless the organisation can also show faster reporting, better escalation quality, and fewer procedural failures.
What practitioners underestimate: The test may reveal a process problem rather than a people problem. If employees routinely comply with urgent or unusual requests because the workflow rewards speed over verification, training alone will not fix the issue.
Practitioner takeaway: The most useful social engineering metric is the one that changes a decision, and click rate by itself rarely does that.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
