What should security leaders do when phishing simulations are creating fatigue or resentment?

Why This Matters for Security Teams

Phishing simulations are meant to improve reporting, reinforce caution, and reveal where human judgement is most likely to fail. When they become predictable or overly frequent, the programme starts measuring irritation instead of resilience. That creates a governance problem, not just an awareness problem: users stop trusting the exercise, reporting rates can fall, and leaders lose the signal they need to understand real exposure.

The control objective is better captured by NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around awareness and training, because the point is to shape secure behaviour over time. Security teams often misunderstand this as a volume problem and keep sending more tests when the actual issue is programme design. A mature programme treats phishing simulations as one input into a wider security culture, not as a punishment mechanism.

In practice, many security teams encounter reporting drop-off only after resentment has already spread through the workforce, rather than through intentional feedback from the programme itself.

How It Works in Practice

The most effective response is to redesign the simulation programme around relevance, variability, and follow-up. That means changing the template, sender style, theme, and difficulty so employees cannot simply memorise the pattern. It also means aligning scenarios to the threats people actually face, such as invoice fraud, password reset abuse, cloud collaboration lures, or business email compromise.

A useful operating model is to separate three functions: testing, coaching, and measurement. Testing should show whether people recognise suspicious content. Coaching should happen privately and immediately after failure, with short guidance on the telltale signs that were missed. Measurement should focus on trends such as reporting rates, time to report, and repeat mistakes, not public scoreboards. Current guidance suggests that public shaming reduces trust and can suppress the exact behaviour security teams want, which is early reporting.

• Use segmented campaigns so finance, HR, engineering, and executives see realistic lures.
• Vary difficulty and channel, including email, SMS, collaboration tools, and voice where appropriate.
• Offer just-in-time training that explains the missed indicators in plain language.
• Reward reporting behaviour, not perfection, so users learn that escalation is valued.

For programme governance, many teams also anchor expectations in identity and access practices, because phishing often becomes harmful when it leads to credential theft or session compromise. If leaders want the baseline control logic, OWASP guidance on user interaction risk and CISA phishing guidance help reinforce why reporting and rapid containment matter. These controls tend to break down when simulations are deployed as a fixed monthly script across a large, diverse workforce because the exercise becomes predictable and detached from actual business risk.

Common Variations and Edge Cases

Tighter testing discipline often increases coordination overhead, requiring organisations to balance behavioural realism against employee experience. That tradeoff matters most in unions, regulated environments, and distributed workforces, where aggressive campaigns can quickly be interpreted as surveillance or mistrust.

Best practice is evolving for high-friction cases such as repeated failures by the same users, executive-targeted campaigns, or teams with high customer-facing load. In those environments, escalating the number of simulations usually makes fatigue worse. A better pattern is targeted coaching, manager involvement, and scenario selection based on observed risk. Where an organisation handles sensitive data or payment workflows, phishing simulation results should also feed into broader control reviews, including access hygiene, step-up authentication, and incident reporting readiness.

There is no universal standard for the exact cadence or failure threshold that should trigger retraining. What matters is that the programme remains fair, proportionate, and clearly tied to risk. If a simulation causes resentment, that is often a sign the content is too repetitive, too punitive, or too disconnected from real attack paths. The right response is to recalibrate the programme, not to intensify pressure.

OWASP materials on security education and user-centred control design are useful references when teams need to justify a more adaptive approach.

Related resources from NHI Mgmt Group

• How should security teams reduce phishing risk in MFA without creating more user friction?
• How should security teams use impossible travel detection without creating alert fatigue?
• How should security teams use ITDR without creating alert fatigue?
• What do security teams get wrong about phishing simulations?