A phishing simulation is a controlled phishing campaign run against your own staff to measure — and improve — how your organisation responds to real attacks. Done well, it builds a culture where people report suspicious emails quickly and without fear. Done badly, it embarrasses staff, erodes trust in the security team, and teaches people to hide their mistakes.
We run social engineering engagements for organisations of all sizes, and the difference between a simulation that changes behaviour and one that generates resentment almost always comes down to five things: goals, targeting, lure design, metrics, and the debrief.
Start With a Goal That Isn't 'Catch People'
If the goal of your simulation is to maximise the number of clicks, you will succeed — and learn nothing. Anyone can be phished with the right lure on the wrong day. That includes security professionals.
Useful goals look like:
- Measure how quickly the first report reaches the security team
- Test whether the reporting mechanism (button, mailbox, chat channel) actually works under load
- Confirm what happens after a report — does anyone triage it, and how fast?
- Establish a baseline so you can track reporting behaviour over time
Click rate is an input, not the objective. Reporting rate and response speed are what limit damage in a real incident, so they are what you should be optimising.
Decide Who You're Targeting and Why
Blasting the whole company with an identical email is easy but crude. Real attackers segment, and so should you:
- Whole-of-organisation waves establish baselines and normalise the programme.
- Role-based campaigns target finance with invoice fraud themes, engineering with fake CI or repo notifications, and executive assistants with calendar and travel pretexts.
- New starters are worth a gentle early campaign — they are heavily targeted in the wild because they don't yet know what 'normal' looks like internally.
Never design a campaign to single out one individual. That's not a simulation, it's an ambush, and it will poison the programme. Executives should be included in scope — excluding them sends exactly the wrong message — but their results deserve the same confidentiality as everyone else's.
Design Lures Ethically
The pretext is where most programmes go wrong. A lure should be plausible and representative of real attacks — not cruel. Avoid:
- Fake bonuses, pay rises, or gift cards
- Redundancy, restructure, or performance-review themes
- Health, family, or emergency pretexts
These get high click rates precisely because they weaponise hope or fear, and the backlash when staff realise it was their own employer is severe. Real attackers use them, but your simulation doesn't need to replicate every real tactic to be useful — the mechanics of verifying a sender, hovering a link, and reporting are the same with a mundane pretext.
Good lures mirror your actual email traffic: document-share notifications, MFA re-enrolment prompts, parcel notifications, meeting invitations. Get sign-off on every pretext from HR and legal before launch, and make sure the security team and help desk know the campaign is running so reports are handled properly.
Tell staff a simulation programme exists. You don't announce individual campaigns — that defeats the point — but an organisation that knows it will occasionally be tested treats every odd email as potentially a test, which is exactly the reflex you want.
Measure What Actually Matters
Click rate alone is close to meaningless — it varies wildly with lure difficulty. Track instead:
- Report rate: what percentage of recipients reported the email
- Time to first report: your realistic detection window for a real campaign
- Report-before-click ratio: did reports arrive before or after the first click?
- Credential submission rate: clicking a link is recoverable; typing a password is a different severity
- Trend over time: the same cohort across quarters, not one-off snapshots
Repeat clickers are a coaching signal, not a disciplinary one. If the same lure keeps working, the fix is usually a technical control — better mail filtering, phishing-resistant MFA, link rewriting — not more punishment.
The Debrief Is the Product
Everything before the debrief is data collection. The value is delivered afterwards:
- Anyone who clicked should land on a short, blame-free teaching page immediately — that moment is the most effective training you will ever deliver.
- Report aggregate results to leadership. Never publish names.
- Close the loop with people who reported: thank them. A one-line acknowledgement does more for reporting culture than any poster campaign.
- Turn findings into process fixes. If the lure spoofed your MD's display name, that's a mail-gateway rule. If credentials were submitted, that's an argument for phishing-resistant MFA.
Attackers also target your phones — vishing and smishing campaigns pair naturally with email simulations, and reconnaissance of your organisation's public footprint (see our OSINT and reconnaissance work) will show you exactly what an attacker would use to build convincing pretexts.
FAQ
How often should we run phishing simulations?
Quarterly is a sensible cadence for most organisations — frequent enough to trend results, infrequent enough that campaigns stay novel. Vary the lures, timing and targeting each round.
Should we tell staff a simulation is coming?
Announce that a programme exists; never announce specific campaigns. Awareness of the programme improves vigilance without invalidating the data.
What is a good phishing report rate?
There's no universal benchmark because lure difficulty varies, but the trend matters more than the number: report rate rising and time-to-first-report falling across campaigns means the programme is working.
If you want a phishing simulation designed and run by people who do offensive security for a living — with lures grounded in real attacker tradecraft and a debrief your staff won't resent — talk to us. We'll scope it in a free call and have a fixed quote to you within one business day.
Need cybersecurity expertise?
Drop your email and we'll be in touch within one business day.