What to do if an employee falls for phishing: a step-by-step response guide

By Kike Gandia · Co-Founder & CEO, OSCP

If an employee has fallen for phishing, the first thing is for them to report it right away, without fear of blame, and the second is to contain it: reset their password, revoke open sessions and, if they ran a file, disconnect the device from the network without switching it off. If they also made a payment, calling the bank comes before everything else. The rest of the response depends on exactly what they did, because opening an email is not the same as typing a password into a fake site or approving an MFA prompt. This guide orders the steps by urgency, from the first minute to mandatory notifications and lessons learned.

Step 1: get the employee to report it now, without fear of blame

What changes the outcome of a phishing incident most is not the mistake itself, but how long it takes for someone to find out. With stolen credentials, an attacker can get into the mailbox, create rules to hide their activity and start writing to clients and suppliers very quickly. If the employee waits a day to say anything out of embarrassment, containment comes too late.

That is why the message to staff, and the one worth repeating in every training session, is simple: if you think you have fallen for it, report it now, even if you are not sure. Whoever reports quickly has done the right thing. If the company's response is to look for someone to blame, next time nobody will report, and that silence costs far more than any click.

When the report comes in, gather straight away:

Exactly what they did: opened the email, clicked, typed their password, approved an MFA prompt, downloaded or ran a file, transferred money or gave access to their computer.
When: the approximate time narrows down which logs to review.
From which device: company laptop, personal phone or home computer.
The original email: they should not delete it. You will need it to find it in other mailboxes, extract the link and sender and, where relevant, send it to the national CERT with its full headers.

Also ask them not to try to fix it themselves —deleting emails or files, restarting the computer, uninstalling programs— until whoever is handling the incident tells them to.

Step 2: work out what they did and what to do first in each case

Not all phishing incidents are equally serious. What the employee did decides where to start:

What the employee did	Severity	What to do first
Only opened the email	Low	Report it without deleting it and find the other recipients (step 6)
Clicked the link without typing anything	Low to medium	Note the URL, block it and check whether any file was downloaded
Entered their username and password	High	Reset the password and revoke sessions immediately (step 3)
Approved an MFA prompt or typed the code into the fake site	Very high	Treat the account as taken over: revoke sessions and tokens, review MFA methods and mailbox rules (step 3)
Granted permissions to an app	High	Revoke that app's consent and tokens (step 3)
Downloaded and ran an attachment	Very high	Isolate the device from the network without switching it off (step 4)
Gave someone remote access over the phone	Very high	Isolate the device and treat it as an intrusion (step 4)
Made a transfer or changed bank details	Critical	Call the bank before anything else and report it to the police (step 5)

Two caveats. Opening an email in an up-to-date client rarely compromises the device on its own, although if images loaded the attacker may learn that the mailbox is active. And if the employee does not remember clearly what they did, act as if they typed their password: resetting it and revoking sessions costs little compared with underreacting.

If several situations apply at once, start with the most serious. A transfer that has already gone out will not wait for you to finish reviewing the mailbox.

Step 3: cut off access to the account: password, sessions, MFA and persistence

Resetting the password is necessary, but not enough. In adversary-in-the-middle (AiTM) attacks, the fake site relays traffic to the real page: the employee types their password and MFA code, the sign-in works and the attacker keeps the session cookie. With it they get in without needing the password or the second factor, and the session stays alive even after the password changes. Microsoft says so explicitly in its analysis of these campaigns: session cookies must be revoked in addition to resetting the password.

In the first hour:

Reset the password and, if the account is clearly compromised, temporarily block sign-in while you investigate.
Revoke all sessions and tokens. In Microsoft Entra ID, with the user's revoke sessions option or the Revoke-MgUserSignInSession cmdlet. In Google Workspace, by resetting the user's sign-in cookies from the Admin console; suspending the account also resets them, along with its OAuth tokens.
Review registered MFA methods. With the session open, the attacker can add their own phone or authenticator app to come back whenever they like. Remove any method the employee does not recognise.
Remove app passwords and review apps with OAuth consent: an authorised malicious app keeps reading email even after the password changes.
Review inbox rules and forwarding. A rule that moves or deletes messages containing invoice, payment or transfer, or that forwards copies to an external address, is the classic signature of fraud in preparation. Also review delegations and mailbox permissions.
Review the devices registered or syncing with the account and remove any that are not the employee's.

Then check the sign-in logs for the IPs and countries used, and the sent items for any messages the attacker sent from the account to clients, suppliers or colleagues. If they did, those people need to be warned. The guides linked at the end explain how to find forwarding rules in Exchange and Gmail and how to audit OAuth consents.

Step 4: if something ran or remote access was given, isolate the device without switching it off

If the employee opened an attachment that ran something —a macro, an archive with an executable, a shortcut file— or let someone into their computer after a call from a fake IT support agent, the problem is no longer just the account: assume the device is compromised.

