Why do phishing programmes often fail even when completion rates are high?

Why This Matters for Security Teams

Phishing programmes fail for a simple reason: they often optimise for administrative completion, not exposure reduction. A workforce can finish every module and still remain vulnerable if training is untargeted, messages are generic, and the organisation never checks whether people actually report suspicious activity or avoid unsafe actions. That gap matters because phishing is rarely just an awareness problem. It is an identity and access problem, a credential theft problem, and often the first step in account takeover or business email compromise.

Security teams also miss that phishing risk is uneven. Finance, HR, executives, help desk staff, and users with privileged workflows face different attack patterns. A single annual campaign does not reflect that reality. Current guidance in the NIST Cybersecurity Framework 2.0 emphasises outcomes, governance, and continuous improvement rather than checkbox activity. In practice, many security teams encounter real phishing exposure only after a credential replay, mailbox compromise, or token theft has already occurred, rather than through intentional measurement of behaviour change.

How It Works in Practice

Effective phishing programmes treat training as one control in a broader detection and resilience model. That means linking simulations and awareness content to real threat patterns, user roles, and identity signals rather than sending the same bait to everyone. The programme should measure whether people report suspicious messages, whether risky clicks decline over time, and whether users who handle sensitive workflows receive more targeted coaching.

In practice, the strongest programmes combine awareness with technical controls:

• Risk-based targeting using business role, privilege level, and exposure to external communication.
• Phishing simulations that reflect current attacker tactics, including QR phishing, OAuth consent abuse, and MFA fatigue.
• Fast reporting paths into SIEM or SOAR so suspicious messages become detectable events, not just training data.
• Identity protections such as phishing-resistant MFA, conditional access, and session monitoring to reduce the impact of mistakes.
• Post-incident review that checks whether messages were opened, credentials were entered, tokens were granted, or access was misused.

This approach aligns with guidance from the CISA Secure Our World campaign and with the MITRE ATT&CK view of phishing as a delivery technique that often precedes credential theft and lateral movement. It also fits with the operational reality that user behaviour is only one layer. If identity assurance is weak, a single successful phish can still lead to abuse even when the training metrics look healthy. These controls tend to break down when organisations rely on generic annual training and lack telemetry from mail, identity, and endpoint systems because there is no way to verify whether behaviour has actually changed.

Common Variations and Edge Cases

Tighter phishing controls often increase operational overhead, requiring organisations to balance lower user risk against more time spent on campaign design, analysis, and follow-up coaching. That tradeoff becomes more pronounced in high-churn workforces, outsourced support environments, and global organisations with mixed language and cultural contexts.

There is no universal standard for what “good” phishing performance looks like yet. Some programmes focus on click rates, but current guidance suggests click rate alone is too narrow because it ignores reporting, credential entry, MFA approval abuse, and downstream containment. Others emphasise just-in-time training after a simulated fail, which can improve retention, but only if it is paired with access controls and clear reporting channels.

The identity intersection matters most where phishing targets privileged users, service accounts managed by people, or workflows that unlock sensitive systems. In those cases, the question is not only whether a person clicked. It is whether the attack could translate into credential compromise, privileged session abuse, or delegated access misuse. Programmes that ignore those pathways often look effective on paper and still fail against real adversaries.

Related resources from NHI Mgmt Group

• Why do access reviews still fail even when completion rates are high?
• Why do passwordless programmes stall even when deployment rates are high?
• Why do MFA programmes often fail even when the login flow is protected?
• Why do completion rates fail as audit evidence for security awareness programmes?