Incident response
You clicked a phishing link. Here is the first hour.
Somebody clicked. They typed their password into a page that was not your login page, and now they have told you about it. The next hour decides whether this is an inconvenience or a breach, and most of what people do first makes it worse.
Do not start by deleting the email
The first instinct is to make the bad thing go away — delete the message, clear the history, close the tab. Every one of those destroys the evidence you need to work out what actually happened, and none of them stops the attacker, who left the moment they had the password.
The email is the only record of what was sent, who else received it, and which address it came from. You will want all three within the hour. Leave it exactly where it is.
Minute 0 to 10: cut off access
Assume the password is already being used. Phishing kits forward credentials the instant they are typed, and automated logins often happen within minutes. Speed matters more than certainty here — you can always undo a precaution.
Reset the password, then kill the sessions
Resetting the password is only half the job, and this is the step people miss. Most services keep existing sessions alive after a password change, so an attacker who is already signed in stays signed in. You have to explicitly revoke active sessions.
In Microsoft 365 this is Sign out of all sessions on the user. In Google Workspace it is Sign out user from the admin console. Do it after the reset, not before, or the attacker simply signs back in with the old password.
Check what the password unlocked elsewhere
If the same password was reused anywhere — and it usually was — every one of those accounts is now compromised too. Bank, payment processor, domain registrar, and the personal email that can reset all of them.
The domain registrar is the account people forget and the one that hurts most. Whoever controls your domain controls your email, and whoever controls your email can reset almost everything else.
Minute 10 to 30: find out what they did
Now look at the audit log, while it is still fresh. You are answering one question: did anyone sign in as this user from somewhere they should not have been?
- Sign-in history — unfamiliar locations, unfamiliar devices, times nobody was working
- Mailbox rules — a new rule that forwards or auto-deletes mail is the clearest sign of a real compromise
- Recent sends — attackers use the account to phish your contacts, and those messages come from you
- Connected apps — a newly authorised third-party app keeps access even after a password reset
- File access — anything downloaded in bulk
The forwarding rule is the tell
A rule that quietly copies incoming mail to an outside address, or that deletes messages containing the word "invoice", is not something a user creates by accident. It is how invoice fraud is set up: the attacker watches your billing conversations for weeks, then intervenes at the right moment with new bank details.
If you find one, this stopped being a phishing click and became a business email compromise. Treat it as serious, tell your finance contacts directly by phone, and verify any payment change made in the past month.
Minute 30 to 60: contain and tell people
If the account sent phishing to your contacts, tell them before they click. A short, plain message beats a careful one written two days later.
Say what happened, what to ignore, and what you will never ask for. No apology paragraph — people want the instruction, not the feelings.
Decide whether this is reportable
If personal data was accessible from that account — customer records, employee details, anything identifying a living person — you may have a legal reporting duty with a short clock on it. In the UK and EU the window is 72 hours from becoming aware.
Reporting duties are decided by what an attacker could reach, not by what you can prove they took. That is an uncomfortable standard, and it is the one that applies.
What not to bother with
Two things get suggested constantly in the moment and neither helps.
- Running a virus scan on the machine. A credential phish steals the password from a web page. Nothing was installed. A scan finds nothing and burns twenty minutes of the hour that mattered.
- Working out who is behind it. You will not find out, and it changes nothing you would do.
The exception: if the link downloaded a file and someone opened it, that is a different incident. Disconnect that machine from the network and treat it as potentially compromised rather than assuming a scan settles it.
The fix that prevents the next one
Phishing training helps less than most people hope. Attackers are good, the messages are convincing, and eventually somebody tired clicks something plausible. Planning for the click is more realistic than planning to prevent it.
The single change that turns this from a breach into a non-event is phishing-resistant multi-factor authentication. With it, a stolen password is not enough on its own — and the whole scenario above collapses into a password reset.
App-based codes are far better than nothing but can still be phished in real time by a convincing fake login page. Hardware keys and passkeys cannot, because they refuse to authenticate to the wrong domain.
The second change is writing the sequence above down before you need it. Nobody thinks clearly at the moment they realise what has happened, and an incident plan exists so that you do not have to.