Skip to main content
← All controls
IR-7 / AT-2 NIST SP 800-53 Rev 5

Can users one-click report a suspicious email to the security team?

Demonstrate that end users can report suspicious emails to the security team through a one-click or minimal-friction mechanism integrated into their email client, and that reported messages are reliably received and triaged by security personnel.

Description

What this control does

This control ensures end users have a simple, embedded mechanism—typically a button or add-in within their email client—to report suspected phishing, malware, or social engineering attempts directly to the security operations or incident response team. The reporting function should require minimal user effort (ideally one click), automatically forward the suspicious message with full headers intact, and optionally remove it from the user's mailbox to prevent accidental interaction. This capability transforms users into a distributed sensor network, enabling faster threat detection, incident triage, and organizational learning from real-world attack attempts.

Control objective

What auditing this proves

Demonstrate that end users can report suspicious emails to the security team through a one-click or minimal-friction mechanism integrated into their email client, and that reported messages are reliably received and triaged by security personnel.

Associated risks

Risks this control addresses

  • Users who lack an easy reporting mechanism fail to alert security teams about phishing emails, allowing attackers to persist undetected across the organization
  • Employees manually forward suspicious emails without preserving headers, stripping forensic evidence needed for threat intelligence and incident investigation
  • High-friction reporting processes (e.g., copying email to a special address, filling forms) discourage user participation, reducing detection of novel phishing campaigns
  • Lack of centralized reporting prevents security teams from correlating multiple instances of the same phishing campaign across departments or geographies
  • Users who cannot easily report threats may instead delete suspicious emails or engage with them out of uncertainty, increasing risk of credential compromise or malware infection
  • Absence of user reporting delays threat intelligence enrichment, preventing timely blocking of malicious domains, sender addresses, or payload hashes
  • Security teams remain blind to social engineering tactics that bypass automated email filtering, missing opportunities to adjust defenses or conduct targeted awareness training

Testing procedure

How an auditor verifies this control

  1. Inventory the email platforms and clients in use across the organization (e.g., Microsoft 365 with Outlook, Gmail with web/mobile clients, third-party mail applications).
  2. Identify the installed phishing-reporting tool or add-in (e.g., Microsoft Report Message add-in, PhishAlarm, Cofense Reporter, KnowBe4 PhishAlert) and document version, deployment scope, and configuration method (GPO, mobile device management, user self-install).
  3. Review deployment logs, Active Directory group memberships, or MDM policy assignments to verify the reporting tool is deployed to all user populations within scope.
  4. Select a representative sample of 5–10 users across different departments and device types, and visually confirm the presence and visibility of the report button or menu option in their email client interface via remote session or screenshot.
  5. Conduct a simulated test by sending a benign test email to sampled users and instructing them to use the one-click reporting function, observing the steps required and timing the effort.
  6. Review the security team's mailbox, SIEM, ticketing system, or dedicated phishing inbox to confirm receipt of the test-reported messages, verifying that full email headers, attachments, and metadata are preserved.
  7. Interview security operations or SOC personnel to confirm their process for triaging, acknowledging, and acting upon user-reported emails, including typical response times and escalation workflows.
  8. Examine metrics or dashboards (if available) showing volume of user-reported emails over the prior 90 days, and review a sample of reported items to assess quality and appropriateness of user reporting behavior.
Evidence required Collect screenshots or configuration exports showing the phishing-report add-in deployed in representative email clients, deployment policy documentation (GPO settings, MDM profiles, or SaaS admin console configurations), sample emails received in the security team's reporting queue with full headers intact, and metrics reports or SIEM dashboards illustrating user reporting volume and security team response actions over the past quarter.
Pass criteria The control passes if a one-click or minimal-friction email reporting mechanism is deployed to all in-scope users, test users can successfully report an email in under 30 seconds without external guidance, and the security team reliably receives reported messages with complete headers and metadata for triage.