What if the weakest point in your security stack is sitting at a desk right now, clicking a link because it looks like a shipping notice? That is the reality most organizations face. Phishing simulation exists to test that human layer safely, before a real attacker does it for you. But a sloppy setup does more harm than good. It breeds resentment, skews your metrics, and teaches people to fear the security team instead of the attacker.
This guide walks through a practical, defensible phishing simulation setup, from getting approval to reading the results without fooling yourself. It is written for the person who has to actually run the thing: the IT admin, the security analyst, or the compliance lead handed the project on a Tuesday afternoon.
Start with Authorization, Not Templates
The single most common mistake is jumping straight into a phishing platform and firing off a campaign. Stop. Before a single email goes out, the program needs written approval from leadership and, depending on where you operate, from legal and HR too.
Why does this matter so much? Because simulation data records who clicked, who submitted credentials, and who reported the message. Under the EU’s General Data Protection Regulation, that is personal data about employee behavior. You need a lawful basis, a retention limit, and a clear statement of what you collect and why. In unionized workplaces or jurisdictions with strong labor protections, running covert simulations without notice can trigger grievances or legal complaints.
Practical steps that work in practice:
- Write a one-page program charter covering purpose, scope, data handling, and who sees results.
- Get sign-off from executive leadership, HR, legal, and any works council or union representative.
- Decide up front whether simulations are announced or unannounced, and document that decision.
- Set a retention period for click data, typically measured in months, not years.
The U.S. National Institute of Standards and Technology treats security awareness and training as a formal control area, and its guidance on building awareness programs is a useful reference when drafting your charter. You do not need to cite it in every meeting, but it gives your program a defensible backbone.
Define What Success Looks Like Before You Launch
Here is a trap that catches nearly everyone: launching a campaign, then deciding what the numbers mean afterward. Define metrics first.
| Metric | What It Tells You | Watch Out For |
|---|---|---|
| Click rate | How many opened and clicked | High volume can reflect curiosity, not risk |
| Credential submission rate | Who entered data on the landing page | The most meaningful risk signal |
| Report rate | Who flagged the message | The metric you most want to grow |
| Time to first report | How fast employees respond | Often more useful than raw report rate |
| Repeat clickers | Who clicks across campaigns | Small groups can distort averages |
A healthy program tracks report rate as its headline number, not click rate. A workforce that reports suspicious mail quickly is worth more than one that merely clicks less. If your platform only surfaces click rates, dig into the reporting data manually.
Set a baseline in the first campaign and resist the urge to publish league tables of departments. Public shaming backfires. People who feel embarrassed stop reporting, and reporting is exactly the behavior you need.
Choose Your Targets and Cadence Carefully
New programs often make the mistake of simulating the entire company at once. That creates a flood of support tickets, angry emails, and a help desk that cannot keep up. Start smaller.
A workable ramp looks like this:
- Campaign one: a small pilot group of 50 to 200 volunteers or a single department, clearly framed as a learning exercise.
- Campaign two: expand to a few departments with varied roles.
- Campaign three onward: company-wide, with a steady cadence of roughly once every four to eight weeks.
Vary difficulty across campaigns. Easy, obvious lures build confidence early. Harder, well-crafted messages test real judgment later. A realistic difficulty curve matters because attackers do not send the same crude email forever. If you want to understand how convincing these messages can get, the mechanics of what spear phishing involves are worth studying, since targeted messages are where simulation pays off most. (Phishing)
Also vary the theme. Password reset notices, shared document alerts, invoice reminders, and delivery notifications all work. Rotate them so employees learn the underlying pattern rather than memorizing one template.
Design Templates and Landing Pages That Teach
The template is the lesson. Get it wrong and the lesson is “the security team is tricking us.”
A few design rules that hold up in practice:
- Use real but safe domains. Never spoof a partner, vendor, or colleague’s actual address. Use a lookalike domain you own and control.
- Avoid sensitive themes. Layoffs, disciplinary action, health scares, and salary changes are off-limits. They generate fear, not learning.
- Keep landing pages educational. The moment someone submits credentials, show a clear teaching page explaining what happened and what to do next. Do not leave them staring at a blank screen.
- Never capture real passwords. Configure the platform to record the submission event, not the password itself. This is both an ethical and a legal necessity.
The landing page is where most programs waste their best opportunity. A good page takes sixty seconds to read, names the specific red flags in the email they just received, and points to a reporting button. A bad page says “You’ve been phished!” and nothing else.
If you want to ground the training in real-world patterns, a primer on what phishing is and how to recognize it gives employees the vocabulary to spot lures across email, SMS, and chat. Simulation without education is just a prank with a spreadsheet. (Teach Employees to Avoid Phishing)
Wire Up Tracking, Reporting, and Follow-Up
A simulation that ends when the campaign closes is not a program. It is an event. The follow-up is where behavior actually changes.
Build these pieces into your setup:
- A one-click report button in the mail client, so reporting is easier than ignoring.
- Automated acknowledgment when someone reports, thanking them and confirming the message was a simulation.
- Targeted micro-training for anyone who clicked or submitted, delivered within 24 hours while the lesson is fresh.
- A short debrief email to all participants after each campaign, showing aggregate results and the top red flags.
- A monthly review where you compare metrics against the baseline and adjust difficulty.
The follow-up training should be short. Two to five minutes. A fifteen-minute mandatory module after a simulated click feels punitive and drives people to complain rather than learn.
One more practical note: coordinate with your help desk before launch. Tell them the campaign dates, the sender addresses, and the expected volume of “is this real?” calls. Nothing derails a program faster than an unprepared service desk telling employees the simulation email is genuine.
Handle the People Side With Care
Technical setup is the easy part. The human side is where programs succeed or fail.
Do not punish clickers. If clicking a simulated phish appears in a performance review, your report rate will collapse. Employees will stop reporting real threats because they fear the consequences of being wrong.
Do publish aggregate results. Company-wide numbers build awareness. Individual naming does not.
Do celebrate reporters. A simple recognition for the fastest report or the highest-reporting team costs nothing and reinforces the right behavior.
Do not run campaigns during major incidents, holidays, or restructuring. Timing affects results and morale. A simulation during a genuine outage reads as tone-deaf.
If your organization runs other technical drills, the discipline transfers. Teams that already document setup steps for internal tools, whether it is a PlayFab multiplayer servers setup or a Mistral large 4 API setup, tend to handle simulation configuration more cleanly because they are used to writing down scope, owners, and rollback plans.
Pick and Configure Your Platform
Most organizations use a commercial phishing simulation platform rather than building one. That is sensible. Configuration, however, is where teams stumble.
A configuration checklist that prevents most problems:
- Verify sending domains and set up SPF, DKIM, and DMARC so your simulation mail does not get quarantined.
- Whitelist the simulation sending infrastructure with your email security gateway, or your campaigns will vanish into spam folders.
- Test every template by sending it to a small internal group first, including one person on a mobile device.
- Confirm the landing page renders correctly on phones, since a large share of clicks happen there.
- Check that the reporting button works and routes to the right inbox.
- Confirm data retention settings match your charter.
That last point gets skipped constantly. Platforms default to keeping data indefinitely. Change the default.
Measure Honestly and Iterate
After three or four campaigns, you will have enough data to see trends. Look for:
- Whether report rates climb over time
- Whether repeat clickers form a stable group or rotate
- Whether specific departments or roles consistently struggle
- Whether harder templates produce proportionally more clicks
A program where click rates fall but report rates stay flat is only half working. A program where report rates climb steadily, even if click rates wobble, is doing its job. The goal is a workforce that treats every unexpected message with mild suspicion and knows exactly where to send it.
Common Mistakes That Sink Simulation Programs
A quick list of the failures seen most often, so you can avoid them:
- Launching without written approval or legal review
- Using fear-based or personally sensitive lures
- Capturing actual passwords
- Publishing individual results
- Running campaigns with no follow-up training
- Never varying difficulty, so employees learn one template and nothing else
- Forgetting to brief the help desk
- Treating a single campaign as the whole program
Each of these is fixable, and most are fixable before launch. The cost of fixing them afterward is trust, and trust is much harder to rebuild than a DMARC record.
Conclusion
A phishing simulation setup is not a technical project with a human component bolted on. It is a trust-building exercise with a technical component. Get authorization first, define honest metrics, design templates that teach rather than frighten, and treat every click as a coaching moment rather than a disciplinary one. Do that, and the numbers will move in the right direction: fewer credential submissions, faster reports, and a workforce that recognizes a lure before it lands. Skip those steps, and you will have a spreadsheet full of clicks and a team that has learned to distrust the security department. The choice is yours, and it is made before the first email goes out.
FAQ
How often should phishing simulations run?
Most mature programs run campaigns every four to eight weeks. New programs should start slower, perhaps quarterly, while employees adjust and the help desk learns the volume. Consistency matters more than frequency. A predictable cadence builds familiarity without fatigue.
Is it legal to run phishing simulations on employees?
In most jurisdictions, yes, provided you have a lawful basis for processing employee data, written internal approval, and a clear data retention policy. Regulations such as the GDPR apply because click data is personal data. Always involve legal and HR, and check local labor rules, especially in unionized workplaces.
Should employees be told they are being tested?
Programs differ. Announced programs build trust and reduce resentment; unannounced ones produce more realistic data. Many organizations use a hybrid: employees know simulations happen, but not when. Document the decision and communicate the policy clearly so nobody feels ambushed.
What is a good click rate for a phishing simulation?
There is no universal benchmark, and published figures vary widely by industry and template difficulty. The more useful approach is to establish your own baseline in the first campaign and track the trend over time. Falling credential submission rates and rising report rates matter more than any absolute number.
Can we capture the passwords employees type into a simulation?
No. Configure the platform to record only that a submission occurred, never the password itself. Capturing real credentials creates serious legal and ethical exposure, and it undermines the trust the program depends on. This should be a hard rule in your program charter.
What should happen to an employee who clicks a simulated phish?
They should receive short, supportive training within a day, not discipline. Punishing clickers suppresses reporting and defeats the purpose of the program. The goal is to make reporting the easiest and most rewarded action an employee can take when something looks suspicious.
