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 This Matters for Security Teams
Click rate is a useful signal, but it is not a security outcome. A social engineering test can produce a low click rate and still leave the organisation exposed if employees do not report suspicious activity, if managers ignore escalation paths, or if the attack succeeded by phone, chat, or help desk manipulation instead of email. That is why NIST guidance on detection and response matters here, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, which frames security as a control system rather than a single user action.
NHIMG research shows how attackers frequently bypass simplistic awareness assumptions in real incidents such as the MGM Resorts Breach 2023 -- Scattered Spider and the Caesars Entertainment Breach 2023 -- Scattered Spider, where the real failure was not simply whether someone clicked, but whether identity, verification, and escalation processes held under pressure. Current guidance suggests that measuring only click rates can reward shallow training while hiding repeat exposure, role-specific weakness, and broken reporting culture. In practice, many security teams discover that the phishing problem was really a process problem only after a real fraud attempt has already moved beyond the inbox.
How It Works in Practice
A better programme tracks the full behavioural chain: who received the lure, who clicked, who reported it, how quickly the report reached the right team, and whether the organisation contained the attempt before any credential, payment, or data loss occurred. That means building metrics around detection, escalation, and response quality, not just user error. The practical question is whether the organisation can stop and learn from the event.
Good testing usually combines several signals:
- clicks, but also report rates and time-to-report
- repeat exposure by role, region, or business function
- whether help desk, finance, or HR followed verification steps
- how often the test exposed weak processes, not just weak judgment
This is consistent with the broader identity and resilience themes in the Ultimate Guide to NHIs, which emphasizes visibility, governance, and response discipline as operational controls, not just inventory exercises. It also aligns with NIST SP 800-63 Digital Identity Guidelines because identity proofing and authenticator handling only work when users and support staff can consistently verify risk before granting access or resetting credentials.
In well-run programmes, the follow-up is as important as the test itself. Analysts review whether staff used the correct reporting channel, whether security triage was timely, and whether any workflow allowed the attacker to progress through the organisation by exploiting trust or urgency. These controls tend to break down in large, decentralised environments because local teams often handle suspicious requests differently, making performance hard to compare and easy to misread.
Common Variations and Edge Cases
Tighter measurement often increases administrative overhead, requiring organisations to balance richer behavioural insight against staff fatigue and reporting noise. That tradeoff is real: if every test is over-instrumented, teams may spend more time scoring users than fixing the weak points attackers actually exploit.
There is no universal standard for this yet, but current guidance suggests separating individual coaching from programme-level reporting. That avoids turning a security exercise into a punitive scorecard, which can suppress reporting and distort results. It is also important to distinguish simulated phishing from broader social engineering, because a phone call to the service desk, a payment diversion request, or a chat-based lure may be more dangerous than an email click.
NHIMG case research such as the Storm-2949 Azure Breach shows why click-centric thinking misses modern attack paths that move across channels and identities. The lesson is to measure resilience, not embarrassment. If the metric cannot show whether the organisation reported, verified, escalated, and contained the attempt, it cannot show whether the control actually works.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM | Measuring report and response signals supports continuous monitoring. |
| NIST SP 800-63 | IAL/AAL | Social engineering often targets identity proofing and authenticator recovery. |
| NIST AI RMF | Behavioural metrics support governance of risk detection and response. | |
| OWASP Non-Human Identity Top 10 | NHI-08 | Weak reporting and recovery workflows often expose secrets and access paths. |
| CSA MAESTRO | Agentic workflows depend on trustworthy escalation and human-in-the-loop controls. |
Review verification and recovery steps to ensure staff do not bypass identity checks under pressure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
