Almost every organization runs some form of phishing simulation. Far fewer can say whether it has made them safer. The usual program sends a fake email each quarter, counts how many people clicked, assigns training to the ones who did, and reports a percentage that goes up or down for reasons nobody can fully explain.
That is a compliance activity. A human risk program is something different: a continuous effort to reduce the odds that a real phishing attempt becomes a real incident, and to shorten the time between a person spotting something suspicious and the security team acting on it.
This guide covers what separates the two.
What phishing simulation is, and what it isn’t
A phishing simulation is a controlled, authorized test in which employees receive realistic lures, and their responses are measured. Done well, it shows how people behave under realistic conditions, builds the habit of reporting suspicious messages, and gives the security team evidence of where risk concentrates.
It is not a way to catch people out. Programs built around blame tend to teach employees to hide mistakes, which is the opposite of what a security team needs. The programs that work treat a click as a learning moment and a report as a win.
Why click rate is the wrong headline number
Click rate is easy to measure, so it became the default. It has two problems.
First, it rewards easy lures. A program can lower its click rate simply by sending less convincing emails, which says nothing about real-world resilience.
Second, it measures failure and ignores the behavior that actually protects an organization. An employee who clicks but reports the email within a minute may have contained the risk. An employee who never clicks but never reports leaves the security team blind.
The metrics that matter
A mature program tracks a set of measures that together describe behavior, speed, and concentration of risk.
- Report rate. The share of recipients who report the message as suspicious. This is the clearest indicator of a healthy security culture.
- Time to report. How quickly reports arrive. Speed matters because a lure reported in minutes can be removed from other inboxes before more people interact with it.
- Time to click versus time to report. Comparing the two shows whether people are reporting faster than attackers can exploit a click.
- Phish-prone percentage. The share of users who interact with a lure in a way an attacker could exploit.
- Repeat offenders. A small number of users often account for a disproportionate share of risk. Knowing who they are, and why, lets a program support them directly instead of retraining everyone.
- Resilience trend. Movement over time across departments, channels, and lure types, which is what a board actually wants to see.
Move beyond email
Attackers have. Phishing now arrives through several channels, and a simulation program limited to email only tests part of the problem.
- QR codes. Often called quishing, these shift the attack to a personal phone, outside many email controls.
- SMS. Text-based lures exploit the trust people place in messages on their own devices.
- Voice. Phone-based social engineering remains effective, particularly against help desks and finance teams.
- Collaboration tools. Messages in workplace chat platforms carry implicit trust that email does not.
- Adversary-in-the-middle (AiTM). These attacks capture session tokens in real time, which means multi-factor authentication alone does not stop them. Testing and training for this scenario safely, without ever storing a real credential, is increasingly important.
Each channel should be enabled deliberately, with consent and safety controls in place, rather than switched on all at once.
Training that responds to behavior
Annual, one-size-fits-all training has a poor track record. A better pattern is just-in-time and adaptive: when a user is caught by a simulation, they receive a short, relevant lesson at that moment, and the content reflects the type of lure that caught them. Completion is tracked per person, and the program focuses further effort where behavior has not changed.
Connect the program to the SOC
This is where most programs stop short, and where the largest gain sits.
In a typical setup, the awareness platform and the SOC are separate systems. A reported email lands in a mailbox somebody checks when time allows. Simulation results never influence how the security team prioritizes anything. And if a simulation or a real campaign reveals a compromised account, disabling it is a manual scramble across consoles.
A connected program closes those gaps in three ways.
- A reported phish becomes a case. A genuine report opens a real investigation in the SOC queue. A recognized simulation credits the reporter instead, and teaches rather than blames.
- Containment is available from the same view. When a user is compromised, an authorized analyst can disable the account and revoke active sessions without switching tools. Because this is a consequential action, it should always be analyst-approved, introduced in a dry-run mode first, and refuse to act on privileged or protected accounts.
- Human risk informs exposure. Repeat clickers represent real exposure. Feeding that signal into exposure management means a person’s risk can raise the priority of the assets they use. For more on how exposure programs prioritize, see our guide to continuous threat exposure management.
Keep it safe, consented, and private
A simulation program touches real people and real systems, so guardrails are not optional.
- Consent and authorization recorded before any campaign runs.
- Verified sending domains and suppression lists so tests reach only intended recipients.
- Per-tenant caps and isolation for providers running programs across multiple clients.
- Data residency. If AI is used to write lure content, where that model runs matters. Keeping generation inside the environment, rather than sending simulation content and user data to an external model, is important for organizations under data-protection mandates such as DPDP or GDPR.
- A full audit trail of every send, report, and response action, which also serves as compliance evidence. For help aligning awareness programs with governance and compliance requirements, see our practices.
Common mistakes
- Optimizing for a low click rate instead of a high report rate.
- Running email-only simulations while attackers use QR codes, SMS, voice, and session-theft techniques.
- Naming and shaming individuals, which discourages reporting.
- Keeping the program separate from the SOC, so reports and results never change how security operates.
- Reporting only to compliance, instead of using the data to direct support and prioritize risk.
- Treating MFA as a complete answer to credential theft, when AiTM techniques can bypass it.
Where Rainier PhishSim fits
Rainier PhishSim is built around the connected model described above. It runs as a module inside the Rainier agentic SOC platform, so a reported phish opens a case, human-risk signals feed exposure management, and containment actions sit alongside the rest of SOC operations. Lure generation runs on an on-premises model, simulations span multiple channels including QR, SMS, voice, collaboration tools, and AiTM, and the platform is built for providers managing many clients with per-tenant isolation.
Want a phishing simulation program that connects to your SOC instead of sitting beside it? Talk to Network Intelligence.
