A phishing simulation program maturity model gives security teams a way to assess whether testing is building safer decisions or simply generating activity. The useful question is not how many messages you sent. It is whether your program can identify relevant risk, respond proportionately, learn from results, and improve the work practices that shape behavior.
Discuss your human risk management goals
In brief: assess a program across purpose, targeting, experience, response, measurement, and governance. A mature program uses simulation as one source of evidence about behavior—not as a test of individual worth or a substitute for examining the systems and processes around people. The model below is a practical planning tool, not a universal certification or a claim that every organization must follow the same sequence.
Phishing simulations can help teams understand how employees recognize and report suspicious messages. But a click rate alone cannot tell you why a person acted, whether the message resembled a real work request, or whether reporting channels were easy to use. It also says little about changes in behavior unless you compare it with context and follow-up evidence.
That is why maturity involves more than increasing campaign frequency. Teams need a clear purpose, defensible measurement, safeguards for participants, and a process for turning findings into useful changes. To see how this fits into the broader discipline, start with what human risk management means.
The stages below describe common program capabilities. They are not a scorecard for judging employees or a fixed timetable. An organization might have strong governance but limited reporting data, for example. Use each stage to identify the next sensible improvement, rather than to force every part of the program into one label.
| Stage | Typical approach | Evidence to look for | Next improvement |
|---|---|---|---|
| 1. Ad hoc | Occasional tests with unclear objectives or inconsistent follow-up. | Campaign records exist, but definitions, audience selection, and outcomes vary. | Set a purpose, baseline, owner, and basic participant safeguards. |
| 2. Repeatable | Planned campaigns use consistent procedures and reporting paths. | Teams track delivery, interaction, and reporting with agreed definitions. | Segment thoughtfully and connect findings to relevant learning or process fixes. |
| 3. Contextual | Scenarios and interventions reflect role, current threats, and work context. | Results are reviewed alongside access, identity, threat, and workflow context. | Check whether interventions change behavior and reduce exposure over time. |
| 4. Adaptive | Evidence informs ongoing, proportionate prevention and program redesign. | Teams review trends, fairness, privacy, and operational outcomes together. | Keep validating assumptions and improve the program as work and threats change. |
The table is a conversation starter, not an excuse to rank teams against an invented industry benchmark. Document what each capability means in your environment. For a useful external perspective on how benchmarking can go wrong, the SANS guidance on phishing awareness benchmarking discusses variables that affect benchmark validity and introduces its maturity and tiering models. Compare like with like before interpreting a rate as progress.
Moving forward does not always mean adding more simulations. A team may first need reliable reporting channels, a consistent response process, or a better understanding of which work conditions create risky shortcuts. A clear security awareness program remit can help keep those priorities connected.
Choose measures that connect to the program’s purpose, and write down how each one is calculated. Use several indicators together. A single outcome can be distorted by message difficulty, audience size, delivery conditions, or changes in how reports are handled.
Keep operational metrics distinct from risk outcomes. Completion counts tell you that an activity occurred. They do not establish that a person can recognize a threat, that an organization has reduced exposure, or that an incident was prevented. When leaders ask for a single figure, explain what it represents and what it cannot establish.
Where possible, review simulation outcomes alongside other relevant signals. Identity and access conditions, threat information, and the way work is designed may explain why a particular behavior is likely. Security tool integrations can be part of a broader view, but additional data is useful only when it has a defined purpose, appropriate access controls, and a plan for acting on it.
A result is meaningful only when its collection conditions are understood. A campaign sent to a small group, during a busy operational period, or through a delivery route that filters messages differently may not be comparable with a previous exercise. Capture these conditions before launch, then include them when results are reviewed. If the audience, scenario, or reporting process changed, say so plainly instead of presenting two percentages as a clean trend.
Separate the observation from the explanation. “Some recipients clicked this message” is an observation. “Employees lack awareness” is an interpretation that may not follow from the evidence. The message might have matched a legitimate workflow, the action might have been unclear, or the reporting route might have been difficult to find. Interviews, employee feedback, and process reviews can help test possible explanations without assuming intent.
Use a stable set of definitions across reports. Decide whether delivery failures are excluded from the denominator, how you treat repeat actions, what counts as a report, and the time window for reporting. Keep the definitions visible to decision-makers. When definitions change, mark the break in the series and avoid describing it as a direct improvement or decline.
Also be careful with subgroup comparisons. Small groups and differences in role, language, access, or working conditions can make a rate unstable or misleading. Aggregate when appropriate, limit access to identifiable results, and avoid using simulation outcomes as a shortcut for evaluating individual performance. The purpose is to find patterns the organization can address and to offer relevant support—not to attach a permanent label to a person.
Finally, connect each measure to a decision. If a metric would not change what the team does, it may not belong in the core report. A concise review can state the risk question, what was observed, what context matters, what action follows, and when the team will evaluate it again. This makes uncertainty visible while keeping attention on practical prevention.
A realistic exercise should still be safe, purposeful, and proportionate. Before launch, agree on the audience, objective, scenario boundaries, data handling, and what will happen after an interaction. Involve the people responsible for security, privacy, legal review, and employee communications as appropriate to your organization.
These safeguards strengthen the quality of the evidence as well as trust. If participants believe a test is designed to trap or embarrass them, the exercise can weaken reporting culture and produce behavior that is hard to interpret. Build communication and review into the program rather than treating them as final approval steps.
Use a short, repeatable cycle. The objective is to make one or two changes that can be evaluated, not to launch every possible activity at once.
Assign clear ownership for each step. Security teams may coordinate campaign design and analysis, while operational teams can help examine the work itself. Leaders should agree on acceptable use of results and how the program will communicate its purpose. A signal-to-response approach can help teams connect observations to proportionate action instead of leaving campaign data in a report.
For organizations expanding beyond standalone training, a broader human risk management program can connect behavior, identity, and threat context. The goal is not to collect every possible data point. It is to make better decisions about prevention and support.
Before assigning a maturity label or expanding the program, leaders can ask a small set of practical questions:
If several answers are unclear, that is a useful starting point—not proof of failure. Prioritize the gap with the clearest relationship to the risk question and the greatest practical impact. Teams can also review Living Security plan options when evaluating how a platform may support their program requirements.
A maturity label is most useful when it reflects the conditions in which people actually work. A global organization may need to account for different languages, devices, time zones, and reporting routes. A team with frequent customer or financial workflows may need scenarios that examine verification steps without disrupting legitimate work. In each case, maturity means understanding the relevant context and designing a fair way to learn from it.
Teams can make the model actionable by assigning an owner and a review cadence to each capability. For example, the campaign owner can document scenario intent and delivery conditions; the people responsible for incident response can confirm how reports are triaged; and privacy or governance partners can review access and retention. These responsibilities may sit with different groups. What matters is that they are explicit and coordinated before a campaign begins.
Review the program after each cycle, but avoid changing several things at once if you need to understand which change mattered. If a team updates a reporting button, changes the scenario, and launches targeted learning in the same period, a later shift in outcomes will be hard to interpret. Keep a simple decision log: what the team observed, what action it chose, what conditions changed, and what result would prompt another adjustment.
Finally, treat maturity as uneven and revisable. A program may have strong participant safeguards and reliable reporting while still lacking a useful baseline. That is not a reason to force a single score. Record strengths, gaps, and the next practical improvement. This keeps the model focused on learning and helps leaders direct effort toward conditions the organization can change.
Explore a human risk management approach
A mature phishing simulation program helps an organization learn responsibly, improve the conditions around secure behavior, and judge progress with evidence that has clear limits. Start with one well-defined question, make one meaningful improvement, and keep the people doing the work at the center of the process.