Insight
Suspicious Email Reports: A Workflow for Analysis and Response
A practical workflow for IT teams and CSIRTs: assign owners, analyze reported emails, reply to employees, verify response actions, and track unfinished work.
When an employee reports a suspicious email, acknowledge it first. Then decide who will investigate, what to tell the reporter, and who will carry out any necessary response. Encouraging reports and improving the team's ability to handle them can happen together.
Providing a report button does not define the work that follows. A report may reach a shared mailbox without anyone taking ownership, or an analysis may be completed without a reply to the employee. Each step needs an owner and a clear completion condition.
This guide organizes the work of IT teams and CSIRTs that receive suspicious email reports. Whether you have a dedicated team or a few people sharing responsibilities, you can start with your existing reporting channel.
Design the reporting channel and the receiving workflow together
In implementation discussions with Yagura, one organization described reporting destinations that differed across departments and too few people to review submissions. It had limited the scope of reports it requested. Another concern was that automatically sending analysis results to employees might cause misunderstandings, unnecessary actions, or duplicate reports.
The first issue concerns work after intake; the second concerns what people do after receiving a reply. Even with the same reporting feature, the checks needed can differ.
The aim is to preserve an environment where people can ask for help when something looks suspicious, while organizing investigation and communication. Japan's Information-technology Promotion Agency (IPA) also describes testing the workflow from receiving many reports through completing the response as one possible purpose of phishing exercises. Read IPA's explanation (Japanese).
Divide the workflow into five tasks
The following is a model proposed by Yagura. One person may own several tasks. Adapt the responsibilities to your procedures and specify what must be passed to the next person.
Task | Decide in advance | Completion condition |
|---|---|---|
Intake and organization | Initial destination, assignment, and grouping of related reports | The person who accepted ownership is known |
Analysis | Message details, user actions, and any further investigation needed | Evidence and missing information are organized |
Decision and reply | Who decides the result and what to tell the reporter | The reporter receives the result or a pending-review update |
Necessary response | Decision authority, execution permissions, and coordination with other teams | The outcome is verified, beyond simply issuing instructions |
Record keeping | Conclusion, evidence, actions taken, and remaining work | Unfinished tasks and their next owners are visible |
Distinguish an acknowledgment from an investigation result
“We received your report” does not mean that the message has been confirmed safe. At intake, thank the reporter, explain that review is under way, request any additional information needed, and provide a contact point.
A result notification should separate what is known from what remains unconfirmed. If a decision is pending, explain what is being checked and when to expect the next update instead of forcing a premature conclusion.
If the user has opened a link or entered information, pass those details to the investigation and response owners. Classifying the email and assessing the user's actions are separate tasks.
A reply should explain the next step, not just provide a classification. For example: “We are reviewing your report. If you have already opened a link or entered information, please tell this team what happened.” Adapt this example to your organization's procedures and contact methods.
If work remains after a reply, record “reporter informed” separately from “response complete.” A quick response should not cause unverified issues to be marked as resolved.
Preserve each reporter's details when combining investigations
Related reports can share an investigation, but matching subject lines alone are not enough: senders and destination URLs may differ.
For example, if several employees report similar invoices, first confirm whether the contents belong to the same incident. Share the analysis where appropriate while retaining each reporter's receipt time, actions taken, and reply destination.
Choose automation based on what happens after the reply
Recording intake and notifying an owner are candidates for automation. Interpreting a result and taking action also depend on the recipient's understanding and authority.
Some organizations discussing implementation with Yagura have requested administrator-only notifications because of concerns about misunderstandings. Consider what the recipient will do next, as well as how quickly a message can be sent.
Define when an automatic reply is appropriate and when a person must review it.
Use a pending-review response when the available evidence is insufficient.
Provide a contact route for users who have already interacted with the message.
Define how to correct a changed conclusion and notify affected people again.
The presence of AI is not the only decision criterion. Existing products or internal processes may cover part of the workflow. Microsoft 365, for example, provides settings for user-reported messages and feedback, while some automated investigation and response capabilities depend on Defender for Office 365 Plan 2. Check your licenses and configuration before identifying the remaining gap. Microsoft's user reported settings documentation.
Improve the point where work gets stuck
Before replacing the whole process, trace a recent report from intake through the final record. Identify where ownership became unclear or work waited.
Use the following Yagura checklist as a starting point and adapt it to your team.
What you observe | What to decide | What to verify |
|---|---|---|
Several destinations, with no clear owner | Initial destination and handoff rules | Owner and assignment time are recorded |
Repeated investigation of similar messages | Criteria for treating reports as the same incident | The investigation remains linked to each report |
Analysis is ready but no reply is sent | Reply owner and communication while a decision is pending | The reporter receives guidance |
A threat is identified but action has not followed | Decision maker and person authorized to execute | The action's outcome is verified |
Work stops when the owner is absent | Backup owner and urgent contact route | Someone can accept ownership during an absence |
A small organization can start by naming a regular owner and a backup contact. You do not need to promise immediate handling of every out-of-hours report, but communicate the route for urgent indicators separately from routine intake.
Requesting an action is not the same as completing it. If email deletion or another response is required, hand it to a person with the necessary permissions and verify the outcome. If it cannot happen immediately, record the reason and the next owner.
Run a small pilot that tests both sides of reporting
Yagura's implementation support has included internal communication and a departmental pilot before extending a report button to a wider audience. A small test should cover the downstream work as well as whether the button works.
Use a test email to check acknowledgment, assignment, handling of a pending decision, and the final reply. Walk through scenarios involving similar reports and an absent owner as well.
Allow for real reports arriving during a training exercise. Identify the relevant messages rather than closing reports in bulk simply because training is in progress. Any additional actions requested from employees should follow your approved verification procedures.
Track unfinished work and waiting time alongside reporting rates
More reports may indicate a stronger reporting habit or a single message reaching more people. Volume alone does not establish that the organization has become safer or more exposed.
To assess improvements on the receiving side, Yagura proposes recording:
The number of unassigned reports and reports awaiting a decision.
Time from intake to the first reply, and from intake to completion of the necessary response.
Hands-on time spent on analysis, replies, and records.
The reasons for additional checks, corrections, and handoff delays.
Separate hands-on work from elapsed response time. Even a short analysis can lead to a slow reply if a report waits for an owner. Look at the reasons behind long-running reports as well as averages to find the next improvement.
Count unique reporters separately from investigated incidents. Combining several reports into one investigation should not make the reporting population appear smaller.
Start by making unfinished reports and their next owners visible in the channel you already use. Then improve analysis, replies, and response so employees can continue reporting with confidence.
For the broader training process, see our guide to targeted email simulations. For a product that supports analysis after reporting, see PhishAI.
If you use exercises to practice reporting, also see our decision guide to phishing simulation difficulty.
References
IPA, Clarify the purpose of targeted email exercises in your organization, July 31, 2017 (Japanese).
Microsoft Learn, User reported settings.
