Should I tell the user immediately, or investigate first?

Tell them immediately, but with the right framing. The user's clock matters: if their session is being actively used by an attacker, every minute they're not aware is a minute they aren't doing things like checking for unauthorized mailbox forwarding or watching for impersonation messages going to colleagues. Lead with what's been done (password reset, session revoke), what they should do next (verify their actual account works, check their sent folder) and the key cultural signal - they aren't in trouble. Reporting cultures collapse when the first reaction is punitive.

Do I have to invalidate the session even if they only clicked the link and didn't enter anything?

Best practice is yes - revoke the active sessions even on link-only clicks, because the trade-off is asymmetric. Cost of revocation: user signs back in once. Cost of not revoking when an AiTM reverse-proxy or session-cookie-stealing payload was actually delivered: full account takeover. Modern phishing kits commonly use redirect chains that drop session-stealing JavaScript even on link-only visits. Revoke first, investigate second.

What if it was an executive who clicked?

Same runbook, additional escalation. Executive accounts often have privileged access to financial systems, board materials and other high-value resources, so the containment urgency is higher and the investigation should explicitly check for OAuth consent grants and mailbox-rule creation (common BEC pre-positioning). On the people side: do not handle the executive call differently than other users from a blame perspective. The behavioral-conditioning research is unambiguous - punishing executives for clicking creates an organizational signal that reinforces non-reporting culture, which is the actual long-term risk.

What if multiple users clicked the same lure?

Treat it as a campaign-level event, not individual incidents. Identify the full recipient list from the email gateway, classify each user by whether they clicked / entered credentials / opened attachments and run the appropriate per-user containment in parallel. The post-incident analysis matters more here because the data tells you something about the lure's effectiveness - what subject line, sender pattern and content got through gateway and got past the trained workforce. Feed that data into next quarter's simulation cadence so the same lure pattern is exercised under controlled conditions.

Should we contact law enforcement or report to the FBI/IC3?

Depends on severity, sector and regulatory obligations. Pure link-only clicks rarely cross the threshold. Confirmed credential or MFA-code theft, lateral movement evidence or financial-impact events (BEC wire fraud, ransomware) generally do - IC3.gov is the U.S. consumer/business filing portal; sector-specific obligations exist for healthcare (HHS / OCR), financial services (FinCEN, applicable state regulators), defense contractors (DC3 / DCISA), public companies (SEC 8-K disclosure under the 2023 cybersecurity rule). Have your legal and compliance counsel pre-mapped to these triggers; the runbook should know who to call before the incident arrives.

How do we prevent this happening again?

The post-incident phase is where the long-term value of the response lives. Three things compound: (1) update the simulation program to include a controlled version of the lure so the workforce is rehearsed against the exact pattern that got through; (2) close the gateway gap that let the lure land - most enterprise email gateways have feedback channels for misclassified messages; (3) review the technical controls that should have caught the post-click behavior (MFA strength, session-binding, OAuth consent restrictions, EDR coverage). The single click is a data point. The program response is what determines whether the next 100 similar lures land or bounce.

An Employee Clicked a Phishing Link - What To Do in the First 60 Minutes

The call (or Slack, or self-report) lands and the question becomes immediate: what now. The good news is that the first 60 minutes have a defined ordering. The bad news is that most organizations rediscover that ordering during the incident itself, which costs time. This post is the runbook to have already written down: triage, contain, communicate, follow up.

The framing matters. A phishing click is a data point about an organizational system, not an individual character flaw. Punitive responses produce one good measurable outcome - fewer reported clicks - by creating fewer reported clicks, not fewer actual ones. The runbook below assumes a non-punitive culture is the goal; the literature on incident-reporting behavior is unambiguous on why.

Step 1: Confirm and capture (minutes 0-5)

Get four pieces of data immediately: the user's account, the URL they clicked, the timestamp and a screenshot of the original message. Do not delete the original email - you need it for gateway tuning, recipient-list extraction and the next campaign's simulation template. If the user already deleted it, recover from journaling / retention policies before doing anything else; once it's gone from journaling it's gone.

Step 2: Triage by what was clicked

Severity bucketing is the most useful thing you can do in minute 5. Four tiers, each with a different containment urgency:

Link-only click - user clicked, landed on a page, didn't interact further. Lowest tier, but still warrants session revocation because of session-stealing JavaScript and AiTM redirect-chain risk.
Credentials entered - user typed username/password into the lure page. Account is presumed compromised; treat all subsequent activity as untrusted.
MFA code entered - user entered the 6-digit code, push-approved or signed in via the lure-hosted flow. Assume AiTM session theft; this is the highest urgency tier.
Attachment opened - separate runbook with EDR scan + persistence-mechanism check; the credential tiers don't apply but a payload may have run.

Step 3: Contain the identity (minutes 5-15)

For the credential and MFA-code tiers, the absolute first action is identity containment. The order matters: revoke sessions then reset password. Resetting first without revoking can leave the attacker's existing session active.

M365 / Entra ID: in the Entra portal, revoke sessions on the user object, then reset password. PowerShell equivalent: Revoke-AzureADUserAllRefreshToken -ObjectId <user>.
Google Workspace: in admin console, sign out the user from all sessions, then reset password.
Federated identity (Okta, Ping, etc.): invalidate the user's active sessions in the IdP, then reset.
VPN / remote access: terminate active VPN sessions if present.
SaaS apps with independent session lifetime: if the user has direct logins to apps that don't immediately respect IdP revocation, individually revoke those (typical examples: GitHub, Slack, AWS console with long-lived credentials).

