Phishing Simulations Done Right: Measuring Human Risk

4:55 on a Friday. A finance clerk at a company we will call acme-corp opens an email from the “CFO”. Wire the vendor now, the invoice is already overdue, I am stuck in a meeting so do not call me. Her cursor was on the approve button.

She stopped. Not because a filter flagged it, and not because she is smarter than the rest of the department. Two weeks earlier she had clicked a phishing simulation that ran the exact same play: urgency stacked on authority, a reason you cannot verify by voice. The lesson stuck. She forwarded the real thing to the phishing button instead.

That is the entire game. A phishing simulation is not about catching people out. It is about measuring how your workforce behaves under a believable lure, then shrinking the distance between the people who click and the people who report. Run it as a blame machine and you teach staff to hide their mistakes. Run it well and you walk away with a defensible number for human risk and a trend line you can actually move.

Key takeaways

• A phishing simulation measures human risk under a realistic lure. It is a diagnostic, not a gotcha exercise or a punishment tool.
• Report rate matters more than click rate. A workforce that reports fast contains an attack faster than one that merely clicks less.
• Run it ethically: written executive sign-off, a briefed HR and SOC, no real passwords ever stored, and no naming individuals.
• Attach short, in-the-moment training to every campaign. The teachable second is right after the click, not in a quarterly slide deck.
• Track click rate, submit rate, report rate, dwell time to first report, and repeat clickers across rounds. One campaign is a snapshot; the value lives in the trend.

What a phishing simulation actually is

A phishing simulation is a controlled exercise where your security team, or a firm like ours, sends benign but realistic phishing emails to your own staff, records who interacts, and turns the result into training and process fixes. The emails look real. The payload does not exist. Nobody’s laptop gets compromised, and no live credential is ever captured.

It maps cleanly onto how attackers get in. Phishing sits under MITRE ATT&CK technique T1566, with sub-techniques for spearphishing links (T1566.002) and attachments (T1566.001). Credential harvesting through a fake login page is the variant we model most, because it is cheap to run and it works. Business email compromise, the wire-fraud scenario above, is the expensive cousin, and it is worth simulating for finance and executive-assistant roles specifically.

Here is the uncomfortable part. Your technical controls can be excellent and one convincing email to one distracted person still walks straight past them. People are not the weakest link because they are careless. They are the target because they are reachable, and because a good pretext hijacks instincts we actually want employees to have: be helpful, be fast, do not make the boss wait.

How do you run a phishing simulation ethically?

Get written authorization before a single email leaves the outbox. In our engagements the campaign does not fire until we have executive sign-off, an agreed target list, and a blackout window that rules out live incidents, earnings days, and anything resembling a company tragedy. Social engineering is the one test type where the subject is a person, not a server. The ethics are load-bearing.

A few lines we do not cross:

• Brief the right people, not everyone. HR, legal, and the SOC lead need advance notice. The general population must not, or you are measuring theater instead of behavior.
• Never keep a real credential. If the landing page has a password field, the submitted value hits the floor. We log that a submit happened, never what was typed. There is no defensible reason to hold a live password.
• No public shaming. Reporting stays aggregated. “Finance report rate was 40 percent” is fine. Naming Dave from Finance in a company channel is how you kill the program in one campaign.
• Calibrate the cruelty. Fake bonus letters, fake layoff notices, and fake charity appeals after a real disaster all pull huge click rates and torch trust just as fast. We skip emotionally abusive pretexts. We are after behavior change, not an HR complaint.

How we build and send the campaign

The workflow mirrors the attacker’s, minus the harm. Recon comes first. What does your real mail actually look like? We study the tone of internal comms, the SaaS you genuinely use (Microsoft 365, Okta, whatever HR portal you live in), and the domains you send from. A convincing lure impersonates something the target sees every week, not a generic “IT Department” that nobody recognizes.

Then the infrastructure. Open-source GoPhish covers sending, tracking, and landing-page capture for most awareness-grade work. For a look-alike domain we register something plausible, say acme-corp-hr.com or a near-homoglyph of the real thing, warm it, and set SPF, DKIM, and DMARC so it reaches the inbox instead of the junk folder. Before we ever send, one of the first things we run is a check on the target’s own posture:

$ dig +short TXT _dmarc.acme-corp.com
"v=DMARC1; p=none; rua=mailto:[email protected]"

A policy of p=none means the domain is monitoring but not rejecting spoofed mail, which tells you plenty before the campaign even starts. If your own gateway quarantines the test, you learned something real about the gateway and nothing at all about the humans, so tuning deliverability is part of the job.

The tracking flow itself is simple. Each link carries a per-recipient token, so every event ties back to one person with no guessing:

GET /login?rid=7f3a9c2e HTTP/1.1
Host: acme-corp-hr.com
User-Agent: Mozilla/5.0 ...

