Running a phishing simulation without punishing staff

Phishing simulations have a poor reputation among the people they are run on, and often deservedly so. Done badly, they function as a trap: an unusually cruel lure, a public list of who clicked, and a mandatory training module as punishment. The measurable result is that staff stop trusting internal email and stop reporting anything, which leaves the organisation worse off than before the programme started.

Done well, the same exercise is one of the highest-value security activities a small company can run. The difference is entirely in the design.

Measure reporting, not clicking

Click rate is the metric everyone starts with and the wrong one to optimise. It is heavily influenced by how hard the lure was, so it can be driven to any number you like by adjusting difficulty — which makes it useless for tracking progress and tempting to manipulate.

The metric that predicts real-world outcomes is the report rate: what proportion of recipients actively flagged the message, and how quickly. In a genuine attack, one person reporting within five minutes gives your responders a chance to pull the message from every other inbox before it is opened. Nobody clicking but nobody reporting is a far worse position than a few clicks and a fast report.

Track the time to first report as your headline number. Watch it fall over successive rounds. That is the capability you are building.

Make reporting effortless

If reporting a suspicious email takes more than one action, most people will not do it, and the ones who do will stop when they are busy. A dedicated button in the mail client, or at worst a single well-known address, is the minimum. Whatever the mechanism, it must acknowledge receipt immediately, and a human must respond to reports — even the wrong ones — within the same day.

Thank people who report legitimate mail by mistake. That is the behaviour you want. Correcting them politely and quickly costs a minute and protects the instinct.

Tell people the programme exists

There is a persistent belief that announcing a simulation programme invalidates the results. It does not. You are not measuring whether people can be surprised; you are measuring whether they know what to do. Announce that simulations will happen periodically, explain why, and state plainly that no individual results will be used in performance reviews or shared with managers.

Get that commitment in writing before the first campaign and keep it. In the EU, this is not only good practice: running covert testing on identifiable employees engages the GDPR and, in most cases, works council or employee representative consultation. Handle the paperwork first.

Coach at the moment it matters

Someone who clicks should land on a short page that explains what the message was, which three signals would have given it away, and how to report the next one. Sixty seconds of specific, relevant explanation at the moment of the mistake beats a forty-minute annual module by a wide margin.

No names to managers. No leaderboards. Aggregate results by department if you need to target follow-up, but never individually. The moment staff believe the exercise is about catching them, the reporting rate you are trying to build collapses.

Use lures that resemble your real threats

Fake bonus announcements and disciplinary notices produce high click rates and lasting resentment, and they teach nothing, because no real attacker has your HR letterhead. Model the campaign on what actually reaches your organisation: a shared-document notification, a supplier invoice with changed bank details, a fake login prompt for the SaaS tool your team uses daily, a delivery notice during a busy period.

Escalate difficulty gradually across rounds. Starting at the hardest level teaches helplessness; starting easy and building teaches pattern recognition.

Close the loop on the technical side

A simulation that only produces a human metric is half-finished. Every campaign is also a live test of your controls. Did the message pass SPF, DKIM and DMARC checks it should have failed? Did the credential-harvesting page load, or did filtering block it? When a user submitted credentials, did anything detect the login from an unusual location?

Fixing one of those is usually worth more than another round of training, because it protects the people who will click no matter how well trained they are — and under sufficient pressure, that is everyone.

A programme that raises reporting from twenty per cent to sixty per cent has materially improved your incident response. A programme that lowers click rate while making staff afraid to report has made things worse. Measure the first.