Most phishing simulation programs become an annual ritual where the security team sends a deceptive email, watches employees click, and then makes them watch a video as punishment. Useful programs do something else entirely.
Most phishing simulation programs are theater. The security team sends a deceptive email at the start of the quarter, watches the click rate, sends out a "results" email with the percentage who failed, and assigns a fifteen-minute training video to everyone who clicked. The click rate ticks down a few points, the team writes it up, and nothing meaningful changes.
The pattern fails because it treats the human as the bug instead of the system. Useful programs do the opposite.
The shift in mindset
A phishing simulation is not a test. It is a measurement. The number you care about is not how many people clicked — it is how quickly the people who *did* notice it told someone, and what happened when they did.
Two organizations have a 10% click rate on the same simulation. In Organization A, three people reported the email within ninety seconds, the security team blocked the source within five minutes, and an all-staff alert went out within fifteen. In Organization B, nobody reported, the security team learned about the simulation only when the click counter started moving, and the all-staff alert never went out.
Same click rate, completely different security postures. The first organization is in good shape. The second one is in trouble. Click rate alone does not surface the difference.
What to measure instead
- Time to first report. From simulation send to the first employee report.
- Number of reports per click. A healthy organization has reports outnumbering clicks several to one.
- Time to platform action. From first report to a blocked sender, deleted message, or security advisory going out.
- Repeat clicker rate. Most clickers click once and never again. Repeat clickers are the signal that needs follow-up — gently, individually, not via mass training.
- Reporting-channel fairness. Do reports come in only from senior staff, or also from front-line employees? If only senior, the front-line either does not know how to report or is afraid to.
Designing simulations that teach
- Use realistic lures, but make them realistic for *this* organization's reality. Generic "your password expired" templates are easy to dismiss as obvious; tailored ones land closer to what real attackers send.
- Vary difficulty. Easy lures every time produce a meaningless 1% click rate. Mix easy, medium, and hard so people see what hard looks like.
- Include the report-success path. The first time someone reports a simulated phish, the response should be a thank-you, not silence.
- Brief leadership on the program. Surprise simulations targeting the CEO can produce career-affecting confusion if leadership has not been briefed.
What to absolutely not do
- Public shaming. Don't post the names of clickers, even in a friendly tone. It teaches employees to hide mistakes.
- Punitive remediation. A mandatory training module assigned to the clickers feels punitive even when framed otherwise. It teaches the organization that admitting confusion has a cost.
- Lures that exploit personal anxiety. Fake bonus letters, fake layoff announcements, fake medical results. These cross a line.
- Over-frequent simulations. Once a month is ambitious. Once a week is harassment.
What the security team owes back
A phishing simulation is the security team asking employees for trust. That trust has to be earned and re-earned.
- Tell people the program exists and that they will be tested. The element of surprise is the simulation itself, not the program's existence.
- Publish click rates and reporting rates as program metrics — not employee metrics.
- Run a "live" reporting channel for real phishes alongside the simulation channel. Make it work the same way and feel the same.
- When real phishes get through, write it up as a system improvement, not a user failure.
The hard part: changing what the report-fail does
In most organizations, the report-fail flow is not designed at all. The employee receives a phishing email, hovers their cursor, hesitates, deletes it, and moves on. The security team learns nothing.
Build the report-success flow first. A one-click "report" button in the mail client, a clear acknowledgment, a periodic "thank you, here's what your reports caught this month." Then the simulation has somewhere to land. Without that, the simulation is just measuring the absence of infrastructure.
A program that works at one year
- Click rate trending down, slowly, with realistic difficulty
- Report rate trending up, faster than click rate
- Real phishing emails detected by employees in roughly the same time as simulations
- Repeat clickers identified individually and supported, not punished
- Leadership engaged in the program, not its target
The point of a phishing program is not to grade employees. It is to make the organization a harder target by giving every employee a working alarm. Build the alarm first; the simulations are how you check it still works.