Report rate is the proportion of employees who correctly report a suspicious message instead of simply ignoring or clicking it. It is a stronger indicator of security maturity than click rate alone because it measures active detection behaviour, response readiness, and whether training is translating into practical action.
Expanded Definition
Report rate describes how often people turn a suspicious message into a report that reaches the security function, rather than treating the message as noise. It is a behaviour metric, not a technical detection metric, so it reflects whether employees recognise potential phishing, business email compromise, or social engineering and know what to do next.
It also helps separate awareness from action. A workforce can have low click rates and still be weak if users hesitate to report, report to the wrong channel, or fail to escalate quickly enough for investigation. In practice, report rate is strongest when paired with time-to-report and report quality, because those measures show whether the organisation can convert human suspicion into usable security signals.
There is an important boundary here: report rate does not prove a message was malicious, and it does not measure how well analysts triage the resulting alerts. It measures the reliability of the first human step in the detection chain.
Examples and Use Cases
Report rate appears in training, awareness, and incident-readiness programmes where the goal is to make employees an active part of early detection. It is most useful when the organisation wants to know whether staff will interrupt a suspicious campaign quickly enough to limit spread or credential exposure.
- A phishing simulation checks how many recipients use the approved report button instead of deleting the message or forwarding it informally.
- A security team compares report rate across departments to spot where reporting habits are weak or where local managers are not reinforcing the process.
- An organisation measures whether staff report suspicious login prompts or invoice-change requests before a fraud attempt reaches finance or identity teams.
- A programme reviews false reports as well as true reports, because a high volume of unusable reports can slow response if guidance is unclear.
The main trade-off is that aggressive reporting campaigns can create alert fatigue if employees are asked to report too broadly. The useful signal is not just volume, but whether reports are timely, relevant, and actionable.
Security Implications
When report rate is low, suspicious messages can sit in inboxes long enough to be clicked, forwarded, or acted on without challenge. That creates a wider attack window for phishing, account takeover, malware delivery, and invoice fraud. It also weakens the organisation’s ability to detect campaigns early, because the security team loses one of the fastest human sources of confirmation.
Low report rate often points to practical breakdowns rather than simple awareness gaps. Employees may not trust the reporting channel, may not understand what qualifies as suspicious, or may fear making unnecessary reports. The result is a weak feedback loop: the organisation trains users, but the training does not reliably produce security action.
For practitioners, the key warning sign is when simulations show acceptable click avoidance but poor reporting behaviour. That usually means the organisation has taught people to avoid harm, but not to help detect it.
Domain and Governance Relevance
Report rate matters in security governance because it measures whether people are functioning as part of the detection control plane. It is especially relevant in email security, social engineering defence, and incident reporting programmes, where human observation can surface threats before automated tooling does.
In identity-adjacent environments, report rate is also important when suspicious messages are used to steal passwords, MFA codes, session tokens, or payroll change approvals. In those cases, fast reporting supports account containment and reduces the chance that a social engineering attempt becomes an identity compromise.
For NHI and agentic environments, the same principle extends to messages that seek to trick operators into approving API keys, service-account access, token grants, or tool permissions. The governance issue is not only whether users notice the threat, but whether the organisation can convert that notice into a controlled response path.
Risk and Threat Considerations
Low report rate creates a material exposure because it gives suspicious communications more time to progress from initial contact to credential theft, fraud, or malware execution. The risk is not abstract awareness failure; it is delayed detection and missed escalation during the earliest phase of an attack.
Failure mechanism: Attackers rely on users ignoring suspicious messages, misclassifying them as routine business traffic, or reporting them too late for containment. That delay can allow phishing kits, fake login pages, invoice manipulation, or malicious attachments to succeed before defenders intervene.
Impact: The organisation may lose early warning, widen the blast radius of a campaign, and increase the chance of account compromise, financial loss, or broader incident response effort.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Report rate supports quick escalation of suspicious access attempts. |
| 14 — Security Awareness and Skills Training | Report rate measures whether awareness training converts into reporting action. | |
| Recommendation — Use access reporting signals to accelerate containment of suspicious account activity. Measure training effectiveness by tracking whether users report suspicious messages. | ||
| NIST CSF 2.0 | DE.CM — Security Continuous Monitoring | Report rate is a human-input signal into ongoing monitoring and detection. |
| RS.AN — Incident Analysis | Reported suspicious messages must be analyzed to confirm threat and scope. | |
| Recommendation — Incorporate employee reports into continuous monitoring and incident detection workflows. Analyze user-reported messages quickly to validate threat patterns and scope. | ||
| MITRE ATT&CK | T1566 — Phishing | Report rate is directly relevant to phishing and social engineering detection. |
| Recommendation — Map reported messages to phishing patterns and hunt for related delivery activity. | ||
Practitioner Guidance
What to watch for: Treat report rate as a behaviour signal that needs context, not a standalone score. A healthy metric usually requires clear reporting channels, quick analyst acknowledgement, and enough user confidence that staff choose reporting over silence or informal forwarding.
Governance implication: Ownership should sit with both awareness and response teams, because the metric only matters if reports become usable detections. If reporting is easy but triage is slow, users will stop trusting the process and report rate will usually fall over time.
Practitioner takeaway: The most useful improvement is not just asking people to report more, but making the report path obvious and the response visibly worthwhile.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
