Protect · Playbooks · At work

Someone at work clicked a phishing link

Last updated 2026-10-14 · Written with AI assistance, reviewed by a person

This happens everywhere, including at companies with large security teams. The person who reports it fast is doing exactly the right thing, so start by thanking them. A click on its own rarely causes harm. What matters is what happened next: a typed password, an approved prompt or an opened file each needs a different response. This playbook helps you work out which, then deal with it.

Who does what. The person who clicked takes the first steps. The owner keeps things moving and makes the business calls. Whoever runs IT (a staff member, your IT provider or you) makes the account and device changes further down. Only make changes you're authorized to make, and follow your provider's current instructions where they differ from ours.

Do this now

For the person who clicked:

1. Stop. Don't type anything else, approve another prompt, call a number on the page or follow its instructions to "fix" your computer. Close the tab. Don't reopen it to check.
2. Tell IT straight away, by a phone number you already know or another channel you trust. If you typed your password, don't use that email account to report it. No IT support? Tell the owner.
3. Say exactly what you did. Did you type or autofill anything, approve a sign-in, enter a code, download or open a file, install something, paste a command or let an app have access? Mention anything you're unsure about too. A page can capture what you type even if you never press Submit.
4. Ran something, or the computer's acting oddly? Disconnect it. Turn off Wi-Fi, then unplug the network cable. Stop using it, but leave it switched on so IT can look. Don't reboot, wipe it or run a cleanup tool. Only if files are being scrambled right now and you can't disconnect it, turn it off.
5. Keep the evidence. Leave the message where it is. Note the time, the device, the account. Don't delete downloads or clear your history: IT can deal with them safely.

For whoever takes the report: thank them, then get the facts without blame. People who get blamed stop reporting, and late reports are the expensive ones.

Which path?

Follow every row that applies. If money was sent, call the bank now (Path E) while IT gets on with the rest.

Get outside help now if an administrator account is involved, malware ran, several people or systems are affected, money was sent, or you can't contain it. A click with nothing else can stay with routine IT unless the evidence says otherwise.

On a phone or a personal device? Find out which device it actually was, then involve its owner. Don't erase a personal device without the owner's permission.

Path A: Only opened the page

Whoever runs IT:

• Make sure it really was "opened only". Phishing pages usually look like a routine Microsoft or Google sign-in, or a "verify it's you" screen, so people forget they saw one. Ask specifically: did a sign-in page appear? Did the browser or password manager fill anything in? Did a sign-in approval or number-matching prompt reach their phone around then? Typing without pressing the button still counts. Any yes means Path B.
• Check the sign-in logs for that user around the time of the click: successful sign-ins, sign-ins interrupted at the two-step stage, new devices or unfamiliar locations. Anything unexplained means Path B, whatever the person remembers.
• Ask about notification requests plus automatic downloads. If they allowed the site to send notifications, remove that permission in the browser's settings, without visiting the page again. A notification pretending to be antivirus doesn't mean antivirus found anything.
• Check without revisiting the link. Look at browser and download history plus security alerts. If anything downloaded, go to Path D.
• Make sure endpoint protection is running (the security software on the device), then run a scan. Check the browser and operating system are up to date.
• Decide. If everything supports "opened only" with nothing suspicious, record what you checked, then let them get back to work. Don't call the device "proven clean" just because a scan found nothing. If you can't see enough to be sure, write that down, then decide whether your provider should take a look.

Path B: A password or sign-in was exposed

Treat the account as compromised. Work from a separate, trusted device. A password reset alone isn't enough. Modern phishing kits often steal the signed-in session itself (the already-signed-in connection), which keeps working after a password change until you revoke it. Two-step sign-in doesn't stop that: only revoking sessions does.

If IT can't be reached, the person who clicked should open the service from a bookmark or by typing its address, change the password, then use its "sign out everywhere" option. Change the same password anywhere else it was used. Keep trying to reach IT: they still need to investigate.

Microsoft 365

Follow Microsoft's compromised account procedure from a trusted admin session:

1. Block sign-in, then revoke sessions for the user.
2. Reset the password where the account lives. If it's synced from an on-premises directory, reset it there.
3. Check authentication methods. Remove any phone, app or key the attacker added. Review app passwords, app consents, admin roles.
4. Check the mailbox for forwarding, inbox rules (including hidden ones), delegates. Record each malicious change, then remove it.
5. Review sign-in logs, the audit log, sent mail to work out what happened.
6. Restore access once it's clean, sending the new credentials through a trusted channel.

Google Workspace

Follow Google's compromised account checklist:

1. Suspend the user. Suspension resets their sign-in cookies plus OAuth tokens.
2. Investigate account, email, OAuth activity in the audit logs.
3. Reset the password, revoke OAuth tokens, then remove app passwords.
4. Check recovery details, two-step verification, Gmail filters, forwarding.
5. Unsuspend only once it's clean. Make sure two-step verification belongs to the employee.

Either platform

• Revocation can lag. Apps connected through single sign-on (Slack, Zoom, your CRM) may keep their own sessions. Check the important ones separately. [3]
• Typed a code into a "device sign-in" page? Attackers use Microsoft's or Google's real device sign-in pages to collect tokens. Revoke sessions as above. If your business doesn't use device code sign-in, block it with Conditional Access. [9]
• An administrator account? Escalate now, then check for changes affecting other users. Don't delete the account as a shortcut: you'll lose the evidence.

Path C: An app was given access

Someone can hand an attacker access through a real Microsoft or Google permission screen, without ever typing a password.

Whoever runs IT:

