How to Run a Phishing Simulation for Your Team Without Panic or Blame

How to Run a Phishing Simulation for Your Team Without Panic or Blame

A phishing simulation is a rehearsal, not a trap. Fire drills don't exist to embarrass the people who file out slowly, and a fake invoice in someone's inbox shouldn't exist to catch them out either. Simulations still go wrong all the time — not because the fake email was too clever, but because nobody agreed on the rules, the metrics or the follow-up before the first message landed. Get those three things right and a click becomes a data point instead of a small humiliation.

Start With Permissions, Scope and a Stated Goal

Before you design anything, settle the boring parts. Get written approval from leadership, talk to HR, and check employment law and any works council or union agreements that apply where your team works. Rules on monitoring and simulated attacks vary by country and sector, so involve people who are qualified to advise on it rather than assuming a simulation is always fine. If your organization operates in multiple countries, treat the strictest applicable rule as your floor, not your ceiling.

Then decide what you're testing. "See who clicks" is not a goal. Pick one or two: reduce clicks on credential-harvesting lures, raise the share of suspicious mail reported through the button in your mail client, or confirm that a new gateway quarantines a known-bad attachment. Each of those calls for a different test. If the goal is reporting, for example, you might use a lure that is suspicious but not humiliating, and you might measure how quickly people hit the report button rather than whether they clicked at all.

Tell the company the programme exists. You're announcing the simulation programme, not the individual messages. Secrecy about the campaign breeds resentment; secrecy about the specific email is what makes it meaningful. A short intranet post, a line in the monthly all-hands, and a note in the security channel are enough: "We run phishing simulations a few times a year. They help us improve our filters, our training and our reporting process. You will never be punished for clicking. You will always get feedback."

Design a Pretext Your Team Would Genuinely Encounter

The best simulations are boring. They look like the mail your colleagues already receive on a Tuesday morning, with the same tone and signature block. If your fake email looks like a Hollywood hack — urgent red banner, misspelled sender, "CLICK HERE NOW" — people will spot it and learn nothing about their real risk.

Borrow from real incidents

Ask the service desk what people report, and look at what slipped through in the past six months — the spoofed freight notice, the "shared document" from a name that was almost right, the fake password-expiry message that arrived during an actual password-expiry cycle. Reuse those shapes, and update them as your tools change. If your finance team keeps getting fake invoices from a supplier with a slightly different domain, that is your next simulation, not a generic "Your account has been limited."

Climb a difficulty ladder

Start with an obvious sender mismatch, a generic greeting, a link nobody needs. Move up once most people catch level one: a plausible internal sender, a timely hook such as a benefits enrolment window. Save the near-perfect imitation for when the first two are consistently spotted. Starting at level three teaches people they cannot win, and a team that believes it cannot win stops trying.

Leave personal fear alone

Fake layoffs, disciplinary notices, salary changes, news about a family member. People don't forget those, and the trust you spend costs more than the click data is worth. Keep the simulation in the professional domain. A fake "HR: Your leave request was denied" email might get clicks, but it also tells your team that security will use their anxieties as bait.

On the landing page, never collect real passwords. One page that says the message was a test, names two or three clues, and offers a short refresher is enough. If you want to measure whether someone would enter credentials, measure the click on the link and the time to report; do not build a working credential harvester just to prove a point.

Write the Rules of Engagement Down

Publish these before the first send, so nobody is negotiating them afterwards:

No individual is named outside the security team and their manager.
The report button works, and every report gets a reply.
Data collected stays aggregated. Individual results are used only for one-to-one coaching, never for performance reviews, discipline or promotion decisions.
No simulated email asks for real passwords, MFA codes, payment details or personal data.
There is a pause switch. If a real incident happens — a genuine breach, a ransomware scare, a company-wide crisis — the simulation stops immediately.
Leadership sees trends, not names. If a manager asks for a list of clickers, the answer is no, and the reason is that fear destroys reporting.

These rules are not fine print. Read them out in a team meeting, put them in the security awareness page, and repeat them in the debrief. The moment people suspect the simulation is a secret test of their competence, they stop reporting real phish to protect themselves.

“The goal is not zero clicks. The goal is a team that reports suspicious mail quickly, learns from the ones that get through, and knows that asking for help is safe.”

Make Reporting the Hero Metric

Clicks are easy to count, which is why they dominate the conversation. But a click without a report is the dangerous outcome, and a report without a click is a win. If twenty percent of people click a lure but sixty percent report it within ten minutes, your security team can reset credentials, block the sender and warn the company before most damage is done. If one percent click and nobody reports, you have a quiet problem.

Make reporting frictionless. Put the report button where people already work, test it on mobile, and make sure it does not require a category, a comment and a ticket number. When someone reports a simulated phish, reply with a short thank-you and a note about what to look for next time. Celebrate the first reporter, not the last clicker. Over time, track report rate, click rate, time to report and repeat click rate. Those four numbers tell a better story than a single "gotcha" percentage.