A lower phishing click rate can still tell the wrong story

A dashboard shows that fewer employees clicked the latest simulated phishing message. The number is easy to understand, easy to compare and easy to present to management. It may also support a conclusion the exercise cannot justify.

Perhaps employees improved. Perhaps the new message was easier to recognize. Perhaps fewer people saw it, the timing was different, or the recipients were too busy to open any mail. A lower click rate is an observation. The explanation still needs evidence.

A security measure should describe the behavior and context it actually captured. When a single percentage becomes a score for organizational safety, it can hide the workflow problems that matter most.

Start with the decision the metric should support

A training team may want to know whether staff recognize a particular request. An incident team may care about how quickly reports arrive. A manager may need to know whether employees can verify a sensitive action without delaying legitimate work.

Those are different questions. Click rate may contribute to some of them, but it does not answer all of them.

Write down the decision before choosing the measurement. If the result will be used to redesign payroll verification, a generic delivery-themed email may provide little useful evidence about that workflow.

What the NIST Phish Scale contributes

The NIST Phish Scale User Guide, Technical Note 2276, provides a method for considering the detection difficulty of phishing messages, including cues and how closely the premise aligns with the recipient’s context. NIST’s human-centered phishing research explains the surrounding research area.

The scale is not a score of an employee’s intelligence and not a new 2026 discovery. Its value here is contextual interpretation: two exercises can produce different rates partly because they present different recognition challenges.

The measurement framework below is our editorial application of that principle. It is not a claim that a particular set of metrics is a validated universal benchmark.

A small hypothetical comparison

These numbers are invented solely to demonstrate interpretation. They are not research findings, target rates or predictions.

The table does not prove that a higher rate is acceptable. It shows why a ranking without context can misidentify where learning or control improvements are needed.

A serious review would examine the message, recipients, timing, delivery conditions and actions after interaction before assigning an explanation to the percentages.

Define what counts as a click

A metric needs an operational definition. Does it count a unique person, every request to a tracking address or only a browser interaction that meets a stated condition? How does the system handle automated inspection or preview behavior?

The responsible technical team should document those distinctions. Otherwise two tools can produce numbers that look comparable while measuring different events.

The denominator matters too. “Sent,” “delivered” and “realistically encountered” are not identical populations. Some accounts may be inactive, some employees may be absent and some messages may be filtered before reaching the intended surface.

You may not be able to measure every factor precisely. That is a reason to state limitations, not to silently assume the cleanest possible interpretation.

A click is one stage, not the whole incident

A person may click a link, recognize the problem at the next page and report it promptly. Another may avoid clicking but forward the message widely, ask a colleague to try it or follow a related instruction through a different channel.

Different actions create different risks and different opportunities for intervention. A single binary outcome can obscure that sequence.

Measure the stages relevant to the exercise: viewing the request, following a destination, submitting simulated information, approving an action and reporting. Use harmless simulation mechanics and avoid collecting real passwords or sensitive data.

Our guide to channel-switch trust boundaries explains why the consequential step may occur after the initial message. The measurement should follow the actual decision being tested.

Reporting deserves its own design

A report rate is useful only if reporting is available, understandable and connected to a response. Employees should know where to send a concern and what information is helpful.

Consider time to the first useful report, the clarity of the report and whether the receiving team could act on it. A report that says “I may have entered information here” can be more operationally valuable than a confident but incomplete “phishing” label.

Do not punish employees for reporting something that turns out to be legitimate. False alarms have costs, but a reporting culture that demands certainty can delay the incidents you most need to hear about.

Our reporting-without-blame guide discusses how acknowledgment and follow-up influence whether people disclose mistakes early.

Measure the verification path, not only recognition

Some requests are difficult to classify from the message alone. A supplier’s bank-change instruction may be well written and connected to real work. The expected defense is independent verification, not perfect visual detection.

An exercise can therefore ask whether the employee found the trusted vendor contact, whether the change was held pending confirmation and whether the approver could see the verification record.

That is a different success criterion from “never click.” It evaluates the control that should protect the payment even when the message looks convincing.

The invoice bank-change workflow provides a concrete example. A useful assessment should test the organization’s real authorization process rather than substituting an unrelated inbox puzzle.

Beware incentives created by the score

If managers are rewarded only for low click rates, they may prefer easy simulations or discourage staff from admitting interactions. If teams are publicly ranked, employees may focus on avoiding embarrassment rather than learning the response process.

These are possible incentive effects, not claims that every program produces them. The design question is whether the measurement encourages the behavior the organization actually wants.

Keep individual-level data restricted to a legitimate, proportionate purpose. Explain how the exercise data will be used and avoid unnecessary public naming or humiliation.

A learning program can be rigorous without becoming adversarial. It can identify repeated risk, provide support and improve controls while respecting the people whose work is being interrupted.

Choose scenarios without exploiting personal distress

A realistic premise should reflect work, but realism does not require manipulating bereavement, medical fears, layoffs or other highly sensitive personal concerns.

Select scenarios that test relevant decisions with proportionate impact. Review them with the people responsible for employee welfare, privacy and operational continuity where appropriate.

Explain the learning objective after the exercise and provide an actionable alternative. “You clicked” is not a complete lesson. “Here is how to verify this kind of change using the actual system” is more useful.

Do not leave employees believing that a simulated threat or promise was real longer than necessary for the approved exercise design. The program’s credibility is itself a resource that can be damaged.

Build a balanced review page

A useful summary can include the scenario and its business relevance, the population and delivery assumptions, the observed interaction stages, reporting outcomes and identified process obstacles.

Add limitations and proposed changes. Separate observations from interpretations: “twelve reports arrived within the exercise window” is different from “staff are now resilient.”

Where possible, compare like with like over time. If the scenario or population changes, describe the difference instead of presenting the percentages as a clean trend.

Include a qualitative finding or two from the workflow review. A broken reporting button or missing vendor contact can be more actionable than a small movement in an aggregate rate.

Close the loop after the chart

Assign owners to the fixes. If employees could not find the reporting route, make it visible. If the approval process depended on an absent manager, define an alternative. If a legitimate service sends confusing messages, improve that communication.

Then test whether the change worked using an appropriate method. That might be another simulation, a tabletop walkthrough or a direct usability check of the reporting process.

Do not treat another email exercise as the automatic answer to every finding. Some weaknesses belong to software configuration, vendor management, staffing or process ownership.

The most valuable result is not a prettier percentage. It is a clearer explanation of where the system helped people make a safe decision, where it failed them and what will change before a real incident tests the same boundary.