Disconnect it from the network, but do not switch it off. Unplug the cable and turn off Wi-Fi, or use your EDR's network isolation if you have one, which keeps the device reachable for analysis. Switching it off wipes memory, where the malicious process, active connections and data that only exist while the machine is running may be.
Do not reinstall it yet. Wiping it straight away destroys the evidence of what ran, what was taken and whether the attacker moved to other machines.
From a clean device, change the passwords of every account used on that machine, not just email: infostealer malware usually takes the passwords saved in the browser too.
Look for the same indicators on other devices: the file name, its hash or the domain it connects to.

If remote access was given over the phone, identify which tool was installed (AnyDesk, TeamViewer, Windows Quick Assist or another), document the session before uninstalling it and treat it as an intrusion: while the employee watched the screen, the attacker could have installed something else or copied files.

Step 5: if money was transferred, call the bank and report it to the police

If the phishing ended in a payment —an invoice with changed bank details, an urgent transfer requested by a fake executive— calling the bank comes ahead of any other task. The sooner your bank knows, the better the chances that it can ask the receiving bank to freeze or return the funds before they leave the account.

Recovery is not guaranteed. If the transfer was instant, the money arrives in seconds, and once credited, getting it back depends on whether it is still in the destination account and on the cooperation of the bank that received it. That is why every minute counts.

Have this ready when you call:

Date, time and amount of each payment order.
Destination IBAN and account holder, and the transaction reference.
The email or message that prompted the payment.

Then file a police report with all the documentation; the bank and the insurer will ask for it. Also warn the real supplier or client whose identity was used: their email may be compromised and other customers of theirs may be receiving the same scam. CEO fraud and supplier impersonation have their own guide, linked at the end.

Step 6: find the same email in other mailboxes and delete it

A phishing email rarely reaches just one person. While someone contains the affected account, someone else should find the other recipients:

Locate every copy by sender, subject or link. In Microsoft 365, with Threat Explorer in Defender for Office 365 (Plan 2) or with a Microsoft Purview content search and its purge action. In Google Workspace, with the security investigation tool, available depending on your edition.
Remove them from every mailbox before someone else clicks, and check who else opened the message or visited the link: each of those people goes back to step 2.
Block the sender, the domain and the URL in your email filter, proxy or DNS.
Warn staff with a screenshot of the email. A short, specific alert along the lines of 'if you got this, do not open it and tell us' works better than a generic reminder about phishing.

If the email impersonated a brand, a bank or a public body, reporting it helps get the fake site taken down. In Spain, for fraud cases, INCIBE-CERT asks for the suspicious email with its headers and attachments.

Step 7: assess whether there is a personal data breach and who to notify

A phishing incident with stolen credentials is very often also a personal data breach: an employee's mailbox contains data about clients, suppliers and colleagues. The breach notification guide from the Spanish Data Protection Agency (AEPD) lists phishing with account compromise among the cyber incidents that can amount to one. The main obligations under the GDPR:

Notifying the supervisory authority (GDPR Article 33): without undue delay and at the latest within 72 hours of becoming aware that the incident affected personal data, counting weekends and public holidays. It is not required if the breach is unlikely to result in a risk to people. In Spain it is filed through the breach channel of the AEPD's online portal and, if you do not have all the information within 72 hours, you can send an initial notification and complete it later.
Informing the people affected (GDPR Article 34): when the breach is likely to result in a high risk to their rights and freedoms, without undue delay and in clear language.
Internal record: the GDPR requires every breach to be documented, whether notified or not, with the facts, its effects and the measures taken.

In Spain, the AEPD offers two free tools for these decisions: Asesora Brecha, to assess whether notification is needed, and Comunica-Brecha RGPD, to assess whether the people affected must be informed.

Depending on who you are, there may be other obligations:

