> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/human-security/report-button/reports.md). # Reviewing reports All reported emails are centralized in `Human Risk` > `Report` > `Results`. From there, you open each report, check its source and set a verdict. ## Reported Threats table The table lists every email reported across your team, sorted by most recent report.
ColumnWhat it shows
Reported atWhen the employee reported the email.
ReporterThe employee who reported the email.
SenderThe original sender of the email.
SubjectThe subject of the reported email.
SourceWhether the email is a Stoïk Simulation or a Suspicious email.
ValidityWhether the report is a True positive, a False positive, or Pending review.
Filter the table by **Status**, **Reporter**, **Source**, or **Validity**, or use the search bar to find a specific email. ## Side panel Click a row to open the full context of the report: * The reporter (name, email, channel: Outlook or Gmail) * The email itself (sender, recipients, subject, body preview, attachments) * The analysis (source, validity, hints when available) * Recommendations for what to do next, when the report needs your attention ## Sources Each report is classified as one of two sources. ### Stoïk Simulation The email was part of a phishing simulation you ran. The employee correctly spotted a fake email designed to test their vigilance. * The validity is automatically set to `True positive`. * No action is required. The report counts in the campaign stats and in your team's awareness metrics. * The side panel shows the simulation hints (for example, urgency wording, sender mismatch) so you can see what your employee spotted. ### Suspicious email The email is not part of any Stoïk simulation. It could be a real phishing attempt, a simulation from another vendor, or a legitimate email that looked suspicious to the reporter. * **Without Email Security**: the validity stays `Pending` until you set a verdict (`True positive` or `False positive`). The side panel gives remediation steps to help you investigate (check the sender, check the links, confirm out-of-band). * **With Email Security**: the Stoïk SOC re-analyzes the email automatically. See [Email Security integration](#email-security-integration). ## Email Security integration When Email Security is active, the Stoïk SOC re-analyzes every reported `Suspicious email`: * You do not have to investigate the email yourself. * The validity is updated with the SOC verdict: `True positive` if a real threat is confirmed, `False positive` otherwise. * If a real threat is confirmed, the SOC acts directly (quarantine across affected mailboxes, notification to your team). {% hint style="info" %} Email Security also blocks most real phishing attempts before they reach your team. The emails reported through the Report button are the ones that slipped past this first line of defense, plus legitimate emails employees want to double-check. {% endhint %} If your organization does not have Email Security yet, [book a demo](https://stoik.io/contact). ## Notifying the reporter Once you set a verdict, the reporter can receive an email telling them whether the reported email was a real threat (`True positive`) or not (`False positive`). To turn it on, go to `Human Risk` > `Overview` > `Settings` and enable **Notify employees of the verdict**. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/human-security/report-button/reports.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.