A fake invoice arriving in an employee’s inbox at 4:55 p.m. on a Friday tests whether someone reports it. That scenario can make a security team uneasy. Phishing remains one of the most common ways attackers get a first foothold in a network, and a phishing simulation lets a security team rehearse the human side of defense before a real attacker does.
But running simulations badly can backfire. Employees feel tricked. Managers want names. Someone clicks a link and the IT team quietly captures a real password. A good phishing simulation checklist keeps the program honest: it forces decisions about consent, data handling, metrics, and follow-up before the first fake email ever goes out. This guide walks through what belongs on that checklist and why each item matters.
Why a checklist beats good intentions
Security awareness programs fail in predictable ways. Simulations get launched with no written policy, no baseline measurement, and no plan for what happens after a click. The result is a one-time event that produces a scary percentage in a slide deck and little else.
A checklist fixes that by turning an ad hoc exercise into a repeatable process. It also connects your program to recognized frameworks. The U.S. National Institute of Standards and Technology (NIST) publishes SP 800-50, the foundational federal guidance on building an IT security awareness and training program, which treats exercises like simulations as part of a broader learning cycle rather than a standalone stunt. NIST’s SP 800-53 Revision 5 contains control AT-2 on literacy training and awareness, which is where simulated attacks fit into formal control mapping. If you ever need to justify budget or scope to leadership, citing a control number helps more than a hunch.
The checklist, section by section
1. Get the policy and legal review done first
Before anything else, confirm that a written policy covers simulated phishing. That policy should state that the organization runs simulations, what data is collected, who can see it, and how results are used. In many jurisdictions, simulation data counts as employee monitoring. The EU General Data Protection Regulation (GDPR), applicable since May 25, 2018, requires a lawful basis and transparency for processing personal data, and behavior records from simulations fall into that category. In Germany, works councils may have co-determination rights over monitoring tools under the Works Constitution Act, so involve legal counsel and employee representatives early rather than after launch.
Common mistake: security teams treat legal review as a formality and run the first campaign while the policy is still in draft. When an employee complains, the program loses credibility it may never recover.
2. Define the goal before choosing the template
What is the simulation actually for? Typical goals include measuring baseline click rates, training the habit of reporting suspicious messages, testing whether a new report button gets used, or satisfying an audit requirement. Each goal implies different metrics and different email designs. A program aimed at building reporting habits should reward fast, accurate reports rather than focus only on punishing clicks.
Write the goal down in one sentence. If the sentence contains two unrelated goals, split them into separate campaigns.
3. Set a baseline and pick honest metrics
The most overused number in this field is the click rate. It is easy to measure and easy to misinterpret. A click is not a compromise. Someone who clicks a simulated link and then reports it has demonstrated exactly the behavior you want.
Use a small set of metrics and track them over time:
| Metric | What it tells you | Common pitfall |
|---|---|---|
| Click rate | How many people interacted with the lure | Treated as a verdict on intelligence |
| Report rate | How many flagged the message | Ignored when report buttons are hard to find |
| Time to first report | How fast the organization reacts | Not measured at all |
| Repeat clickers | Who needs extra coaching | Used to punish rather than support |
| Help-desk tickets | Whether the simulation caused confusion | Never reviewed |
Baseline first, then improve. Comparing your organization to vendor benchmarks is less useful than comparing this quarter to last quarter.
4. Choose difficulty levels deliberately
Start with obvious lures: mismatched sender names, clumsy grammar, generic greetings. As the program matures, increase realism gradually. A sudden jump to highly convincing, context-aware messages generates click spikes that tell you nothing except that the difficulty changed.
If you want to understand the difference between mass campaigns and targeted attacks, it helps to know what spear phishing involves, because highly personalized simulations sit much closer to that category and carry more emotional risk for employees.
5. Use safe payloads and never store real credentials
This is the item people skip, and it is the one that causes incidents. A simulation landing page should never accept and store a real password in plain text. Best practice is to accept any input, discard it immediately, and show a teaching moment. Some organizations block password entry altogether.
Decide in advance whether the simulation will capture anything typed. If it will, document encryption, retention limits, and access controls. If it will not, say so in the debrief so employees understand the exercise was designed to be safe. (How to check whether an apk file is safe)
6. Train the reporting pathway as well as suspicion
A simulation that teaches people to be suspicious but not what to do next creates paralysis. Before the first campaign, confirm that the report button exists, works on mobile, and routes to a monitored inbox. Tell employees what happens after they report: who triages, how fast, and whether they will hear back.
Practical tip: run a “report anything” drill in week one. Send a benign internal email and ask everyone to report it. You will discover broken Outlook add-ins and confused help-desk staff before a real campaign exposes them.
7. Plan the debrief before the launch
Every simulation needs a landing page or follow-up message that explains what happened, why it matters, and what to do differently. Keep it short, non-judgmental, and specific. “You clicked a link that looked like a delivery notice. Here are three things that gave it away” beats a generic wall of text.
For employees who repeatedly click, offer a short coaching session rather than a disciplinary referral. Punitive use of results is the fastest way to destroy trust and drive under-reporting. If someone hides a click because they fear consequences, your metrics become fiction.
8. Review vendor and data handling
If you use a third-party platform, ask where data is stored, how long it is retained, whether subprocessors are involved, and what happens on contract termination. Get the answers in writing. A simulation tool holds a detailed map of who is likely to click what, which is sensitive information in its own right.
9. Schedule cadence and communication
Most programs settle into a quarterly rhythm with a short campaign each time. Announce the program at launch, not each campaign. Employees should know simulations happen regularly without knowing exactly when. Publish aggregate results, never individual leaderboards. (Cyber Threats and Advisories)
10. Close the loop with real-world learning
When a real phishing email reaches the organization, use it. If it is safe to share, turn it into a mini-lesson. Real examples resonate more than fabricated ones. This is also a good moment to reinforce the basics of what phishing is and how to recognize it, since the tactics employees see in the wild shift constantly. (Phishing)
What actually works in practice
Experienced practitioners tend to agree on a few things that rarely appear in vendor marketing. First, reporting rate matters more than click rate, because a reported email protects everyone while a click only endangers the clicker. Second, short, frequent exercises beat annual marathons. Third, the debrief is the product; the email is just the delivery mechanism.
They also agree on what fails. Surprise campaigns aimed at catching senior leaders, public shaming of repeat clickers, and simulations that mimic real internal systems without warning all tend to produce backlash. One more failure mode: running simulations while the organization is mid-incident or during a major restructuring. Timing is part of the checklist.
A quick pre-launch sequence
- Confirm policy, legal review, and employee communication are complete.
- Verify the report button works and the triage inbox is monitored.
- Set the baseline metric and the target for this campaign.
- Approve the lure template and difficulty level.
- Confirm the landing page stores no real credentials.
- Brief the help desk so they recognize simulation reports.
- Schedule the debrief email for the same day.
- Book a review meeting two weeks after launch.
Conclusion
A phishing simulation checklist is really a trust document. It shows employees that the exercise has rules, that results will not be weaponized, and that the goal is a safer organization rather than a scarier one. Teams that treat the checklist as bureaucracy tend to learn the hard way why each item exists. Teams that follow it end up with something more valuable than a click-rate chart: a workforce that knows how to report, a help desk that knows how to respond, and leadership that understands the program is working.
Frequently asked questions
How often should a company run phishing simulations?
Quarterly campaigns suit most organizations, with a short debrief each time. Highly regulated industries sometimes run monthly micro-campaigns. The key is consistency and gradual difficulty rather than frequency for its own sake.
Is it legal to run phishing simulations on employees?
In most jurisdictions, yes, provided there is a lawful basis, transparency, and a written policy. Under GDPR, simulation data is personal data, so employees must be informed that monitoring occurs. Some countries require consultation with works councils or unions before launch.
Should simulations ever capture real passwords?
No. A well-designed simulation landing page accepts input, discards it, and shows a teaching message. Storing real credentials creates a breach risk with no training benefit. If a vendor’s default configuration captures passwords, change it.
What is a good click rate for a phishing simulation?
There is no universal benchmark worth chasing. What matters is the trend within your own organization. A rate that falls over successive quarters while report rates rise indicates the program is working.
Do simulations actually reduce phishing risk?
They help, but only as part of a wider program that includes reporting tools, email filtering, and fast incident response. Simulations train behavior; they do not replace technical controls. Programs that skip the debrief and the reporting pathway see little lasting change.
How should repeat clickers be handled?
With coaching, not punishment. A short one-on-one session, extra training material, and a check-in after the next campaign work better than disciplinary action. Punitive responses drive under-reporting, which makes the whole program less effective.
Who should own the program? Ownership matters less than coordination, but someone has to hold the thread. Common homes include IT security, compliance, or HR, and each brings a different bias: security teams tend to over-engineer lures, compliance teams tend to over-document, and HR teams tend to over-protect. Whichever team leads, give it a named owner, a budget line, and a standing agenda item with leadership. Programs without an owner quietly lapse after two campaigns, and the reporting habit you spent months building fades within a quarter.
Final word
Print the checklist, pin it where the program team can see it, and revisit it before every campaign rather than once a year. The items that matter most—safe payloads, a working report button, a same-day debrief, and a no-blame culture—are also the ones most often skipped under deadline pressure. Treat each campaign as a small experiment with a written goal, a baseline, and a review date. Do that consistently, and the metrics will take care of themselves.