1. Record the app: its name, ID, permissions, who approved it, when.
2. Block it, then remove its permission grants. Revoke related sessions or refresh tokens. Existing access tokens can stay valid until they expire. Resetting the user's password does not revoke an app's own access. Check application permissions as well as delegated ones. [8]
3. Work out what it could reach, then what it actually did. Check whether anyone else approved it.
4. Credentials exposed too? Follow Path B as well. Organization-wide or admin consent means escalate straight away.

Done when the grant is removed, revocation is recorded, the app can't be approved again, someone is watching for activity until the remaining tokens expire. A quiet log on its own doesn't prove every token is dead.

Path D: A file downloaded or something ran

Downloaded only

Don't open the file to see what it is. IT should record its name and location, confirm it never ran, then let endpoint protection quarantine it. If you can't rule out that it ran, use the next section.

Opened or ran something

Keep the device isolated. If your endpoint protection can isolate it remotely, use that: IT keeps access to investigate while everything else is cut off.

• Record what ran, when. Preserve alerts plus device evidence before any cleanup.
• Assume saved passwords are stolen. A lot of malware today is "infostealers": it copies passwords saved in the browser, plus signed-in sessions. From a clean device, reset those passwords, then revoke sessions on the accounts involved.
• Pasted a command from a fake "verify you're human" page? Treat that exactly like running a malicious file.
• Get your IT provider or an incident responder to decide whether to rebuild the device from a trusted source. A clean antivirus scan isn't enough to close a case where malware ran.
• Don't reconnect it just because the pop-up went away. Whoever leads the recovery should write down why it's safe to return to service.

Escalate now for remote access by a stranger, credential-stealing malware, anything run with admin rights, files being encrypted, or signs other devices are affected.

Path E: Information or money was shared

The owner:

• Money sent? Call the bank's fraud team now, on a verified number. Ask whether the transfer can be recalled or frozen. Then report it at IC3. Our We paid a fake invoice playbook has the full routine.
• Payment details exposed? Ask the bank how to protect the account. Pause any payment or bank-detail change that came from the same conversation, then confirm it with the real vendor on a number you already had.
• Business or personal information exposed? Record exactly what was shared, who it's about, how it was sent. Bring in your incident, insurance or legal contact to assess what you may need to tell customers or regulators.

Keep going with the account or device response: a stopped payment doesn't fix a compromised mailbox.

Before the end of the day

Whoever runs IT:

• Preserve the original message with its headers, plus the relevant logs, before they age out. Don't hold up containment for perfect evidence.
• Find everyone else who got it. Search mail logs for the same sender, subject or link (Microsoft: Threat Explorer or content search; Google: the security investigation tool). Once you've kept a copy, remove the confirmed malicious messages from inboxes. [6]
• Repeat the right path for anyone else who clicked.
• Warn your team with the subject line, the claimed sender, the action it asked for. Never forward the link or the attachment.
• Block narrowly. Block the malicious domain in your DNS filter (our guide to free DNS filtering shows how), not a whole service like Google Drive or SharePoint because one file there was bad.
• Look beyond email. Check file storage plus business apps for activity. Missing logs mean the impact is unknown, not that nothing happened.

The owner: name one person to lead, then set a time for the next update. For a likely compromise, call your IT provider, plus your cyber insurer's incident line if you have one. If company email might be watched, use phones. If your only admin account is affected, call the platform's business support straight away.

Don't upload confidential messages, attachments or links with sign-in tokens in them to public scanning sites.

When can we close this?

Tick the items that apply to the paths you took. Mark the rest "not applicable", with a reason.

• We recorded what happened, who was affected, what's still uncertain.
• Exposed accounts are secured, unauthorized access removed, legitimate access tested.
• Affected devices have a written return-to-service decision.
• Other recipients plus downstream effects were checked, as far as the evidence allows.
• Payments, data exposure, notification questions each have an owner.
• The evidence with a timeline is stored somewhere access-controlled.
• Someone owns follow-up monitoring, plus anything unresolved.

Follow up on account alerts the next business day, then again within a week. If the compromise was confirmed, agree a longer watch with your responder. Those are check-in points, not proof that it's over.

Keep a simple record

One page is enough. Never put passwords, recovery codes or session tokens in it.

If customers' or employees' personal information might be involved, start a short log of possible notification duties too: who might need telling, by when, under which rule. Let your adviser decide which rules apply, but don't wait for the full investigation to start the list.

Make a repeat less likely

Pick improvements that match what happened:

• Phishing-resistant sign-in (passkeys or security keys) for the exposed accounts first, then every admin.
• Stop users approving risky apps on their own. Allow only verified publishers or low-risk permissions, with an admin approval route for the rest. [10] [11]
• Block device code sign-in if you don't use it. [9]
• A DNS filter that blocks known phishing sites for every device. Ours is free: How to block.
• An obvious report button, plus a thank-you every time someone uses it.
• Call-back checks on any payment change, whatever the email says.

Sources

Checked October 14, 2026. Admin menus, logs and features vary by product or subscription. This playbook follows the incident response approach in NIST SP 800-61 Rev. 3. It's a careful, documentation-based guide, not a certification. It hasn't yet been exercised in a live environment.

1. Microsoft: Respond to a compromised email account
2. Google Workspace: Identify and secure compromised accounts
3. Microsoft Entra: Revoke user access in an emergency
4. CISA: StopRansomware Guide
5. FBI IC3: Business email compromise
6. Microsoft: Phishing investigation playbook
7. Microsoft: Manage website notifications in Edge
8. Microsoft Entra: Review application permissions
9. Microsoft Entra: Conditional Access authentication flows
10. Microsoft Entra: Configure user consent
11. Google Workspace: Control which apps access your data
12. Microsoft: Token theft playbook

Related playbooks

• A work email account was hacked
• We paid a fake invoice
• Our files are locked, or there's a ransom note