Report rate, click rate and retest: what to measure

The bottom line: reporting beats not falling for it, but only the retest proves behavior changed

If we had to sum up this year's metrics debate in one sentence, it would be this: report rate is a better signal than click rate, but neither of them proves that a person has changed their behavior. Only retesting them does. The three metrics (how many fall for it, how many report it, and how many resist when the same kind of trap is set again weeks later) measure different things, and confusing them is the most common mistake on 2026 security dashboards.

Cisco's 90-5-5 framework, which estimates that nearly 90 percent of breaches involve a human factor, is why this discussion matters so much. If the risk lives in people, measuring the program that prepares them is not a luxury, it is the only way to know whether the money spent reduces real risk or just produces activity. And activity is not outcome. A team can report a lot, run many simulations, and still be no more resilient. The question that orders everything is simple: does this metric measure that someone did something, or that someone changed?

Why click rate stopped being enough on its own

Click rate (the percentage of people who fall for a phishing simulation) was the industry's first metric and it is still useful, but as a single number it falls short. Its limit is twofold. First, it measures what went wrong, not what was learned: a low click rate can mean the team improved or, just as easily, that the simulation was easy to spot. Second, it is easy to dress up. Sending unconvincing lures is enough to make the number look good in the report to leadership, without anyone being better protected. CISA's canonical figure, that more than 90 percent of successful cyberattacks begin with a phishing email, is a reminder of why click rate was born: the click is the door. But measuring only the door that opens leaves out what really matters, which is what the person does when they recognize the trap.

That gap is what pushed the search for a metric that captured the right behavior, not just the absence of the wrong one. We covered the broader framework in how to measure if security training works; here the focus is narrower and more uncomfortable: the exact ladder of three metrics and the order in which to read them.

What report rate measures and why it is emerging as a maturity signal in 2026

Report rate is the percentage of people who, on receiving a suspicious email, flag it through the proper channel instead of ignoring it or clicking. It is the metric that is emerging this year as a program's maturity signal, and for good reason. It measures an active, desirable action: the person not only avoids the trap, they warn, and that warning can alert the security team to an ongoing campaign before someone else falls. An employee who reports becomes a sensor. Against click rate, which only says who failed, report rate says who helped defend. It is a healthy shift in perspective: it moves from counting mistakes to recognizing the behavior we want to see more often.

That is why this year's conversation, pushed by regulatory pressure and by several players in the market, revolves around reporting instead of merely not falling for it. The direction of that shift is not in doubt. The problem is not that report rate is a bad metric, it is that it is being adopted as if it were the final goal, when it is really an intermediate step.

The limit of report rate: it measures intent to warn, not sustained behavior change

Here it is worth being honest, because it is the point almost no one says out loud: report rate measures the intent to warn at a given moment, not that the person's behavior has changed in a stable way. Someone reporting an email today does not guarantee that next week, with a different pretext, more urgent or better personalized, they will not click. Reporting captures a good one-off reflex; it does not capture resilience over time.

And like any metric that becomes a target, report rate can be inflated. If the program rewards reporting, people over-report, even legitimate emails, and the number climbs without anyone becoming harder to deceive. It is the old trap of managing toward the metric instead of toward the outcome: when a measure becomes the goal, it stops being a good measure. Adopting only reporting over clicking, with nothing else, is taking half the road and stopping right before the part that proves change. The next step is missing.

The retest as the next step: probing the same category again weeks later

The retest means probing the person again, weeks after a failure or a training, with an attack of the same type and difficulty but a different pretext, to see whether they resist this time. It is the only one of the three metrics that answers the question that truly matters: did the behavior change, or did the person just remember one specific email? The difference is huge. Passing a training right after falling proves short-term memory. Resisting a fresh attempt three weeks later, when the lesson is no longer fresh and the context is different, proves that something holds.

This idea has backing. There is peer-reviewed evidence that completing a training does not, on its own, predict a reduction in real failures; what demonstrates change is observing behavior again under similar conditions. So writing that an employee "has been trained" is not an outcome figure, it is an activity figure: traditional training, on its own, does not verifiably change behavior, a point we questioned in why traditional training does not change behavior. The retest turns an assumption ("we assume they learned") into a measured fact ("we probed them again and they resisted"). It is, on the ladder of the three metrics, the only rung that touches outcome instead of activity.

How to read the three metrics together without confusing activity with outcome

The three metrics do not compete, they complement each other, but only if they are read in the right order and without confusing what each one measures. Click rate watches the entry risk. Report rate recognizes the desired behavior. And the retest validates that the behavior holds. Reading them together avoids the mirage of a dashboard that looks good (low click, high report) while real resilience remains unproven.

The practical rule for leadership is to read right to left when deciding whether the program works: first the retest, which is the outcome, and only then report rate and click rate as process signals that feed it. A board report showing only click and report is counting effort; one showing retest is counting effect. The point this piece adds to that distinction is the warning not to crown report rate as the final goal. It is an excellent rung, as long as it is not mistaken for the summit.

At bottom, all of this is a Human Risk Management (HRM) problem: the discipline that measures and modifies how people behave under pressure, not how much they know on a test. And in that discipline, the highest bar is not how many warn, it is how many resist when they are probed again.

At Fensivo we build the program around that last rung. We track click and report as process signals, but the heart of the system is the retest: when someone fails, they get short training in the moment and, weeks later, a fresh simulation of the same type with a different pretext validates whether their behavior really changed. You can see how it works in our use cases. The question we leave open is the one that orders the dashboard: when your next report shows a rising report rate, will you be able to say whether your team learned to resist, or only learned to warn?