What to Do After Clicking a Phishing Link at Work

Overview

Clicking a suspicious link is common because phishing messages are built to look routine, urgent, and familiar. The right response is not panic. It is fast containment, accurate reporting, and a clear handoff between the person who clicked and whoever manages endpoint protection for business systems.

Use this article as a checklist, not a script. Your environment may include Microsoft 365, Google Workspace, remote workers, DNS filtering, managed antivirus, EDR for small business, or a mix of tools. The sequence below stays useful across setups because it focuses on the basics: isolate risk, protect accounts, preserve evidence, and check for follow-on activity.

Before getting into scenarios, keep these rules in mind:

• Do not hide the click. Early reporting is often the difference between one risky event and a wider compromise.
• Do not keep exploring the site. Every extra action can expose more data or trigger more payloads.
• Do not assume nothing happened. A page can collect credentials, session cookies, MFA prompts, device data, or start a download.
• Do not assume the worst either. Many phishing incidents are contained quickly when the first responder acts methodically.

A simple way to classify the event is to ask four questions:

1. Did you only click, or did you also sign in?
2. Did you approve an MFA prompt or type a one-time code?
3. Did a file download or an installer run?
4. Was the device company-managed, personal, or a mobile device?

Those answers determine whether you are dealing with possible credential theft, malware protection software alerts, browser session risk, or endpoint compromise.

Checklist by scenario

This section breaks the response into practical cases. Start with the immediate actions that apply to almost everyone, then move to the scenario that matches what happened.

Immediate actions for any phishing link click

1. Stop interacting with the page. Close the browser tab. If a file is actively downloading or a script appears to be running, disconnect the device from the network first.
2. Report it right away. Use your company phishing report button, ticketing process, help desk channel, or security mailbox. Include the message source, time clicked, device used, and what you did after clicking.
3. Preserve basic evidence. Save the original email or message if possible. Take a screenshot of the page only if doing so does not require further interaction. Note the URL and any redirects you observed.
4. Do not forward the malicious message casually. Forwarding can spread risk. Follow your internal reporting method instead.
5. Watch for signs of follow-on activity. New browser prompts, unexpected login approvals, security warnings, changed inbox rules, or antivirus alerts all matter.

Scenario 1: You clicked the link but did not enter anything

If you clicked a phishing link at work but did not type a password, the situation may still involve browser-based tracking, fake sign-in prompts, drive-by download attempts, or session theft attempts. The checklist is shorter, but not optional.

1. Disconnect if anything downloaded or executed. If the page triggered a file, extension request, or installer, isolate the device from Wi-Fi or Ethernet and notify IT immediately.
2. Run your standard endpoint checks. Let IT trigger or review antivirus and EDR scans, browser protection events, and web filtering logs. If you are the admin, check whether your malware protection software recorded a blocked payload or suspicious child process.
3. Clear the risk path only after evidence is preserved. Depending on policy, IT may clear browser data, revoke session tokens, or reimage the machine if execution is suspected.
4. Check account activity anyway. Even without entered credentials, confirm there were no suspicious sign-in attempts following the click.

For deeper endpoint cleanup guidance, see How to Remove Malware from a Windows PC Without Making Things Worse.

Scenario 2: You entered your password on the phishing page

This is the most common and most urgent case in a what to do after phishing link workflow. Assume the password is compromised.

1. Change the password immediately from a known-clean device. Do not use the same browser session or potentially compromised endpoint if you can avoid it.
2. Revoke active sessions. Sign out of all sessions for the affected account, especially cloud email, VPN, identity provider, and collaboration tools.
3. Reset MFA if needed. If the attacker may have captured an OTP, prompt, or recovery method, review MFA enrollment and remove unknown devices or methods.
4. Check account recovery settings. Look for changed phone numbers, alternate emails, app passwords, or backup codes.
5. Review mailbox rules and forwarding. In business email compromise cases, attackers often add hidden forwarding rules, delete certain messages, or monitor replies.
6. Review recent sign-ins. Look for impossible travel, unusual IPs, failed login bursts, consent prompts, or app authorizations.
7. Escalate if privileged access was involved. If the account had admin rights, finance access, HR data access, or shared mailbox privileges, treat it as a higher-impact incident.

