A user reported a phishing email

The most common trigger there is, and the one most often closed too early. The question is never whether the message was phishing. It is who else got it, who acted on it, and whether anything is still running.

Trigger. Somebody forwarded a message to the security mailbox, or clicked the report button.

The first 60 minutes1 of 5 expire

01 02 03 04 05

030 min60

01
Take a copy with headers intact, then hunt the campaign
by 10 minexpires
Export the original with full internet headers before any remediation touches it. Then search delivery across the whole tenant on sender, subject, URL and attachment hash separately: a campaign that rotates the display name rarely rotates all four.
02
Establish who clicked and who authenticated
by 25 min
Two different questions. URL-rewriting tells you about clicks; the sign-in log tells you whether anyone reached a credential prompt and succeeded. A click with no sign-in is an exposure. A sign-in is an incident, and you switch to the account compromise playbook.

Tell somebody

The wider team, if the lure references a real internal process such as a payroll or supplier change
Finance, immediately, if the lure is an invoice or bank detail change
Whoever owns awareness training, with the actual lure rather than a generic example

Drawn from

The documents these steps come from, so you can check one rather than take it on trust.

The evidence

What each source proves, and what it does not.

logon events

Collect it in one go

A read-only script that gathers most of the above in volatility order, with a hash manifest.

Triage collection

Make it yours

Replace the escalation list with real names, and the timings with what your change process actually allows. A playbook that assumes an authority you do not have will stall at the step that needed it.

Take a copy with headers intact, then hunt the campaign

Establish who clicked and who authenticated