Phishing Drill

Practice

A rehearsal in which a company sends convincing fake phishing email to its own staff and measures who falls for it and who reports it.

Why it exists

For a long time a company had two levers on security: write the rules down, and get people to read them. The second one is security training, and what it actually confirms is attendance. Someone sat through the session.

So the same sequence kept playing out. Everyone completes a one-hour course in December and the security lead reports 100 percent completion. Two months later an email dressed up as a tax invoice arrives, someone in finance opens the attachment without checking it, and the shared drive encrypts itself. Slide three of the course material said not to open attachments you did not expect.

The failure was never a knowledge gap. People know the rule and still miss it, because the twenty seconds spent skimming an inbox against a deadline is not a moment when knowledge gets retrieved. Behavior follows habit rather than instruction, and habits only form by going through the thing.

A phishing drill manufactures that experience in a safe form. If training checks what people know, a drill checks what they do. A security policy states what should happen; the drill produces evidence about whether it does.

How it runs

Build a scenario, clear a sending path so the mail is not eaten by the spam filter, send it on a chosen day, count the reactions in four stages, and debrief immediately.

  1. Set the scope and the question. Unless there is a reason to narrow it, the audience is everyone. Write down in one sentence what this round is meant to reveal; reactions to payment mail and the reporting habit lead to different scenarios.
  2. Build the scenario. Common material: a document-sharing notification from the company's own collaboration tool, an HR announcement, a failed parcel delivery, a tax invoice. Set the difficulty at the same time. A sender address off by one character is easy; a pixel-accurate copy of the internal tool's login page is hard.
  3. Prepare the sending path. Register a dedicated drill domain and add exceptions in the mail server and the spam filter. Skip it and every message lands in the junk folder and the round produces no numbers.
  4. Send. Spread delivery over several hours instead of firing everything at once. When the whole company gets it in the same minute, someone says "what is this email?" out loud and the reactions contaminate each other.
  5. Count. There are four values: the share who opened the mail, the share who clicked the link, the share who typed credentials into the fake login page, and the share who reported it. Send to 45 people and get 32 opens, 8 clicks, 2 credential entries and 11 reports: an 18 percent click rate and a 24 percent report rate.
  6. Debrief on the spot. Anyone who clicks lands on a page that says this was a drill and points out the signals they could have caught.
  7. Publish the result and book the next round. Share the company-wide figure and department-level figures, and stop there.

A first round usually lands between 15 and 25 percent clicks. Over successive rounds the targets to aim for are a click rate under 5 percent and a report rate above 30 percent.

Who joins and when

Whoever owns security runs the drill, and because it means sending fake mail to the whole company, leadership signs off before anything goes out.

Deciding who is told in advance and who must not be comes next.

  1. The people who field questions are told. If whoever staffs the internal help channel is in the dark, dozens of identical reports at once look like a live incident and the response procedure fires for nothing.
  2. Managers are usually left out. A manager who knows tends to tip off the team, and then one department's numbers come in artificially low.

On cadence, once a quarter is common, and a small company can run a useful drill every six months. New hires join from the first round a month after they start; in week one they have no basis for telling an internal notification from a fake one.

Some weeks are wrong for it. Quarter-end close, an active service outage, and the days right after a real breach are all bad timing. After a real incident everyone is already on alert, so the numbers do not represent an ordinary week. The opposite pull comes from audits: when a team is preparing for security compliance review, drill records are usually a required artifact, which tends to move the schedule earlier.

How it sounds at work

"Click rate came in at 18 percent this round. It's up from last time, but the scenario was harder, so the two aren't directly comparable."

Attaching the condition that changed before anyone reads the number as a regression.

"We're not sharing who clicked. Department-level figures only."

Drawing the line in advance against using drill results in performance reviews.

"A 24 percent report rate means the other 76 percent just deleted it. That's the bigger problem."

Not falling for it and raising the alarm are two different behaviors.

Pagedeck's first drill was run by Grace shortly after the Series A. The mail was styled as a document-sharing notification from the team's own collaboration tool and went to 45 people, with a sender address one character off. Sofia clicked, thinking it was a contract a customer had sent her, and Theo reported it to the help channel within three minutes.

What the debrief spent most of its time on was not the click rate but time to first report. Ten of the eleven people who reported did so inside ten minutes, and at that speed a warning would reach everyone else even if the mail had been real. Grace set the next round's target on that number instead of on clicks.

What people get wrong

The most common misreading treats the drill as a test that identifies who gets fooled. Results are recorded per person, so the shape invites it. What it measures is an organizational rate; names are used to send the debrief and not kept. Publish the names or feed them into reviews and the habit people acquire first is concealment rather than caution. Reporting dries up, and on the day a real message arrives the company gets no signal at all.

Treating a zero percent click rate as the goal is the other frequent mistake, and it looks reasonable: lower seems safer. But click rate is entirely controllable through scenario difficulty — send mail from an obviously wrong address and the number comes out near zero. Once that figure is being reported as an achievement, the drills get easier every round, and nothing has been rehearsed for the day a well-built message actually arrives. So difficulty rises along with the rounds, and the report rate is read next to the click rate. An incident response plan only starts if somebody raises the alarm first, and the number that produces that person is the report rate, not the click rate.

Where to go next

Last updated 2026-09-16