Phishing Simulation Programs: Design, Metrics, and What Not to Do

A phishing simulation sends controlled, harmless lookalike messages to your own staff and measures what happens. Gophish is the common open-source platform for running them, but the platform is the easy part. Program design is what determines whether a simulation improves security or quietly damages the relationship between the security team and everyone else.

How a simulation works

The mechanics are the same as real phishing, minus the payload. You define a target group, compose a message, host a landing page on a domain you control, and send. Each recipient gets a uniquely tracked link, so the platform can record who opened the message, who clicked, who submitted data on the landing page, and who reported it.

The landing page is where the training happens. Rather than a fake login that harvests credentials, a well-built simulation lands the user on a short page explaining what just happened and pointing out the specific cues in the message they missed.

Delivery requires preparation. Simulation mail must be allowed past your own filters or the test measures your gateway instead of your people, and the sending infrastructure needs correct SPF, DKIM, and DMARC records so mail is not silently dropped. Setting that up is itself a useful exercise in how email authentication works.

Authorization comes first

This is the part that is not negotiable. A simulation sends deceptive messages to employees and collects data about their behavior, so it requires documented approval before anything is sent. Executive sign-off, HR and legal review, and a defined scope covering who is targeted and how results will be used.

Running an unauthorized simulation — even with good intentions, even by the security team — is a career-ending move in many organizations and potentially a legal problem. Employee monitoring and data protection law applies to the results, and in some jurisdictions works councils have to be consulted. Get it in writing.

Metrics that mean something

The click rate is the number everyone quotes and the least useful one in isolation, because it moves with how difficult the message was. A sophisticated lure will always out-click a clumsy one, so comparing this month's rate to last month's tells you nothing unless difficulty was held constant.

The report rate is the metric that matters. A user who clicks and then reports gives the response team a head start; a user who clicks and says nothing leaves the organization blind. Treat reporting as the behavior you are training, and measure whether it is rising. Track the median time to first report as well — speed determines whether containment beats the attacker.

Credential submission rate is worth separating from click rate, since entering a password is a materially worse outcome than opening a page. Repeat-clicker analysis identifies the small group who need targeted help rather than another company-wide module. And where reported messages feed into your SOAR workflow, you can measure the whole detection-to-containment path, not just the human step.

Design mistakes to avoid

Do not punish clickers. Programs that name, shame, or discipline people who click reliably produce one outcome: users stop reporting, because reporting means admitting they clicked. You have then traded a measurable click rate for an invisible one.

Do not use cruel lures. Fake bonus announcements, fake layoff notices, and fake benefits changes generate spectacular click rates and lasting resentment. The simulation is supposed to build the instinct to report, and a lure that feels like a betrayal teaches people the security team cannot be trusted.

Do not impersonate real colleagues by name, and do not clone real internal systems so faithfully that users cannot tell simulation from reality afterward. Vary difficulty deliberately and record it with each campaign so your trend line means something. And cover channels beyond email — voice and SMS pretexts are common in real incidents and rarely simulated.

Exam angles

Know that phishing simulation is a form of security awareness training and a detective-and-corrective control on the human layer. Recognize that written authorization is required before running one. Understand that the reporting rate, not the click rate, is the indicator of a maturing program, and that punitive handling suppresses reporting. Expect scenario questions where the correct answer is training and reporting process rather than an additional technical control, because the message reached a user whose judgment is the last line — the same reasoning behind teaching users to spot obfuscated links.