If your environment runs Microsoft 365, pair this with a review of anti-phishing controls and alerting. A useful companion is Email Security for Microsoft 365: Anti-Phishing Settings That Matter Most.

Scenario 3: You entered your password and approved MFA

This usually means the attacker may have obtained enough to access the account immediately, or close to it. The response should be treated as potentially active account takeover.

1. Force a password reset and session revocation immediately.
2. Reset MFA enrollment. Remove and re-register trusted devices, authenticator bindings, and phone methods according to policy.
3. Inspect sign-in history in detail. Focus on the time window around the phish. Look for cloud app access, token issuance, and conditional access bypass clues.
4. Review tenant-level changes if the user had elevated rights. New inbox rules, OAuth app consent, newly registered devices, and role assignments all matter.
5. Notify affected contacts if the mailbox sent suspicious messages. Attackers often use the compromised account to phish coworkers or vendors.

Scenario 4: A file downloaded or an installer ran

This shifts the incident from possible credential phishing to possible malware execution. At that point, the device becomes the priority.

1. Isolate the endpoint. Disconnect network access. If you are an admin using EDR for small business, use device isolation if your tooling supports it.
2. Do not start random cleanup steps. Ad hoc deletion can destroy forensic clues and make recovery harder.
3. Capture basic details. File name, download source, hashes if available, parent process, user path, and whether SmartScreen, antivirus, or browser controls raised alerts.
4. Run approved scans and triage. Check managed antivirus and EDR telemetry for execution, persistence, scheduled tasks, registry changes, and lateral movement attempts.
5. Decide between cleaning and reimaging. If there is credible evidence of execution beyond a blocked attempt, many teams prefer reimaging over partial trust restoration.
6. Reset credentials used on that device. If malware may have harvested browser-stored passwords or tokens, expand the response beyond the single account.

Small teams comparing controls often find that antivirus alone is not enough for these cases. Network controls help too. See DNS Filtering vs Antivirus: Which Stops More Small Business Threats? and Phishing Link Checker Tools Compared for IT and Security Teams.

Scenario 5: The click happened on a phone or unmanaged personal device

Remote work and BYOD make phishing incident response less tidy. The main goal is still to protect company accounts and prevent spread into managed systems.

1. Change the affected work account password from a trusted device.
2. Revoke sessions and review recent sign-ins.
3. Remove suspicious browser tabs, profiles, or downloaded files.
4. Do not reconnect that device to company apps until IT advises.
5. Document the device type, OS, browser, and app involved. Those details help analysts scope exposure.

Scenario 6: You are the admin responding to a user report

If you manage security or IT, your checklist should go beyond the single user.

1. Triage the report quickly. Confirm the message source, recipient count, click history if available, and whether anyone submitted credentials.
2. Search for related messages. Purge or quarantine lookalike emails or chat messages across the environment if your platform supports it.
3. Review controls that should have caught it. Email security, browser isolation, DNS filtering for small business, safe links, and endpoint web protection logs can show where the gap occurred.
4. Scope blast radius. Identify additional recipients, repeated domains, same-day credential resets, impossible-travel logins, or new OAuth grants.
5. Contain affected accounts and endpoints. Session revocation, forced reset, MFA re-registration, host isolation, and scan or reimage decisions should follow your normal incident workflow.
6. Document the chain. Record timeline, user actions, detections, containment steps, and lessons learned for future playbooks.

If phishing remains a recurring issue, it is usually worth reviewing adjacent defenses such as browser protections, delivery method trends, and rollout consistency across devices. Related reads include Most Common Malware Delivery Methods to Watch This Year and How to Roll Out Antivirus to a Small Business Without Disrupting Users.

What to double-check

Once the urgent response is done, slow down and verify the details that often get missed. These checks are where many teams discover that an apparently simple phishing click was actually a broader account or endpoint issue.