-- click logged for rid=7f3a9c2e
-- page renders a fake Okta login
-- if the user submits:
POST /login  { username, password }
-- submit logged, credentials discarded, redirect to training

Anyone who submits lands on a short debrief the moment they hit enter. Here is the email you got. Here are the three tells you could have caught. Here is the report button. That page beats any annual training module, for one reason: the lesson arrives while the mistake is still warm.

For higher-maturity clients we go past email. Vishing (a phone pretext) and smishing (SMS) fill out the picture, and a QR-code lure tests whether “quishing” sidesteps your email defenses entirely. Attackers do not confine themselves to one channel, so mature testing should not either.

Which phishing metrics actually matter?

Click rate is the number every stakeholder asks for and the one I trust least on its own. It is trivial to game. Send a lazy, obvious lure and your click rate looks brilliant. The numbers that tell you something:

• Report rate. What share of recipients hit the report button? This is the single best predictor of how fast a real attack gets contained. A team that clicks 15 percent but reports 60 percent is in far better shape than one that clicks 8 percent and reports nothing.
• Submit rate. Of those who clicked, how many typed credentials? The click is a stumble. The submit is the compromise.
• Dwell time to first report. Minutes from send to your first user report. Fast reporting lets the SOC pull the malicious mail from every inbox before more people bite.
• Repeat clickers. The small slice who click campaign after campaign are your concentrated risk. They need targeted coaching, not another blast email.

One campaign gives you a snapshot. Four across a year, segmented by department, gives you a trend, and the trend is the deliverable. It is what a board actually wants to see and what an auditor accepts as evidence that an awareness control is operating rather than existing on paper.

How do you actually reduce the risk?

Testing without follow-through is just annoying people on a schedule. The reduction comes from two places: fast, specific training tied to each simulation, and fixing the process gaps the exercise drags into the light.

Make reporting the easy default and reward it. A one-click report button in Outlook or Gmail, answered with a plain “thanks, we are looking into it”, beats a punitive culture every single time. On the technical side, the same campaign almost always surfaces gaps worth fixing no matter how the humans did: DMARC still on p=none, no external-sender banner, MFA that accepts phishable SMS codes, no mail-flow rule to yank a reported phish from every mailbox at once. Push high-value accounts toward phishing-resistant MFA such as FIDO2 or passkeys, because that removes the credential-harvest payoff entirely. No password to steal, no fake login page worth building.

Be honest in the debrief too. Wording your way out of a bad result (“engagement was low due to timing”) helps nobody. If half of finance handed credentials to a wire-fraud lure, that is the finding. Write it down. It is fixable, and pretending otherwise just guarantees you find out the same thing from a real attacker next quarter.

How CyberXplore helps

Our social engineering and phishing simulation service runs the whole program end to end: realistic multi-channel lures across email, voice, SMS, and QR, safe credential handling that never stores a real password, per-department metrics, and in-the-moment training that fires the second someone clicks. We build pretexts around your real tools and tone, brief your SOC so the exercise doubles as detection-and-response practice, and hand you a trend line you can take to the board or an auditor. Want to know your true report rate before an attacker measures it for you? Get a quote and we will scope a campaign to your headcount and risk profile.

FAQ

How often should we run a phishing simulation?

Quarterly is the sweet spot for most organizations. Monthly tends to breed fatigue and desensitization, while annual campaigns are too rare to build a habit or show a trend. Vary the pretext and difficulty each round so people cannot simply pattern-match on “it must be the quarterly test.”

Should employees who fail be punished?

No. Punishment teaches people to hide mistakes and distrust the security team, which is the opposite of what you want. Focus on coaching, easy reporting, and supporting the small group of repeat clickers. Reserve formal HR action for genuine policy violations, never for clicking a well-crafted test.

What is a good click rate for a phishing simulation?

There is no universal magic number, and chasing a low one is misleading. A well-crafted, targeted lure will always beat a lazy one, so rising difficulty with a stable or falling click rate is the real win. Watch report rate and repeat clickers over time instead of obsessing over a single click percentage.

Is a phishing simulation legal and safe for our staff?

Yes, when it is authorized and handled ethically. You are testing your own employees on your own systems with executive sign-off, so it is legal. Safety comes from never storing real credentials, avoiding abusive pretexts, briefing HR and the SOC, and keeping all reporting aggregated rather than naming individuals.

How is a phishing simulation different from a red team engagement?

A phishing simulation is a focused, measurable exercise aimed at workforce behavior and awareness metrics across many recipients. A red team engagement may use phishing as one entry point, but then pursues a broader objective, such as reaching sensitive data or domain admin, to test detection and response across the whole environment. They complement each other: the simulation builds the human baseline that a red team later stress-tests.