Phishing Incident Response Guide: How to Track Cases on a Board

How to identify and scope a phishing campaign

Start a case when a message is reported or detected, then determine whether it is isolated or part of a broader campaign. Look for shared sender addresses, domains, URLs, attachment hashes, subject lines, and delivery patterns. Similar-looking messages may be related, but confirm that they share meaningful indicators before grouping them together.

Preserve the original message and its full headers. RFC 5322 defines the Internet message format and the Message-ID field. Use the full identifier for Message-ID correlation, but do not rely on it alone: compare other indicators because identifiers and message copies can vary across mail systems.

Use your mail platform’s email delivery trace to identify recipients and determine whether messages were delivered, rejected, deferred, or otherwise handled. For example, Microsoft’s Exchange Online message trace documentation describes tracing message status and processing events. Search across relevant mailboxes and time ranges, and record the search method and results in the case.

Define the scope in the board: known recipients, confirmed delivery, suspected variants, affected accounts or devices, and unresolved questions. Label findings as confirmed, suspected, or not yet assessed so that an initial lead does not become an assumed fact.

What evidence to record on a phishing case board

Make the board a reliable index to evidence—not a replacement for original logs or files. Assign each case a unique identifier and record the report time, discovery source, owner, severity, status, and a concise incident summary. Use consistent timestamps and time zones so investigators can compare events across systems.

• Message evidence: original message or preserved copy, full RFC 5322 email headers, sender and reply-to details, recipient list, subject, received time, URLs, attachment names and hashes, and relevant authentication results such as SPF, DKIM, or DMARC.
• Campaign and delivery evidence: observed sender or infrastructure indicators, related message variants, affected recipients, email delivery trace results, and the Message-ID values used for correlation.
• User and asset evidence: reported actions, affected account and device identifiers, browser or endpoint observations, and whether the user opened an attachment, followed a link, entered information, or approved a prompt.
• Investigation and response: evidence sources and time ranges searched, findings and confidence, containment actions, action owner, action time, outcome, and any remaining risks.
• Case management: related cases, escalation and communication notes, decision rationale, closure criteria, and follow-up tasks.

Restrict access to sensitive case details and store evidence in approved systems. Keep a clear record of where evidence came from and avoid putting passwords, active tokens, or unnecessary personal information in the board.

How to assess user interaction and credential exposure

Ask the recipient what happened, when it happened, and on which device or account. Determine separately whether they previewed or opened the message, clicked a link, opened an attachment, entered credentials, approved a multifactor prompt, or granted an application permission. A click alone does not establish that credentials were submitted or that an account was accessed.

Compare the user’s account with authentication logs for successful and failed sign-ins, unfamiliar locations or devices, unexpected MFA events, and activity shortly after the suspected interaction. Review interactive and non-interactive events where available; an absence of sign-in evidence does not prove that no credentials were entered, particularly if the phishing page collected them without immediately using them. Microsoft’s sign-in logs documentation explains the types of sign-in records and the activity they can help investigators examine.

Consider possible OAuth exposure as well as password exposure. If the user approved an unfamiliar application or permission request, identify the application, granted permissions, and affected account. Review the identity provider’s audit records and revoke suspicious consent or access using your organization’s process. Microsoft’s guidance on detecting and remediating illicit consent grants describes investigating and revoking suspicious OAuth grants.

Record the evidence behind each conclusion and its confidence. Do not ask users to send their password or token to the response team. If the evidence is incomplete, mark exposure as unknown and apply precautions proportionate to the potential impact.

How to investigate follow-on activity across logs

Build a timeline that begins before the earliest known message and continues after the last suspected interaction. Use a consistent time zone, note the source of every timestamp, and document any gaps in log coverage or retention. Correlate on multiple fields—such as user, device, IP address, application, URL, and time—rather than treating one identifier as conclusive.

Review identity provider authentication logs and audit logs for successful or unusual sign-ins, MFA changes, password resets, new devices, application consent, mailbox access, and changes to forwarding rules or account settings. Where available, include non-interactive sign-ins and token-related events. Microsoft’s identity log documentation describes sign-in and audit log categories and how they can support investigations.

