TASKS
Scenarios
Investigating a Phishing Report
A practical workflow for validating suspicious messages, determining user impact, preserving evidence, and escalating when needed.
Use this page to run a governed phishing investigation from first report to explicit closure or escalation.
1. Problem this page solves
Phishing triage often fails in three ways:
- scope expands before authority is checked
- conclusions are asserted before evidence is sufficient
- escalation is delayed because compromise is treated as a confidence question instead of a control boundary
This page defines a bounded investigation sequence with explicit gates so actions and conclusions remain reviewable.
2. Reader outcome
After this page, you should understand:
- the ordered investigation path from signal intake to case disposition
- where scope, evidence sufficiency, and escalation must be decided
- what evidence must be preserved at each stage
- how to separate observed facts from inferred conclusions
- how to close locally or hand off with a complete package
3. Mechanism-first investigation sequence (signal intake to closure)
- Intake and case binding. Record report source, timestamp, reporter, and suspicious artifact reference.
- Preserve primary artifact. Preserve original message/artifact before analysis or remediation.
- Validate technical indicators. Review sender identity, routing/authentication data, destinations, and attachment details.
- Assess interaction and impact. Establish whether the target clicked, submitted credentials, approved MFA, or executed content.
- Classify and choose disposition. Mark benign, suspicious/unconfirmed, phishing, or probable compromise based on current evidence only.
- Close or escalate explicitly. Either close with bounded rationale or escalate with evidence package and unresolved risk notes.
4. Decision gates at each stage
| Stage | Scope gate | Evidence sufficiency gate | Escalation gate |
|---|---|---|---|
| Intake and case binding | Is this report in your authorized intake lane and asset boundary? (Is This In Scope?) | Do you have enough intake context to start (reporter, time, artifact reference)? | Escalate immediately if reporter or target falls outside local authority boundary. |
| Preserve primary artifact | Is preservation method allowed for this data class and system? | Is the original artifact (or immutable provider reference) captured without alteration? | Escalate if you cannot preserve the primary artifact without policy exception. |
| Validate technical indicators | Are planned checks limited to authorized message/artifact analysis? | Do collected indicators support a bounded technical finding (e.g., spoofing pattern, malicious destination)? | Escalate if indicators imply active campaign, privileged target exposure, or controls failure. |
| Assess interaction and impact | Is user/account follow-up within your role and approval boundary? | Do you have direct interaction facts (click, credential entry, MFA approval, execution) from reliable sources? | Escalate if interaction suggests account or endpoint compromise, or if impact cannot be bounded. |
| Classify and choose disposition | Is selected action (warn, quarantine, reset, hold) authorized at your level? | Is classification supported by preserved artifacts and explicit rationale? (What Evidence Is Required?) | Escalate if required action exceeds local authority or evidence remains insufficient under risk. |
| Close or hand off | Is local closure allowed for this event class? | Does the record let another reviewer reconstruct what was observed, decided, and done? | Use Do I Need to Escalate? when authority, evidence, or risk boundaries are exceeded. |
5. Evidence path (what to preserve, and when)
| When | Preserve | Why it is required |
|---|---|---|
| At intake | report source, reporter identity, timestamp, artifact identifier/location | establishes chain of intake and case origin |
| Before analysis | original message/artifact copy, full headers/metadata, recipient scope | preserves primary evidence before any change |
| During indicator validation | extracted URLs, resolved destinations, sender/reply-path comparison, attachment metadata/hash where available | supports technical findings and classification rationale |
| During interaction assessment | user statement, auth/access logs, endpoint/mail telemetry tied to interaction claims | distinguishes attempted phishing from probable compromise |
| At disposition | classification decision, action taken, approval/escalation records, unresolved questions | supports closure review or escalation handoff |
Screenshots are supporting artifacts, not substitutes for primary evidence.
6. Observed vs inferred
| Layer | What is observed | What is inferred |
|---|---|---|
| Intake and artifact analysis | message content, headers, sender attributes, URLs, attachment properties, report metadata | attacker intent, campaign attribution, full targeting scope |
| Interaction and impact | confirmed clicks/submissions/approvals/execution events, log timestamps, affected identities | degree of compromise, persistence, total blast radius |
| Disposition | documented classification, actions taken, escalation decision and rationale | long-term impact likelihood, future attacker behavior |
Do not promote inferred conclusions to observed facts without additional evidence.
7. Trust assumptions and limits
- reporter statements can be incomplete or incorrect
- mail, identity, and endpoint telemetry can be delayed or missing
- provider metadata can show routing/authentication outcomes but not attacker intent
- absence of evidence is not evidence of absence when logs are incomplete
- this workflow governs triage and bounded response; broader tenant-wide containment may require separate authority and incident handling
See Threat Model for trust boundary context.
8. Closure and handoff
Choose one explicit end state:
- Close locally: evidence is sufficient, risk is bounded, and local authority permits closure. Record final rationale and actions.
- Escalate: evidence or authority boundary is exceeded. Hand off with preserved artifacts, gate outcomes, open questions, and risk notes via Do I Need to Escalate?.
After closure or escalation, return to Scenarios for the next governed case flow or to the relevant decision page for follow-on action.
| When to stop | Stop when the next step would move from message validation into broader account, mailbox, or tenant response without approval. |
| Escalation trigger | Escalate immediately if credentials were entered, MFA may have been approved, code was executed, or privileged accounts are involved. |
| Evidence required | Preserve the message or identifier, sender and recipient details, indicators, user interaction status, and your classification rationale. |
| Next path | Do I Need to Escalate? |