NIS2: the directive requires essential and important entities to send an early warning within 24 hours, an incident notification within 72 hours and a final report within one month for significant incidents. In Spain, the transposing law (the Cybersecurity Coordination and Governance Act) was approved as a draft bill in January 2025, but as of October 2026 it has not been published in the BOE, Spain's Official State Gazette, and the European Commission referred Spain to the Court of Justice of the EU in July 2026. Meanwhile, organisations already within the scope of Royal Decree-Law 12/2018 must still notify their reference CSIRT of incidents with significant disruptive effects.
ENS (Spain's National Security Framework): public sector bodies notify the National Cryptologic Centre (CCN) of incidents with significant impact, and private companies providing services to them notify INCIBE-CERT, which informs CCN-CERT (Article 33 of Royal Decree 311/2022).

Step 8: get help and notify your insurer

If you do not have your own security team, you do not have to handle it alone:

017, INCIBE's cybersecurity helpline in Spain: a free, confidential line that also serves businesses and professionals, from 8:00 to 23:00 every day of the year. Besides the phone, it is available on WhatsApp at 900 116 117 and on Telegram at @INCIBE017.
INCIBE-CERT: the reference incident response team for citizens and private companies in Spain, operating 24/7. Incidents are reported by email or web form from the business section of INCIBE's website.
Your insurer, if you have cyber insurance: the Spanish Insurance Contract Act gives a maximum of seven days to report a claim, unless the policy sets a longer period. Before hiring anyone, check whether your policy has an incident hotline or requires you to use its provider panel: costs you incur on your own may not be reimbursed.
An incident response team: if code was executed, remote access was given or there are signs the attacker moved to other systems, forensic analysis of the device and the logs is specialist work.

Meanwhile, keep everything: the original email, screenshots of what the employee saw, the time of each action you take and the exported logs. The bank, the police, the insurer and, if you notify, the data protection authority will ask for that timeline.

Step 9: after the incident, lessons learned and training with the real case

Once the incident is contained, hold a short meeting to reconstruct what happened without looking for someone to blame: how the email arrived, why it got past the filters, how long the report took, what worked in the response and what was improvised. That is where the highest-return improvements come from:

Turn the real email into training material. An example staff recognise as their own teaches more than any generic template. Anonymise it and do not single out whoever fell for it.
Phishing-resistant MFA (FIDO2 security keys or passkeys), at least for the most privileged or exposed accounts. These credentials are bound to the legitimate domain and do not work on a fake site, which is exactly what AiTM exploits.
Conditional access that limits sign-ins to managed devices or expected locations.
A report button in the email client and a reporting channel everyone knows.
Verification of bank detail changes through a channel other than email, with a call to a phone number you already had, and the rule of never ignoring the verification of payee warning that euro area banks have shown since October 2025 when the name does not match the IBAN.
Alerts on new external forwarding rules, new MFA methods and new OAuth consents.

If the incident showed that nobody knew who to report to, that is the first thing to fix: a one-page procedure, with names and phone numbers, that all staff know before the next email arrives.

Common mistakes that turn a click into a serious incident

Most phishing incidents can be contained by acting quickly and in order. These mistakes are what tend to turn a click into a bigger problem:

Punishing the employee. It makes sure the next person does not report, or reports late. The goal is to shorten the time between the click and the report, and that only happens if reporting is safe.
Switching off or wiping the device before analysing it, which loses the evidence of what ran and what left.
Only changing the password. With a stolen session or an authorised app, the attacker is still in.
Not looking for persistence. Forwarding rules, added MFA methods, OAuth apps and registered devices let the attacker come back weeks later.
Looking only at the employee who reported it and not finding the other recipients of the same email.
Letting the 72 hours pass without assessing whether there is a personal data breach, or not documenting why you decided not to notify.
Closing the case without checking what the attacker did with the account: emails sent in the employee's name, files downloaded or shared, and access to other apps through single sign-on.

FAQ

Is changing the password enough if the employee typed it into a fake site?

No. You also need to revoke open sessions and tokens, because in AiTM attacks the attacker keeps the session cookie and stays in even after the password changes. Also review registered MFA methods, mailbox rules, authorised apps and the devices linked to the account.

Should the employee who fell for the phishing be disciplined?

As a general rule, punishing a good-faith mistake backfires: the next person who falls for it will take longer to report, and a fast report is what limits the damage most. Deliberately skipping a mandatory procedure, such as verifying bank detail changes, is a different matter that has to be assessed case by case with HR.

Does a phishing incident have to be reported to the data protection authority?

Only if it is a personal data breach that may result in a risk to people, which is common when the attacker gets into a mailbox holding client or employee data. In that case, within 72 hours of becoming aware of it; in Spain, through the AEPD's online portal. If you conclude notification is not needed, document the breach and the reason for the decision anyway.

Can money sent in a phishing transfer be recovered?

Sometimes, but there is no guarantee. It depends on how quickly you alert your bank, whether the money is still in the destination account and the cooperation of the bank that received it. Call the bank as soon as you spot it, file a police report and keep all the documentation of the transaction.

Should I switch off the computer if the employee opened a malicious attachment?

No. Disconnect it from the network —cable and Wi-Fi, or your EDR's isolation— but leave it on: switching it off wipes memory, which may hold the evidence of what ran. Do not wipe it either until it has been analysed.

What if the employee only opened the email and did not click anything?

The risk is low: in an up-to-date email client, opening a message rarely compromises the device on its own. Even so, they should report it without deleting it, because it helps find and remove the same email from other mailboxes before someone else clicks.

Who can I ask for help if I do not have a security team?

In Spain, INCIBE's 017 helpline, free and confidential, from 8:00 to 23:00 every day, and INCIBE-CERT, which handles business incidents around the clock. If you have cyber insurance, notify your insurer too, and if code was executed or remote access was given, bring in a specialist incident response team.

Sources

Get help with a phishing incident