A simulation should leave people better prepared to act, not wondering whether their employer’s next good-news email is another trap.
You can design a phishing test that gets clicks and still design a poor learning experience. The question security leaders should ask is what employees will do differently when the next real threat arrives. A memorable deception is useful only if it teaches a useful response.
“Congratulations, you caught an employee clicking. Now explain what you taught them.”
Joshua Crumbaugh, founder of PhishFirewall
The choice of lure matters
In September, Madison Square Garden employees reportedly received an email offering a choice of championship rings. Clicking led to mandatory cybersecurity training. MSG later apologized for using the ring offer as the lure. Separately, it said more than 275 rings and pieces of jewelry were already planned for people in the organization. This was a controversy about a training tactic, not proof that employees had been denied real rings. [1]
Our objection is straightforward. An organization should be careful about turning its own recognition of employees into the setup for a security lesson. The emotional investment may make the lure compelling. That does not make it a good teaching choice.
Attackers exploit excitement, urgency and authority. Employees absolutely need practice recognizing those pressures. But the defender controls the exercise: the scenario, difficulty, feedback and follow-up. Realism does not remove the responsibility to choose a lesson that people can actually use.
A click rate cannot tell you what people learned
A click is an observation. On its own, it does not explain why someone clicked, whether the message gave them usable warning signs, or whether they know how to verify a similar request next time. A clever lure can produce a dramatic number without producing a better decision.
Before sending a simulation, define the behavior you want to teach. Should the employee open a known internal portal instead of following an unexpected link? Call a trusted contact to verify a request? Report a suspicious message through a familiar channel? Those are actions someone can practice. “Be less trusting” is not a usable procedure.
“If your phishing test makes employees trust the security team less, your security team failed the test.”
Joshua Crumbaugh, founder of PhishFirewall
Make the next action obvious
A useful debrief gives the employee a clear explanation while the decision is still fresh. Identify the relevant cue, explain the pressure the message used, and show the safer action. Keep the feedback specific enough that the employee can apply it to a different message rather than simply memorize the last test.
For a benefits or recognition-themed example, the lesson could be to verify an unexpected offer through the organization’s established portal or a known contact. That is more helpful than telling people to distrust every welcome message they receive. If the organization has no reliable verification path, the process needs fixing too.
Five rules for a better simulation
Start with a learning objective. Choose the action first, then build a realistic scenario around it. Do not select a lure simply because it is likely to generate a high failure rate.
Set boundaries around sensitive themes. Review scenarios involving compensation, layoffs, health, personal distress and employee recognition. Ask whether the same skill can be taught with a less damaging scenario. Security and people leaders should agree on those boundaries before launch.
Coach privately and promptly. Make the follow-up useful, short and specific. Avoid public failure lists or framing training as the penalty for being fooled. Required training can still be constructive.
Recognize reporting and recovery. Thank people who raise concerns, including employees who report a mistake after clicking. Teach them what to do next. A program that measures only the initial click misses this important part of the response.
Measure more than the trap. Track reporting, time to report where available, repeated behaviors and performance on comparable scenarios. Ask employees whether they understood the lesson and knew where to get help. Interpret results in context rather than treating one campaign as a verdict on the workforce.
The PhishFirewall point of view
PhishFirewall is built around adaptive simulations, short learning moments and constructive feedback. Our platform supports personalized training, positive reinforcement and visibility into reporting and engagement. Those features should serve a simple goal: help people make better security decisions without making them the enemy. [2]
Automation does not excuse bad judgment about a campaign. A security team still needs sound objectives, appropriate scenarios and a clear way for employees to ask for help.
“Security awareness shouldn’t be an elaborate way to say, ‘gotcha’ to the people you’re supposed to protect.”
Joshua Crumbaugh, founder of PhishFirewall
The lesson for security leaders is to judge a simulation by the behavior it builds. Employees should finish knowing how to verify, how to report and what to do if they make a mistake. If the most memorable part is that their employer fooled them, rethink the exercise.
Want to move beyond gotcha-style phishing tests? Talk with PhishFirewall about a program built around relevant practice, useful feedback and the behaviors you want people to repeat.
Sources
[1] Associated Press reporting on MSG’s response, October 24, 2026
