The 5-minute phishing-triage playbook

A SOC analyst's job on a phishing report is not to be right. It is to be right enough, fast enough. The fifth report in a campaign is more valuable than the third, and the third is more valuable than the second — every minute you spend on one is a minute the next four are sitting in the queue. The shape of a good triage workflow is therefore not depth-first; it is the cheapest answer that's defensible.

Why five minutes is the right ceiling

Five minutes is what we observe is the sustainable median across the SOC teams we work with. Faster than that and analysts skip the documentation step, which means the auditors come back with questions you can't answer. Slower than that and the queue grows faster than it drains during a campaign, which means users start ignoring the "report" button — and that is the actual attack surface you're defending.

Internal benchmark: if your analysts can't consistently land a verdict + a short note in under five minutes for the median report, the problem is rarely analyst skill. It's tooling. The triage UI is asking too many clicks per report, or the reports themselves arrive without enough context for the analyst to skip the first 90 seconds of header-parsing.

The four-axis decomposition

Every reported email decomposes into four questions, in order. The first answer that's confident-enough resolves the verdict; the analyst doesn't need to keep going.

1. Sender reputation

Look at the rendered sender, the envelope sender, and the Reply-To header. A mismatch between any two of these is the single highest-signal indicator we measure — it predicts phishing with high precision and the analyst doesn't need much beyond it. Sender domains that have authoritative SPF / DKIM / DMARC pass andmatch the rendered brand are almost always legitimate (or compromised — which is a different verdict).

2. Content cues

Urgency language ("your account will be suspended"), uncommon request patterns ("gift cards for the team"), and out-of-band finance requests are the three patterns that drive most of the value here. None of them are diagnostic on their own. They're cumulative — three weak content signals plus a sender mismatch is a verdict; one strong sender match plus a single urgency line is not.

3. Payload

Treat every link and every attachment as untrusted until shown otherwise. URL shortener domains, IP-address links, and lookalike domains (paypaI vs paypal, with the capital I) are the high-precision tells. For attachments, the file extension matters more than the MIME type — a .docm with macros, a .iso wrapping an .exe, or a .html attachment that asks for credentials when opened are all near-certainty malware verdicts if the file actually loads.

4. Intent

Once you have a confident read on sender, content, and payload, the last step is classifying the attacker's goal. A credential-harvesting login page is phishing. A wire-transfer request from a spoofed executive is fraud (and gets escalated automatically — see below). A drive-by installer is malware. A mass untargeted offer is spam. The verdict matrix is small enough to keep in your head; the discipline is in not picking phishing for everything that looksphishing-shaped.

The verdict decision matrix

The six verdicts a Phishguard analyst can pick and the rule of thumb for each:

• Phishing — credential or session-cookie harvesting. The user is the asset being attacked.
• Fraud — money or sensitive data is being asked for directly. Vendor-impersonation invoices, gift-card requests from a spoofed CEO, refund scams. Auto-escalates to the tenant's security manager because the time-to-loss window is measured in hours.
• Malware — the payload IS the threat. A loader, a stealer, a ransomware dropper. Pull the attachment to a sandbox and confirm.
• Suspicious — the user was right to report but you can't confirm. Treat the sender as untrusted, log the indicators, move on. Avoid over-using this verdict — it's a polite version of "I don't know," and three of those a week is fine; three a day is a process problem.
• Spam — unsolicited bulk mail, no security implication beyond gateway tuning. Mark it, move on, don't notify the reporter (most spam reports come from users who would rather just see less spam).
• Clean — the email was legitimate or harmless. Reporting it was still the right call; the reporter just hears nothing back.

When to escalate

Three concrete triggers. Anything else, the verdict closes the report on its own.

1. Fraud verdict. Always. Automatic. The platform fires the security-manager incident email the moment the analyst clicks the verdict button. If finance hasn't engaged within an hour of a fraud verdict, the ticket goes to the SOC lead for follow-up.
2. Confirmed malware that was opened. The reporter clicked the link or opened the attachment before reporting. Escalate immediately even if the verdict suggests low impact — assume credentials are gone, sessions are hijacked, and the host needs isolation.
3. Same campaign hitting more than ten users within an hour.This is the volume signal that a mailbox / DMARC / gateway control just failed in some way that needs the SOC lead. A solo verdict on an individual report doesn't address the gateway gap.

Documentation for the audit trail

Three lines, every verdict. The auditors are happy. Future-you is happy when the verdict comes back contested and you need to remember what you saw.

1. What you saw. The one most-diagnostic signal you used — "Reply-To pointed at a different domain," "attachment contained a credential-harvesting page," etc.
2. What you ruled out. The thing that looked like the verdict but didn't hold up. "Sender mismatch was actually just a shared mailbox alias, confirmed in their AD."
3. Who else needs to know. The notification flags you ticked — reporter only, security manager, both, neither. Future you will look at this when the reporter calls the helpdesk saying they never got an email.

In Phishguard, that note lives on the verdict-set form and flows into the audit log + both notification emails automatically.

See how this looks in practice on the analyst dashboard. Request access and our team will walk you through the queue on a real tenant's data.