Click-through rates alone create a narrow and often misleading view of risk. They miss whether employees report suspicious messages, how quickly they escalate concerns, and whether certain roles face higher exposure. Without those signals, teams can overstate progress, underprioritise privileged users, and fail to spot patterns that predict real incidents.
Why This Matters for Security Teams
Click-through rates are easy to measure, which is why they often become the default metric in phishing simulation programmes. The problem is that they measure a narrow event, not the broader security behaviour that determines whether a real phishing attempt becomes an incident. A programme that only tracks clicks can miss reporting discipline, escalation speed, repeat exposure by role, and whether users recognise suspicious content before damage occurs.
That gap matters because security teams use simulation results to justify awareness spend, target training, and brief leadership. If the metric is weak, the decisions built on it are weak too. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports broader awareness and response control objectives than simple click tracking alone, including behaviour that improves detection and reporting.
In practice, many security teams discover the limits of click-only reporting only after a real phishing email has already been reported too late, or not at all.
How It Works in Practice
A stronger phishing simulation programme measures the full response path, not just the moment of failure. That means capturing whether a user clicks, whether they submit credentials, whether they report the message, how quickly they report it, and whether the report reaches the right response channel. It also means segmenting by function, privilege level, geography, and business unit so the programme can identify where exposure is concentrated.
Useful metrics usually include a mix of leading and lagging indicators:
- click rate, but only as one signal among several
- report rate and time-to-report
- escalation rate to SOC, service desk, or abuse mailbox
- repeat susceptibility by cohort or role
- credential submission rate for higher-risk scenarios
These metrics work best when the simulation platform is linked to incident handling workflows and SIEM visibility, so a reported message can be correlated with other suspicious activity. That helps teams see whether awareness actually reduces dwell time and improves detection. It also supports more defensible governance, because results can be tied to CISA phishing resources and internal response playbooks rather than being treated as isolated training outcomes.
Teams should also separate awareness objectives from blame. When employees are scored only on clicks, they often learn to hide mistakes rather than report them quickly. A better design rewards reporting behaviour, uses simulations to identify patterns, and refreshes content based on real attack themes. These controls tend to break down in large, distributed organisations with weak incident intake processes because the simulation data never reaches the people who can act on it.
Common Variations and Edge Cases
Tighter measurement often increases administrative overhead, requiring organisations to balance richer insight against reporting complexity. That tradeoff becomes visible when different business units want different success metrics, or when leadership insists on a single number for simplicity.
There is no universal standard for phishing simulation scoring yet. Some programmes weight reporting more heavily than clicking, while others prioritise role-based exposure or credential submission. Best practice is evolving toward outcome-based measurement, especially for privileged users, finance teams, and executive assistants, where a single missed message can create outsized risk.
In regulated environments, simulation results may also need to support audit evidence, awareness attestation, or control validation. In those cases, click-through rates alone are too thin to demonstrate that a programme is improving resilience. NIST’s broader control model, including awareness and response expectations, is a better fit than a single training metric. The same is true when phishing exercises are used to test readiness for business email compromise, because the important question is not only who clicked, but who noticed, who reported, and who escalated.
For organisations with heavy remote work, multilingual workforces, or high turnover, the signal can be distorted further. Those environments need cohort-based analysis and repeated measurement over time, not one-off campaign summaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AT-1 | Awareness outcomes should measure more than clicks to show users can recognise and respond to phishing. |
| OWASP Agentic AI Top 10 | Agentic workflows can amplify phishing impact if users or agents act on malicious prompts or links. | |
| NIST AI RMF | Risk measurement should support governance decisions, not rely on a single shallow metric. |
Track reporting and escalation behaviour, not just click rates, to validate awareness effectiveness.
Related resources from NHI Mgmt Group
- What breaks when human risk programmes rely only on training completion and phishing clicks?
- What breaks when organisations only measure vishing training by completion rates or simulation click rates?
- What breaks when attack simulation programs only track click rates?
- How should security teams measure phishing risk beyond click rates?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
