Executive Takeaway
A falling phishing click rate can produce a reassuring board slide without showing whether the organization is better able to resist or contain a real attack. New research covering 12 months of simulations reinforces that distinction: clicking, surrendering credentials, reporting a message, and enabling a rapid response are different behaviors with different consequences.
The management decision is not whether to abandon phishing simulations. It is whether to stop treating their easiest output as proof of resilience.
Security leaders should retain click rate as diagnostic data, but place it within a broader operating model that measures credential submission, reporting speed, exercise difficulty, post-click reporting, and the time required to contain a suspected compromise. The desired business capability is not a workforce that never makes a mistake. It is a workforce and response system that detect consequential mistakes early and limit their impact.
What the New Data Shows
On September 10, 2026, security-awareness vendor Pistachio published findings from 2,473,158 simulated phishing messages sent across 1,288 organizations. Its like-for-like analysis focused on 648 organizations with complete 12-month records, covering 123,692 users.
The reported findings challenge several familiar assumptions:
- On their first simulation, 1.57% of users submitted credentials.
- Across the year, 30.27% of technology-development users and 28.53% of IT users clicked at least once.
- With a similar difficulty mix across 18 departments, cumulative click rates ranged from 26.35% in design to 41.31% in construction.
- Click and credential-submission rates peaked around six months, when the platform delivered its hardest tests, before declining.
- By 12 months, users reportedly submitted suspicious-message reports nearly twice as often as they clicked.
These numbers require boundaries. This was research produced by a company that sells adaptive phishing simulations. The population primarily represents small and mid-market organizations using its platform, not a random sample of global enterprises. The simulations also measure behavior under controlled exercises, not losses or compromise rates during real attacks. A contemporaneous independent review also noted the absence of geographic analysis.
The study therefore does not establish universal industry benchmarks. It does provide a large operational dataset illustrating why the same click percentage can mean very different things.
The Error Is Not Measuring Clicks; It Is Misinterpreting Them
Click rate answers a narrow question: how often did recipients interact with a particular simulated message? It does not establish whether a person entered credentials, reported the message, recognized the problem after clicking, or enabled the security team to contain a wider campaign.
It also cannot be interpreted responsibly without knowing how difficult and relevant the message was. NIST’s Phish Scale was developed specifically to add human detection difficulty and recipient context to click and reporting results. NIST warns that rates alone offer only a partial picture because some messages are inherently harder for a target population to detect.
A low click rate may indicate improvement. It may also indicate easy exercises, repeated templates, irrelevant scenarios, filtering that removed difficult messages, or employees who learned how the testing platform behaves. Conversely, a rising click rate may indicate deteriorating behavior, or it may mean the organization has started testing credible attacks against people whose work requires them to open unsolicited messages.
The mistake occurs when a security activity metric becomes an assurance claim. A board sees a declining percentage and is invited to infer that credential compromise, fraud, ransomware entry, or operational disruption is becoming less likely. The metric cannot support that conclusion on its own.
Measure the Capability and the Consequence
A more useful dashboard connects the simulation to the operating response it is intended to exercise.
| Evidence | Decision it supports |
|---|---|
| Difficulty-adjusted click rate | Are scenarios becoming more realistic while recognition improves? |
| Credential-submission rate | How often does interaction become immediately exploitable exposure? |
| Report rate and median time to report | Is the workforce contributing timely detection? |
| Post-click report rate | Will people disclose mistakes quickly enough to support containment? |
| Repeat credential-submission rate | Is targeted intervention changing high-consequence behavior? |
| Time from report to identity and message containment | Can the security operation convert a human signal into risk reduction? |
This moves the program through control, capability, and consequence. The simulation is the control. Recognition, reporting, identity containment, and campaign removal form the capability. Reduced attacker dwell time and fewer usable credentials are the intended consequences.
Reporting must also lead somewhere. A report button that sends messages into an unattended queue creates activity, not protection. The workflow should support rapid message analysis, enterprise search, malicious-message removal, identity investigation, session revocation, credential reset, and blocking of related infrastructure where appropriate.
For industrial organizations, the scenarios should reflect actual working conditions without undermining safety communications. Procurement teams, maintainers, logistics personnel, engineers, and plant leaders encounter different external senders and operational pressures. Testing everyone with the same office-themed template may produce comparable numbers while revealing little about the decisions people make during supplier changes, maintenance events, shipping exceptions, or urgent production requests.
Prioritized Actions and Leadership Questions
First, change the program objective. The CISO and awareness owner should document that simulations are intended to improve recognition, safe handling, reporting, and response—not simply minimize clicks. This prevents the easiest metric from becoming the de facto goal.
Second, preserve difficulty and population context. Classify scenarios by difficulty, role relevance, communication channel, requested action, and potential consequence. Compare like with like. A quarterly average that blends easy mass emails with targeted credential lures is not decision-useful.
Third, connect simulations to identity and incident response. Measure how long it takes the SOC or service provider to investigate a high-confidence report and execute containment. Periodically run an end-to-end exercise in which the reported message triggers the same workflow expected during a real campaign.
Fourth, remove incentives to hide mistakes. The UK NCSC cautions that blame-oriented simulations can discourage reporting and erode trust. Its phishing defense guidance recommends making reporting simple, quick, and psychologically safe, including after a person has clicked. HR, legal, security, and business leaders should agree on how simulation results will be used before targeting individuals or teams.
Fifth, reduce the consequence of inevitable error. Training should complement phishing-resistant authentication, restricted privileges, transaction verification, email defenses, and rapid session revocation. For consequential payment or data-release requests, use independent verification paths such as those described in CyberEnablement’s executive impersonation playbook.
Leadership should ask:
- Which metric on our dashboard most directly represents exploitable credential exposure?
- Are trends normalized for exercise difficulty and workforce role?
- Can employees safely report a mistake after clicking or submitting information?
- What is our demonstrated time from the first report to campaign and identity containment?
- Which business owner accepts the residual risk where phishing-resistant authentication or dual authorization is not feasible?
My Perspective
My concern is not that organizations measure clicks. It is that many have allowed a convenient training statistic to stand in for a security outcome.
A click is an interaction. A credential submission is exposure. A prompt report is detection. A revoked session is containment. Those events belong in the same operational story, but they should not be assigned the same weight.
The new study should not be used to replace one universal benchmark with another. Its sample is not representative enough for that. Its stronger contribution is showing how misleading a single number becomes when exercise difficulty, workforce context, and downstream response are hidden.
I would treat the workforce as a distributed detection capability rather than a defective control waiting to fail. That does not absolve careless behavior or eliminate the need for training. It changes the design objective: make the safe action usable, make reporting easier than silence, and ensure that a report produces visible action.
Conclusion
Phishing simulations can expose meaningful weaknesses, but only if leaders resist converting their simplest output into assurance theater. Click rate belongs in the analysis; it should not carry the conclusion.
The next dashboard should show whether people surrender credentials, whether they report suspicious activity quickly, whether tests remain credible, and whether the organization can contain the resulting identity and messaging risk. That evidence gives leaders something more valuable than a lower percentage: a defensible view of whether the capability works when a believable message reaches a busy person.