Phishing Report and Response Workflow

How do I set up this workflow for my team?

Publish the template in your workspace and it's ready to run immediately, no development or installation needed. You'll want to assign which workspace members handle the security analyst, IT, and security team tasks so reports route to the right people. The request form and reporter emails work out of the box, so staff can start submitting phishing reports right away.

How do staff submit a phishing report?

Staff fill out the public request form with details like the message subject, sender's address, when it was received, the message content, a screenshot, and whether they clicked a link or entered details. No account is needed to submit a report. Once submitted, the workflow creates a record with a reference number and sends the reporter a thank-you email.

What happens if the reporter clicked a link or entered details?

The workflow checks the answer to 'Did you click a link or enter any details?' and, if yes, creates a fire-and-forget IT task to reset the reporter's credentials, due in one day. This task runs alongside the rest of the process rather than pausing it, so assessment and containment can move forward at the same time. The completion of the credential reset stays on that task in the record's task list.

Who assesses the phishing report?

A security analyst is assigned to the report and given a task, due in one day, to assess the message as Malicious or Benign and record any affected users. The workflow waits for this task before moving on, and the assessment and affected users are saved to the record. This gives every report a documented assessment before any containment or closure action is taken.

What's the difference between a malicious and benign outcome?

If the analyst assesses the message as Malicious, the status moves to Containing and a security team task is created to record credentials reset, sender blocked, and affected users notified, due in one day. Once that task is done, those actions are saved to the record and the status is set to Closed, with the reporter emailed that the message was dealt with. If the message is assessed as Benign, the status goes straight to Closed and the reporter is emailed that the message was safe and no action is needed.

Can I customise the tasks or emails in this workflow?

Yes. You can describe the change you want in plain English or edit the steps directly in the workflow editor, and earlier versions of the workflow are kept. This makes it straightforward to adjust task due dates, reword reporter emails, or change what containment steps the security team records.

What does the reporter see after submitting a report?

The reporter receives a thank-you email with their reference number right after submitting the form. Depending on the outcome, they later receive an email telling them either that the malicious message was dealt with or that the message was assessed as benign and no action is needed. They interact only through the form and these emails, with no account required.

How is the credential reset task tracked if the workflow doesn't wait for it?

Because it's set up as a fire-and-forget task, the IT credential reset task runs independently and its completion detail, Credentials Reset Completed, is recorded on that task rather than on the main record. You can still see it listed in the record's task list alongside the rest of the phishing report's activity. This lets urgent credential resets happen without holding up the analyst assessment step.

What gets recorded on the report over time?

Each phishing report is a record with a reference number, a status such as Reported, Containing, or Closed, and a timeline showing what happened at each step. The analyst's assessment, affected users, and any containment confirmations like sender blocked or users notified are saved directly to the record. Every workspace action on the report is logged, giving you a traceable history, though each business should confirm this meets its own security record-keeping requirements.