How to introduce phishing simulations without punishment

The bottom line: a simulation that humiliates teaches people to hide the slip, not report it

When a company introduces phishing simulations, the decision that matters most is not which template to send, it is the culture you send it with. A simulation framed as a trap to catch the careless teaches the team to hide the slip and distrust the security function. A simulation framed as blameless practice, announced before it starts, teaches the team to report. The goal is not to hunt whoever clicks, it is to build a place where flagging a suspicious email is normal and safe.

The first step only sounds contradictory: announce the program before the first send. You do not reveal which email will arrive or when, but you do explain that the company will run simulations, why it does so, and what happens if someone falls for one, which is nothing bad. From there, introducing the practice without breaking trust is a four-step process:

Communicate the program before the first send, with clear rules and no punitive surprises.

Define what to do, and what not to do, when someone falls, so the slip is not experienced as humiliation.

Turn the slip into immediate, specific microlearning, not a report to the manager.

Validate the change with a retest weeks later, not another scare.

All four steps share one idea: the person is the target of the attack, not the cause of it, and the program is designed to strengthen them, not expose them.

Why the catch-the-employee approach costs you

Start with what is at stake, because it explains why tone matters so much. Cisco's 90-5-5 framework estimates that close to 90 percent of breaches involve a human factor, which makes one thing clear: the person is the surface where most incidents are decided. The wrong reading of that number is to treat that person as a suspect to be watched. The right reading is that this, human judgment under pressure, is where risk can be reduced the most, and that happens by strengthening people, not by punishing them.

When a simulation is designed to catch, it produces the opposite of what it wants. Someone who falls and feels ashamed learns two things, and neither is the one we want: they learn to hide the slip, and they learn to distrust internal security emails, which is exactly the channel a report should travel through. A team that hides its slips leaves the security function blind, finding out about problems only once they are incidents. This is where the idea of a security behavior and culture program comes in: the work is not to catch people, it is to change how the whole organization reacts to a suspicious email. Nobody reports a slip they expect to be punished for.

Step 1: communicate the program before the first send

The most common mistake at the start is silence: sending the first simulation with no warning, to see who really falls. That surprise debut defines the entire relationship with the program, and it defines it badly. Before the first send, it helps to communicate four things to the team, without revealing the templates or the dates.

First, what will happen: the company will send practice emails that mimic real attacks, on a regular basis. Second, why: not to grade anyone, but to train a reflex that attackers exploit every day. Third, what happens if someone falls: they get a short lesson in the moment and go on with their day, with no penalty, no public list, no email to the boss. Fourth, what is expected of the team: to report the emails that look suspicious, whether they are a simulation or not, with a button or a clear address. Once people understand that reporting is what gets recognized and falling is not what gets punished, the practice starts with trust on its side.

Step 2: define what to do, and what not to do, when someone falls

Simulations are run on email because email is still the main way in: more than 90 percent of successful cyber-attacks start with a phishing email, according to CISA. Practicing on that vector makes complete sense. What decides whether the practice builds or destroys trust is what happens in the minute after someone clicks.

What to do: show right away, on the same screen, that it was a simulation and which signals gave it away, in a tone that informs rather than scolds. Log the event for the risk score internally, without exposing the person in front of their coworkers. Treat the slip as what it is, a chance to learn about an attack that sooner or later was going to arrive for real.

What not to do: no public lists of who fell, no emails in a reprimanding tone, no alerting the manager as the first reaction, no comparing one person against another. The moment of the slip is the most fragile point in the whole program. If the person feels exposed there, they never trust it again, and everything else falls apart.

Step 3: turn the slip into immediate microlearning, with no punishment

A slip only teaches if the lesson arrives at once and is specific. A generic video about what phishing is, sent three weeks later, changes nothing: by then the person has forgotten the email they fell for. What works is short microlearning, a couple of minutes long, that appears at the moment of the click and speaks to the exact attack that fooled them: what pretext it used, what signals it carried, and how to recognize it next time.

That approach is not a format preference, it targets the real reason traditional training does not change behavior. Most people spend a minute or less on training material, so a long, ill-timed lesson gets ignored. A short lesson, immediate and tied to a concrete slip, gets remembered. And, a key point for trust, the microlearning is not a punishment: it is the help the person receives so they do not fall again. If the program escalates anything to the manager, it should be triggered because someone did not complete their lesson, not because they fell. It unblocks a pending task, it does not flag a culprit.

Step 4: validate the change with a retest, not another scare

The last step is the one almost nobody takes, and it is the one that proves the program works. Completing the lesson does not show the behavior changed. There is peer-reviewed evidence that having completed training does not, on its own, predict a reduction in real failures (Ho et al., IEEE S&P 2025; Lain et al., IEEE S&P 2022): people pass the module and fall again. What proves the change is testing the behavior once more.

That is what a retest is: weeks after the slip, the person receives a simulation of the same category and difficulty, but with a different template and context. If they do not fall this time, there is real evidence they learned the lesson and did not just memorize that one email. If they fall again, the program knows and adjusts, without dramatizing it. Seen this way, a retest is not another scare or a second trap: it is the honest way to know whether the practice worked, and it fits the reporting culture because it measures the organization, it does not single out the person.

A human risk management (HRM) program built on this principle automates what matters most in this approach: it delivers the specific microlearning within minutes when someone falls, with no penalty, and weeks later it sends a retest of the same category with a different template to validate that the lesson stuck. That is how we designed Fensivo, which treats every slip as a learning point and not a fault, so that introducing simulations strengthens the team's trust instead of eroding it. To see how it applies to a specific case, there are our use cases.

Will the next phishing simulation serve to point at whoever fell, or to build a team that reports without fear?

Sources and references

• CISA, Shields Up: Guidance for Families: https://www.cisa.gov/shields-guidance-families
• Cisco, The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity (2025): https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity
• Ho et al., Understanding the Efficacy of Phishing Training in Practice, IEEE Symposium on Security and Privacy 2025: https://ieeexplore.ieee.org/document/11023357/
• Lain et al., Phishing in Organizations: Findings from a Large-Scale and Long-Term Study, IEEE Symposium on Security and Privacy 2022: https://ieeexplore.ieee.org/document/9833766/