Check email systems for related messages, forwarding, replies, and suspicious outbound mail. Search endpoint telemetry for visits to campaign URLs, downloaded files, browser activity, script execution, and other events around the user’s interaction. Endpoint detection and response data can help connect an email click to device activity; for example, Microsoft Defender for Endpoint’s investigation documentation describes device timelines and related event investigation.

Record queries, time ranges, systems checked, and findings on the case. Separate confirmed activity from plausible hypotheses, and preserve relevant records according to your organization’s evidence-handling and retention procedures.

How to contain and recover from a phishing incident

Choose containment actions based on the evidence and potential impact. Depending on the case, you may remove or quarantine delivered messages, block malicious indicators, disable or restrict an exposed account, reset its password, review MFA methods, and isolate a device when endpoint activity warrants it. Coordinate actions with the teams responsible for email, identity, endpoints, and business operations.

If credentials may have been exposed, take prompt steps to prevent further access. Identity provider session revocation can invalidate certain refresh tokens and force reauthentication, but it may not end every application session immediately. Microsoft notes that applications can issue their own session tokens and may need to revoke those sessions independently. Follow your identity provider and application-specific procedures, and verify that the response actually removed access where possible. See Microsoft’s guidance on revoking user access in Microsoft Entra ID.

If an unfamiliar app received access, perform OAuth token revocation or revoke the relevant consent and permissions as appropriate. A password change alone may not remove an app’s granted access. Confirm which accounts and resources were affected, and review for activity that occurred before revocation took effect.

After containment, remove malicious messages and artifacts, remediate affected devices, restore normal access safely, and monitor for renewed suspicious activity. Record each action’s owner, timestamp, result, and any limitations. Close the case only when defined criteria are met—for example, the known campaign is contained, impacted accounts and devices have been addressed, and residual risks have an owner.

How to review cases and measure response performance

Use the board to review both individual cases and recurring patterns. Check whether evidence was complete, the campaign scope was accurate, response actions were timely and effective, and communications reached the right people. Capture lessons such as detection gaps, unclear ownership, missing log sources, or process steps that delayed containment.

Choose a small set of metrics with clear definitions and consistent denominators. Useful measures include time from report to triage, time to confirm scope, time to contain, number of messages delivered and removed, number of affected users and devices, and the proportion of cases with confirmed interaction or account exposure. Segment results by severity or campaign type where that makes comparisons more meaningful.

Interpret metrics in context. A shorter time to close is not necessarily better if investigators closed cases before validating containment. Track reopened cases, missed recipients, or repeat activity alongside speed measures, and state how the clock starts and stops. NIST SP 800-61 Rev. 3 provides current incident-response recommendations that emphasize integrating response with cybersecurity risk management and improving response and recovery activities.

In summary, a useful phishing case board connects preserved evidence, campaign scope, user and account impact, investigation findings, containment actions, and measurable follow-up. Consistent fields and explicit uncertainty help your team respond efficiently without mistaking incomplete evidence for a confirmed conclusion.

FAQs

What information should a phishing case board record?

Record a case ID, report and discovery times, owner, status, severity, original message and full headers, recipients, URLs and attachment indicators, delivery trace findings, user interactions, affected accounts and devices, investigation sources and time ranges, containment actions, outcomes, and closure rationale. Link to approved evidence storage rather than placing passwords or active tokens on the board.

How do you determine whether a user submitted credentials?

Ask the user what they entered and when, then compare that account and time with available authentication logs, endpoint or proxy activity, and phishing-page or security-tool telemetry. A click or a sign-in record alone may not prove credential submission. Record the evidence and confidence level; if you cannot establish what happened, treat exposure as unknown and assess whether precautionary response is warranted.

When should sessions or tokens be revoked after a phishing incident?

Revoke sessions or tokens promptly when credentials, an active session, or an OAuth grant may have been exposed, following your organization’s incident procedures. Also address passwords, MFA methods, and suspicious application consent as appropriate. Revocation effects vary: identity-provider actions may not immediately invalidate tokens or sessions controlled by an individual application, so verify access where possible.

Which metrics help evaluate phishing incident response?

Track consistently defined measures such as time to triage, time to scope, time to containment, messages delivered and removed, users and devices affected, confirmed interaction or exposure rates, reopened cases, and recurring activity. Interpret speed alongside completeness and effectiveness; a rapid closure is not a successful response if containment or impact assessment remains uncertain.