For the link-only tier, do the session revoke anyway. Trade-off is asymmetric: cost of revoke is one re-login; cost of not revoking when an AiTM kit was actually delivered is full account takeover.

Step 4: Investigate authentication and tenant telemetry (minutes 15-30)

Pull sign-in logs for the user from the click time forward. Look for:

Sign-ins from unfamiliar IPs, foreign countries or anomalous device fingerprints.
New OAuth consent grants - particularly to apps the user wouldn't normally interact with. Consent-grant phishing bypasses MFA and is a common BEC pre-position.
New mailbox forwarding rules, especially to external addresses or with sender-search filters that look for "wire," "invoice," "payment," "bank."
New device registrations / MFA enrollments - attackers commonly register their own MFA method to maintain persistence after the user resets.
Suspicious activity in connected services - file shares, Teams/Slack messages sent, calendar invites created.

If MFA codes were entered, expand the search window - attackers may have logged in earlier and waited. A 30-day backward look is reasonable for the credential and MFA-code tiers.

Step 5: Search for other affected users (minutes 20-35)

Phishing rarely targets one mailbox in isolation. Pull the lure email's recipient list from your email gateway. Classify each recipient: did they receive it, did they click, did they enter credentials, did they open attachments. Run the per-user runbook in parallel for everyone in the credential or MFA tiers.

If the campaign hit a meaningful percentage of the workforce, this becomes a campaign-level event with a different communication pattern (Step 6) and a different reporting requirement (Step 8).

Step 6: Communicate (minutes 30-45)

Three audiences, three messages:

The user: lead with what's been done. "We've reset your password and revoked active sessions; you'll need to sign back in. You're not in trouble - phishing simulations are how we calibrate our defenses, and a real phishing email is what we're trying to defend against." If they entered credentials or MFA codes, ask them to verify their account works and walk them through checking their Sent folder for impersonation messages.
IT / security on-call: full incident notification with severity tier, containment status and any anomalies surfaced in Step 4.
Leadership: only when severity warrants. Link-only clicks rarely need an executive call. Credential or MFA-code events with confirmed lateral movement, financial impact or other-affected-user-spread reach the threshold. The "leadership briefing" is calmer when it follows containment than when it precedes it.

Step 7: Endpoint and persistence check (minutes 45-55)

For attachment-opened tiers, run an EDR scan on the endpoint and check for new persistence mechanisms:

Scheduled tasks created in the last 24 hours.
Registry run keys (HKLM\Software\Microsoft\Windows\CurrentVersion\Run, the user-hive equivalents).
New autostart services or driver loads.
Browser extensions installed in the same window.
Outbound connections to unfamiliar domains in network logs.

Absence of antivirus alerts is not exoneration. Modern ransomware operators pre-test against the most-deployed EDRs before launching; living-off-the-land binaries (cmd, powershell, certutil, mshta) often bypass signature detection. Treat the endpoint as untrusted until forensic examination clears it; if the tier is high and the workload critical, reimage rather than spend two days investigating.

Step 8: Tune and follow up (the next 60+ minutes, and the next quarter)

The phishing-click runbook is most valuable in what happens after the immediate containment:

Push the lure to the gateway blocklist - domain, sender pattern, subject hash. Submit to your gateway vendor's misclassification feedback channel; that improves the gateway's classifier for everyone.
Update the simulation program - recreate the lure as a controlled simulation template. The workforce that just got hit by a real version of this lure will be measurably more responsive when they see it again under controlled conditions. Auto-assigned remediation training ensures the next click triggers immediate behavior-conditioning.
Review the technical control gaps - was MFA in place? Was it phishing-resistant (FIDO2/passkeys) or phishable (SMS, push approval, TOTP)? Were OAuth consent grants restricted? Did the EDR fire? Each gap is a budget conversation for the next renewal cycle.
Reporting - sector-specific obligations (HHS/OCR, FinCEN, SEC 8-K under the 2023 cybersecurity disclosure rule, applicable state regulators) may require formal notification. Have these triggers pre-mapped before the incident.
Insurance - confirmed credential events with material-impact thresholds may trigger cyber-insurance notification obligations. Check the policy's notification window. The cyber-insurer renewal walkthrough covers what underwriters typically look for at renewal after a confirmed incident.

The reporting culture matters more than the runbook

Organizations that handle phishing clicks well share a single trait: people report. The runbook is the second-most-important thing. The most important is that an employee who clicks something they shouldn't have feels safe enough to report it within minutes rather than hide it for hours. Every minute of delay is a minute of unconstrained attacker activity. The single best ROI investment in incident response is removing the friction (and fear) that stops users from reporting.

Where Bait & Phish fits

Bait & Phish is a phishing simulation and security awareness platform - not an incident-response tool. The connection to this runbook is the prevention side: continuous simulation reduces the input volume to every step above. The metrics that matter to leadership include click rate (how often Step 1 fires) and time-to-report (how often the runbook starts within minutes vs hours). Start a free trial up to 25 users or talk to us about a program that emphasizes reporting culture as a measurable program output.

This post is informational and does not constitute incident-response, insurance or legal advice. Specific containment, regulatory-notification and legal decisions are organization-specific - consult your security team, legal counsel or incident-response retainer for tailored guidance.

See also: Ransomware Phishing for the post-click attack chain that the runbook is trying to interrupt; Phishing Trends 2026 for the broader threat-landscape context.

22apr