Low reporting rates are the clearest warning sign, especially when users still rely on manual deletion or have multiple reporting paths that compete with the add-in. Weak awareness, poor training, and no feedback after simulated reports also suppress participation. If the organisation sees many simulations missed but few reports submitted, the programme is not building the habit needed for real-world detection.
What underperformance looks like in a phishing reporting programme
A reporting programme underperforms when it is not turning suspicious messages into quick, routine reports that security can action. The most visible symptom is low participation, but the deeper signal is that users are not building a consistent reporting habit, so suspicious mail is being ignored, deleted, or handled inconsistently instead of entering the response workflow.
The practical question is not only whether people can report, but whether the programme has become the easiest and most trusted path for handling suspicious messages. If users still prefer manual deletion, multiple competing channels, or informal workarounds, the programme is not embedded in day-to-day behaviour.
Underperformance is also visible when missed simulations and real-world reports diverge sharply. If people frequently fail phishing tests but rarely submit real reports, training has not translated into action, feedback loops are weak, or the report mechanism is too frictionful to use under pressure.
What the operational warning signs usually cluster around
Low report volume is the headline indicator, but it should be read alongside quality signals. A healthy programme produces timely reports with enough context to support triage; an underperforming one produces very few reports, late reports after the email has already been deleted, or reports that are too sparse to help analysts separate true phishing from noise.
Another warning sign is channel confusion. If users have to choose between forwarding, deleting, opening a ticket, or using an add-in, the path of least resistance often wins. That usually means the programme is optimising for the organisation's process rather than the user's actual behaviour.
Weak adoption also tends to show up in teams that receive little reinforcement. When users do report and hear nothing back, they learn that the action has no visible value. Over time, that suppresses future reporting even if the technical control exists.
Where reporting metrics are available, look for gaps between exposure and response. A programme can appear active on paper if simulations are sent frequently, yet still underperform if the reporting rate remains flat, reporting latency is high, or security sees no improvement in how quickly suspicious messages are surfaced.
What good performance should change in practice
Good programmes make reporting the default behaviour, not the exception. Users should know the one approved path, understand when to use it, and see that reports are acted on quickly enough to matter. That changes reporting from a compliance exercise into a detection signal that can help contain real phishing attempts faster.
Effective programmes also reduce variance. The best indicator is not just a higher number of reports, but a consistent pattern across business units, user groups, and device types. If performance is strong only in one team or only after recent training, the programme is still fragile.
Feedback is part of performance, not a bonus. When users receive confirmation that a report was useful, or see that it led to a takedown, they are more likely to repeat the behaviour. A programme that never closes the loop usually struggles to sustain engagement.
Risk and Threat Considerations
When reporting underperforms, phishing messages are more likely to linger long enough to be clicked, forwarded, or reused by an attacker. The risk is not just missed detections, but missed speed: every extra minute before reporting increases the chance that the email reaches more users or is used to seed follow-on compromise.
Failure mechanism: Users do not trust or remember the reporting path, so suspicious messages are deleted, ignored, or handled outside the official workflow. That breaks telemetry, slows triage, and makes simulation results look better or worse than real behaviour.
Impact: Security loses an early-warning signal, response becomes slower and less targeted, and the organisation is more exposed to credential theft, account takeover, and broader social-engineering success.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Phishing reporting depends on email controls and user reporting behavior. |
| Recommendation — Strengthen email reporting workflows and user-facing protections to improve detection and response. | ||
| NIST CSF 2.0 | DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Reporting programmes feed detection monitoring for suspicious email activity. |
| PR.AT-01 — All users are provided awareness and training | Underperformance often reflects weak user awareness and poor reporting habit formation. | |
| Recommendation — Use reported phishing signals to improve monitoring and detection coverage. Reinforce user training so suspicious messages are reported consistently. | ||
| NIST SP 800-53 Rev 5 | AT-2 — Awareness Training | Training quality directly affects whether users report phishing attempts. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Programme metrics and user reports need review to spot low adoption and missed detections. | |
| Recommendation — Provide phishing-focused awareness training and verify that it changes reporting behavior. Review reporting metrics and triage outcomes to identify weak adoption quickly. | ||
Practitioner Guidance
What to verify: Check whether one reporting method is clearly preferred and available everywhere users work, including mobile and webmail. If the organisation has multiple competing paths, compare their usage, because low reporting may be a design problem rather than a training problem.
What to measure: Track reporting rate, reporting latency, simulation-to-report conversion, and the share of reports that contain enough context for triage. A programme is improving only if reports arrive quickly and consistently, not merely if phishing content is being noticed.
Common mistake: Treating failed simulations as the only problem. In practice, the more important issue is whether users take a correct action after suspicion arises. A small number of well-formed reports is more valuable than a large amount of passive awareness.
Practitioner takeaway: The goal is not simply to teach users that phishing exists, but to make reporting the easiest and most reinforced response when suspicion appears.
Related resources from NHI Mgmt Group
- What are the signs that malicious Teams activity is being used to deliver phishing or malware?
- Who should own phishing simulation reporting in an identity programme?
- What are the signs that an employee risk reporting programme is failing to reduce exposure?
- What are the signs that an MFA programme is not actually reducing phishing risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