• Inbox rules and forwarding: Look for auto-forwarding, delete-and-hide behavior, and rules targeting invoices, wire transfers, HR, or password resets.
• OAuth and app consent: A fake sign-in may really be a consent phishing page. Review connected apps and revoke anything unfamiliar.
• Session persistence: Changing the password is not always enough if sessions remain active. Confirm token revocation where possible.
• Saved browser credentials: If malware execution is possible, assume browser-stored secrets may be exposed.
• Shared accounts and delegated access: Mailboxes, support platforms, finance tools, CRM systems, and password vaults may need review too.
• Security alerts around the same time: Correlate mailbox alerts, endpoint alerts, identity alerts, and DNS or proxy logs.
• Secondary targeting: Check whether the compromised user sent suspicious messages to coworkers, customers, or suppliers.
• Device trust: If there is real uncertainty about malware execution, reimage rather than trying to salvage confidence.

For Windows-centric fleets, it also helps to confirm your baseline deployment and policy coverage. If endpoint controls are inconsistent, phishing recovery becomes slower and less certain. See How to Deploy Antivirus to Windows Devices with Microsoft Intune.

Common mistakes

The purpose of a checklist is to reduce avoidable errors under stress. These are the mistakes that repeatedly complicate malicious link recovery.

• Waiting too long to report. Users often spend valuable time trying to decide whether the click was “really bad enough” to mention.
• Changing the password on the same suspicious device. If the endpoint is compromised, the new credentials may be exposed immediately.
• Only changing the password. Session revocation, MFA review, mailbox inspection, and app consent checks are just as important.
• Assuming antivirus clean means incident over. Antivirus review is important, but phishing often targets identity, not just malware delivery.
• Deleting the email before preserving details. Basic evidence helps determine scope and block similar lures.
• Ignoring mobile devices. A phishing click on a phone can still expose business accounts and cloud access.
• Focusing only on the victim user. The same message may have reached dozens of coworkers or external contacts.
• Overcomplicating the first response. Containment and reporting come first; long analysis comes after the situation is stable.

Another common trap is treating every phishing event as purely technical. Users need a short, blame-free route to report mistakes. If reporting feels punitive, incidents stay hidden longer.

It is also worth remembering that phishing evolves. Today it might be a fake Microsoft 365 prompt, a QR code phishing scam, a malicious document, or a fake antivirus scare page. The recovery logic stays similar even when the lure changes. For adjacent examples, see QR Code Phishing Scams: How to Spot, Block, and Respond and Fake Antivirus Scams: Warning Signs, Removal Steps, and Prevention.

When to revisit

This checklist should be reviewed before seasonal planning cycles and any time your workflow or tooling changes. A phishing response plan gets stale quickly when login flows, endpoint controls, or reporting channels move.

Revisit and update this process when any of the following happen:

• You change email or identity platforms. Password reset, session revocation, and sign-in review steps may differ.
• You deploy new endpoint protection. Best antivirus software and EDR tooling change the evidence you can collect and the actions you can automate.
• You add remote workers or BYOD users. Mobile and unmanaged-device response steps need to be explicit.
• You adopt DNS filtering, safe browsing controls, or browser extensions. Blocking and logging paths should be reflected in the playbook.
• You see a new phishing pattern. QR lures, shared-document scams, MFA fatigue, and consent phishing each expose different weak points.
• You had a real incident. Every event should feed a better checklist, not just a closed ticket.

For a practical next step, turn this article into a one-page internal runbook:

1. Create two versions: one for employees and one for admins.
2. List your actual report channel, help desk contact, and after-hours escalation path.
3. Document where to review sign-ins, revoke sessions, and check mailbox rules in your environment.
4. Decide in advance when a device should be scanned, isolated, or reimaged.
5. Test the process during tabletop reviews, especially for remote workers.

If your team is still building the surrounding controls, focus on the basics first: strong email filtering, consistent endpoint coverage, clear reporting, and fast credential reset workflows. The goal is not to eliminate every phishing click. It is to make one click easier to contain than to exploit.