A phishing simulation that ends with a list of “who clicked” sent to line managers teaches one lesson: hide your mistakes. That is the opposite of what you need on the day a real attacker gets through and the only thing standing between you and a breach is an employee willing to say “I think I clicked something”.
What a phishing simulation program is for
A simulation program sends realistic but harmless phishing emails to your own staff, then uses the results to train and to measure. For a refresher on the threat itself, see what phishing is and how to spot it.
Set the goals in writing before you pick a tool. Good goals are about behaviour and process:
- Build the reporting reflex – staff who report suspicious messages quickly, whether or not they clicked.
- Test the reporting pipeline – does the report button work, and does the security team or SOC triage and act?
- Give safe practice – spotting a lure in your own inbox is a different skill from spotting one on a slide.
- Target training – results show which scenarios and teams need more support.
- Track a trend – one campaign tells you little; twelve months show whether behaviour is changing.
Notice what is missing: “find out who is careless”. If that is the real goal, people will stop reporting and start warning each other about “the IT test” instead.
Getting approval before you send anything
Simulations involve deception and record what individuals do, so they need sign-off beyond the security team. A short charter agreed in advance avoids most later arguments.
Who needs to be involved
- Executive sponsor – someone senior who will back the program when an executive clicks and complains.
- HR – to agree results are not used for discipline and to flag staff who should be excluded.
- DPO and legal – for the GDPR and employment-law points below.
- Employee representatives – in Italy and several other EU countries, they may have a formal role. Involve them early.
- IT, SOC and helpdesk – to allowlist the platform without weakening real filtering, and to agree how simulated reports are handled.
Program charter checklist
- Purpose and goals, in plain language
- Who is in scope, who is excluded and why
- What data is collected, who sees it, how long it is kept
- Aggregate reporting by default
- A written commitment that results are not used for disciplinary action
- Off-limits lure topics
- How employees are informed that the program exists
- Escalation route if a simulation causes distress
Designing simulations ethically
Your program depends on staff trusting the security team. Ethical design keeps it effective for years, not months.
No punishment culture
Punishing clicks feels logical but backfires. People who fear consequences delay reporting, delete the email and hope, or quietly ask a colleague instead. In a real incident, those lost minutes matter. Make it explicit that clicking a simulation leads to a short learning moment, never a disciplinary note, and that reporting, including your own click, is always the right move.
Avoid “worst department” leaderboards and never name individuals. Celebrate reporters instead.
Cruel lures to avoid, and why
Some lures work very well precisely because they exploit hope or fear. That is exactly why you should not use them in a simulation:
- Fake bonuses, pay rises or holiday gifts. Telling staff they are getting money, then revealing it was a test, feels like a betrayal. The lesson people remember is that the company played with their pay, not how to spot a phish.
- Redundancies, restructuring or disciplinary notices. These can cause genuine anxiety, and staff may act on them before realising they are fake.
- Health results, medical appointments or personal emergencies. These can be distressing, especially for people dealing with illness or bereavement.
- Charity appeals after real disasters. Exploiting a current tragedy damages trust and reputation if the campaign becomes public.
There is a practical reason too: if simulations impersonate HR on sensitive topics, staff learn to distrust genuine HR messages. And screenshots of a cruel test travel outside the company quickly.
Attackers do use these themes, so cover them. Do it in training content, examples and discussions, not by tricking people with them.
Other ground rules
- Use an established simulation platform or your email security suite’s attack simulation feature, not ad-hoc tooling.
- Configure landing pages so text typed into a fake login form is not stored. You only need to know something was submitted.
- Do not impersonate a real, named colleague without their agreement.
- Never attach anything executable, even if harmless.
- Keep simulations to work accounts. SMS or voice tests to personal phones raise extra privacy questions.
Difficulty levels
A click rate means nothing without knowing how hard the email was to detect. NIST’s Phish Scale (Technical Note 2276) rates difficulty using two factors: the number of visible cues in the message, and how closely the premise matches the recipient’s real work context. A well-aligned lure with few cues is hard for anyone.
A simple four-level model works for most organisations:
| Level | Description | Typical cues | When to use |
|---|---|---|---|
| 1 – Basic | Generic, obvious lure | Odd sender, spelling errors, urgent generic request | Baseline and new starters |
| 2 – Moderate | Plausible everyday scenario (parcel, shared document) | Mismatched link, slightly wrong domain | Core of the program |
| 3 – Targeted | Matches a team’s real work (invoice for finance, CV for HR) | Few cues; premise is credible | Teams that have mastered level 2 |
| 4 – Advanced | Highly context-aware, few or no visible cues | Mostly process cues (unexpected request, payment change) | Occasionally, for high-risk roles, with extra care |
Record the level of every campaign. When you compare months, compare like with like.
Cadence
Start with a baseline campaign at level 1 or 2 so you know where you stand. After that, most organisations send each person one simulation every four to six weeks. That is frequent enough to build habit, not so frequent that staff feel watched.
- Stagger send times and vary templates so the whole company does not get the same email at 9:00.
- If colleagues warn each other, treat that as good behaviour, even though it distorts click numbers.
- Raise difficulty gradually, team by team, as report rates improve.
- Pause during high-stress periods such as restructurings or major incidents.
Metrics that matter: report rate vs click rate
Click rate is the number most people quote, and the least useful on its own. It depends on lure difficulty, never reaches zero, and may fall simply because templates got easier.
Report rate tracks real defensive value. In a genuine attack, one early report lets the security team find and remove the same email from every other inbox. The incident response clock starts with that report.
| Metric | What it tells you | Watch out for |
|---|---|---|
| Report rate | Share of recipients who reported the email | Make reporting one click; a clunky process hides progress |
| Time to first report | How quickly the organisation “notices” a campaign | Measure per campaign, not per person |
| Click rate | Share who opened the link | Only meaningful alongside difficulty level |
| Submission rate | Share who entered data on a landing page | Record the event only, never the content |
| Report-after-click rate | Share of clickers who then reported | A rising number is a strong culture signal |
| Repeat clicks | People who click across several campaigns | Handle privately and supportively |
Follow-up micro-training
The moment after a click is the best teaching opportunity you will get. Use it well:
- Landing page: a short, friendly explanation that this was a simulation, with the specific cues in that email highlighted. Aim for 60 to 90 seconds of reading.
- Tone: no shaming language. “This one was tricky – here is what gave it away” works better than “You failed”.
- Reporters: send an automatic thank-you that confirms they did the right thing. Positive feedback is what builds the habit.
- Repeat clickers: offer a short private conversation or an extra module on the scenario type they struggle with. Often the cause is workload or role, and the fix is a process change.
Simulations work best as one part of a wider program. See our guide to building a security awareness program that works, and our article on protecting against social engineering for the broader threat.
Legal and privacy considerations in Europe
This is general guidance, not legal advice. Rules differ between EU member states and between public and private employers, so involve your DPO and an employment lawyer before launch.
GDPR
Simulation results are personal data: who received which email, whether they clicked, when, and often from which device. The GDPR applies in full.
- Lawful basis. Private employers usually rely on legitimate interests (Article 6(1)(f)), the interest being the security of systems and data. Document a legitimate interests assessment that weighs that interest against employees’ rights. Consent is rarely suitable in employment, because the imbalance of power means it is hard for it to be freely given. Public authorities cannot rely on legitimate interests for processing in the performance of their tasks, so they will need another basis.
- Transparency. Articles 13 and 14 require you to tell people about the processing. You can announce that a simulation program exists, what it collects, who sees results and how long they are kept, without revealing when or what emails will be sent.
- Data minimisation and purpose limitation. Article 5(1) requires you to collect only what you need and use it only for the stated purpose. In practice: report in aggregate, limit individual-level access to a small team, never store submitted credentials, set a short retention period, and do not reuse results for performance reviews.
- DPIA where appropriate. Article 35 requires a data protection impact assessment where processing is likely to result in a high risk. The EDPB-endorsed DPIA guidelines (WP248) list criteria including systematic monitoring and vulnerable data subjects, a category that includes employees. Many organisations conclude a DPIA is appropriate for simulations; at minimum, document why you decided one was or was not needed.
Article 88 also allows member states to set more specific rules for processing in the employment context. That is where national labour law comes in.
Italy: Statuto dei Lavoratori Article 4 and Garante guidance
In Italy, Article 4 of the Workers’ Statute (Law 300/1970, rewritten by Legislative Decree 151/2015) governs tools that allow remote monitoring of employees’ activity. In summary:
- Paragraph 1: audiovisual systems and other tools from which remote monitoring of workers may also result can be used only for organisational and production needs, workplace safety or protection of company assets. They require a prior collective agreement with the company’s union representatives or, failing that, authorisation from the National Labour Inspectorate (INL).
- Paragraph 2: that procedure does not apply to tools employees use to perform their work, or to tools that record access and attendance.
- Paragraph 3: information collected can be used for all purposes connected with the employment relationship only if workers have been given adequate information about how the tools are used and how checks are carried out, and in compliance with the Italian Privacy Code (Legislative Decree 196/2003).
The Privacy Code (Article 114) refers back to Article 4, and the Garante has issued guidance on workplace monitoring. Its 2007 guidelines on email and internet use at work ask employers to state clearly how these tools may be used and whether and how checks are carried out, and rule out practices such as systematic reading of employees’ email. Its 2024 guidance document on email management software and metadata indicates that, for infrastructure purposes, email metadata should be kept for a limited time (as a guide, no more than 21 days), and that broader retention enabling indirect monitoring of workers requires the Article 4(1) safeguards.
We have not found Garante guidance on phishing simulations specifically, so the question is how these general rules apply to your design. A platform recording each employee’s behaviour may be viewed as a tool allowing remote monitoring; whether paragraph 1 or 2 applies is a judgement for your labour lawyer and DPO. Steps that reduce risk: involve union representatives early, give clear written information to staff in line with paragraph 3, keep data pseudonymised and aggregated, apply short retention, and commit that results will not be used for discipline.
Other countries have their own rules, such as works council co-determination rights in Germany, so check each country you operate in.
Test the response side too: a tabletop exercise built around a successful phish shows whether reports become fast containment.
AceFortis runs practical phishing simulation and awareness training for teams and management – get in touch to plan a session.
FAQ
Should we tell employees that phishing simulations will happen?
Yes. Announce the program, its purpose and how data is handled, without revealing timing or content. The GDPR requires transparency and, in Italy, adequate information is a condition under Article 4(3) of the Workers’ Statute for using the data collected.
Should repeat clickers face disciplinary action?
We recommend not. Punishment reduces reporting, the behaviour you most need. Offer targeted support and look for process causes. Using results for discipline also raises extra legal questions in many jurisdictions.
How often should we run simulations?
About one per person every four to six weeks, after a baseline. Adjust difficulty by team rather than increasing frequency.
Is click rate useless?
Not useless, but misleading on its own. Read it alongside difficulty level, and give more weight to report rate and time to first report.
Sources
- Regulation (EU) 2016/679 (GDPR) – EUR-Lex
- Article 29 Working Party – Guidelines on Data Protection Impact Assessment (WP248 rev.01)
- Law 300/1970 (Statuto dei Lavoratori), Article 4 – Normattiva
- Garante Privacy – Guidelines on email and internet in the workplace (1 March 2007)
- Garante Privacy – Guidance document on email software and metadata (6 June 2024)
- NIST TN 2276 – NIST Phish Scale User Guide
