What a retest is and why it proves behavior changed

The conclusion: a retest sends the same category of attack weeks later, with a different template, to see whether the person learned the lesson or just the email

A retest is the second behavioral test an employee receives after failing a simulation: weeks later, another simulated attack of the same category and difficulty arrives, but with a different template, sender and context. Its purpose is narrow and very concrete: to separate the person who understood the mechanism of the deception from the person who simply memorized the email they fell for.

Everything else a security awareness program measures describes activity. The retest describes outcome, because it is the only measurement that puts the person back into the situation they already failed, unannounced, and watches what they do this time.

What a retest is and where the idea comes from

The retest did not come out of the training industry. It came out of a methodological discomfort: every awareness program claims it changes behavior, yet almost none measures behavior again after intervening. The failure is measured, the remedy is delivered, and the loop is declared closed on the evidence that the remedy was consumed.

The idea is borrowed from any discipline that evaluates an intervention seriously. Nobody considers a condition treated because the patient showed up to the appointment; you measure again. Applied to the security of people, a retest is exactly that: a second observation under equivalent conditions, separated in time from the first, which turns a claim into a measurement.

It is worth remembering why the effort concentrates on email. CISA notes that more than 90 percent of successful cyberattacks begin with a phishing email, so the corporate inbox is still where most of the test is played out, with newer fronts (voice, text messages, QR codes) adding to that ground rather than replacing it.

How it differs from resending the same simulation

Resending the same email measures memory. A retest measures judgment. The difference lies in what is kept and what is changed between the first test and the second.

A well designed retest keeps three things: the category of the deception (the instinct it exploits, for example executive authority or financial pressure), the level of difficulty, and the fact that the person does not know they are being evaluated. Everything else changes: the sender, the subject line, the story, the design and the impersonated platform. If the person falls again, it is not because they failed to recognize one specific email, it is because the mechanism that deceived them still works on them.

When the original template is repeated, the result is predictable and uninformative. Someone who just took training about that exact email will spot it, and the program records an improvement that does not exist outside the lab. That is the most common way to produce a flattering number without having reduced any risk. It is also why varying style between sends matters: a team can learn to recognize the simulator instead of learning to recognize the attacker.

Why completing training is not proof of change

Because completing is an act, not a behavior. Peer reviewed evidence says it plainly: completing training does not by itself predict a reduction in real failures (Ho et al., IEEE S&P 2025; Lain et al., IEEE S&P 2022). The module can be well built, short and delivered at the exact moment of the mistake, and its completion still does not constitute evidence that the person will act differently next time.

This is not an argument against training, it is a correction of its role. Training is remediation, the action taken after the failure to give the person a useful explanation of what happened to them. The proof comes afterwards, and it is of a different nature. Confusing the two is the underlying reason so many training programs change nothing while still reporting perfect compliance.

Cisco's 90-5-5 framework, which estimates that around 90 percent of breaches involve a human factor, explains why this distinction is not academic. If most of the risk runs through the conduct of people, a program that can only demonstrate content consumption is not measuring what it claims to measure.

How to read a retest: passing, repeating the failure, and the risk floor

A retest has three possible readings, and none of them is a simple pass or fail.

The first is that the person does not fall. That is the good signal, but it should be read with care: a single success can be luck, a quiet day, or a simulation that arrived at a bad moment for the simulated attacker. This is why a retest makes sense as a series, not as a one time exam.

The second is that the person fails again in the same category. That is the most valuable signal the program produces, uncomfortable as it is, because it points to a specific pattern of vulnerability rather than to general carelessness. Someone can resist urgency pretexts without trouble and give in to authority every single time, and that profile becomes actionable: it says what to reinforce and in which scenarios to test again.

The third reading is the risk score over time. The sensible practice is that a failure leaves the person at an elevated risk level that does not drop because they passed the module, nor because they survived one later simulation, but only after several consecutive tests without falling. That floor prevents the effect that ruins most dashboards: risk declared resolved because somebody clicked "understood". If click rate, report rate and retest all live on the same dashboard, it helps to be clear about the order in which those three metrics are read: there the retest is one step on a measurement ladder, here it is the whole mechanism.

How often it makes sense to test again

The reasonable interval sits around three weeks after the failure. The reason is a balance between two opposite errors. If the retest arrives two days later, it measures fresh memory rather than internalized judgment. If it arrives six months later, it is no longer measuring the effect of that training but the general state of the person, mixed with everything that happened in between.

That interval also respects how a team's attention actually works. Three weeks is long enough for the specific email to fade and for daily work to return to its normal rhythm, which is precisely the condition under which real deceptions happen. For someone who has not failed, the logic is different: there is no retest to apply, there is a regular cadence of simulations that keeps the muscle working, varying style and difficulty so that nobody learns to recognize the drill instead of the attack.

One last warning about interpretation. A retest does not produce a certificate, it produces a time series. Its value is not in one month's snapshot but in the recurrence curve of a population over a year, which is what really indicates whether the program's human risk management (HRM) is reducing exposure or merely generating activity.

At Fensivo the retest sits at the center of the cycle: when someone falls for a phishing simulation they receive, within minutes, training specific to the attack that deceived them, and three weeks later another simulation of the same category and difficulty arrives with a different template, to validate that they learned the lesson and not the email. The failure also leaves them at an elevated risk level that only lifts after several consecutive tests without falling. You can see how it works in our use cases.

The question we leave open is uncomfortable on purpose: if tomorrow one of your employees passes the module after falling for a phishing email, what evidence would you take to your board that they will not fall again?