Phishing Incident Response Playbook: What to Do After the Click

A phishing incident response playbook is a stage by stage plan for what happens after someone clicks. It names what the attacker does next, which signal exposes it, and which containment action belongs to that stage.

Most programmes stop at the click. Filters block what they can. Training reduces how many people fall for what gets through. Reporting tells you when someone did. All three are necessary and none of them is sufficient: the human element appeared in 62% of breaches in the 2026 Data Breach Investigations Report, and phishing was the initial access route in 16% of them (Verizon, 2026 Data Breach Investigations Report, 2026, p. 12).

There is a second gap, and it is wider. Almost every phishing playbook in circulation assumes the lure arrived by email. Attackers stopped assuming that years ago. The same intrusion now starts with a text message, a phone call, a QR code on a printed invoice, or a callback number in a PDF, and the response plan written for a mailbox does not cover any of them.

This playbook covers five stages and three channels: email, SMS and voice.

New to the topic? Start with our guide to email incident response, then come back here for the stage by stage plan.

Why One Response Plan Is Not Enough

Most organisations have a single phishing response plan. Quarantine the message, block the sender, notify the user, close the ticket.

That plan answers the first stage. It answers nothing after it, and it answers nothing that did not arrive by email.

The stages are not variations of one problem. Isolating a device is the correct move during execution and the wrong move during exfiltration, where the priority is closing the outbound channel and defining the breach scope. Revoking a session token matters after credential theft and does nothing against a scheduled task that survives the reset.

A playbook is a set of stage specific actions, each one preplanned and each one owned. It shortens the two numbers that decide how bad an incident becomes: time to detect, and time to contain.

It also makes the programme measurable. When every stage has a defined action, you can see which stage you keep losing time in.

Stage 1, Initial Access: The Click and What It Opens

The user interacts with something that looks legitimate. In practice that is a credential harvesting page, a file that runs, or a prompt sequence ending in an approval the user did not understand.

Attackers no longer need a payload. Credential theft alone gets them in, quietly. Stolen credentials were the initial access route in 13% of breaches in the 2026 DBIR (Verizon, 2026 Data Breach Investigations Report, 2026, p. 15). Pretexting, where the attacker builds a believable scenario instead of sending a generic lure, accounted for 6% (p. 10 to 12).

On SMS. The lure is shorter and the pretext is thinner, usually a delivery notice, a bank alert or a password reset. Link shorteners hide the destination and the mobile browser shows less of the URL than a desktop client does. Reporting is also harder: most organisations have a reporting button in Outlook and nothing on a phone, so the first evidence of a smishing campaign is often the compromise itself. APWG recorded smishing volume rising 30 to 40% quarter on quarter through 2025 (Anti-Phishing Working Group, Phishing Activity Trends Report, Q4 2025, p. 4).

On voice. There is no link to inspect. The attacker builds the pretext in real time, adapts to hesitation, and asks the target to perform the action themselves: read a code, approve a prompt, install a remote support tool. Voice cloning has made the opening more convincing, and Gartner reports that 35% of organisations have experienced a deepfake incident while only 10% of security leaders prioritise deepfake training (Gartner, "6 Ways to Transform Your Cybersecurity Awareness Program", G00840741, March 2026, 2025 Secure Behavior Strategies Survey, n=65).

The channel difference shows up in the numbers. The same DBIR puts the median click rate for email based simulations at roughly 1.4%, while phone centric simulations fail at roughly 40% higher (p. 50). A programme that tests only email is not measuring its weakest channel.

How to detect it

• Authentication failures on the sending domain: SPF, DKIM and DMARC results that do not match the claimed sender, plus recently registered lookalike domains.
• Reported messages from employees. A reporting button turns people into sensors, and reports usually arrive before the alert does.
• Threat intelligence on newly registered domains and brand impersonation, so the lure is known before it lands.
• Sandbox detonation of links and attachments, which catches the first instance of a campaign rather than the hundredth.
• For SMS and voice, the signal is different: helpdesk contacts about unexpected messages, a spike in password reset requests, MFA prompts nobody initiated, and calls to numbers that do not belong to any vendor you use.

How to respond

• Quarantine the message across every mailbox that received it, not only the one that reported it.
• Block the sender, domain and URL at the gateway and the firewall.
• Check whether credentials were submitted. If a harvesting page was reached, this is a credential incident, not a mail incident.
• Request takedown of the malicious domain where the provider supports it.
• For SMS and voice there is nothing to quarantine, so containment moves to the identity layer immediately: reset the account, revoke sessions, and warn the wider organisation while the campaign is still running.

Measuring how people respond to each channel is a separate discipline. Our phishing simulator covers email, voice, SMS and QR in one console, which is what makes the failure rate comparable across channels rather than a set of unrelated numbers.

Stage 2, Execution: When the Payload Runs

If a file was delivered and opened, code runs. This is usually the first stage that produces an alert in the security operations centre rather than the service desk, which is why the handover between mail security and operations has to be agreed in advance.

On SMS. The payload is often an application rather than a document, and on a personal device it lands outside your endpoint tooling entirely. A managed laptop gives you telemetry. A personal phone with corporate mail on it frequently gives you nothing.

On voice. The attacker rarely delivers a payload at all. They ask the target to install a remote support tool, and the target does it willingly. The software is legitimate, signed, and often already allowed in your environment. Nothing looks like an attack until someone notices the session.

How to detect it

• Endpoint telemetry showing unexpected process trees, unsigned binaries, or a known signature from an existing blocklist.
• Behavioural detection rather than signature matching, which is what catches the evasive cases: unusual API calls, registry modification attempts, an encryption library invoked by something with no reason to call it.
• Sandbox analysis of file behaviour, including background connections opened after execution.
• Remote access tools starting outside the normal support workflow. This is the single most useful signal for a voice led intrusion, and most environments do not alert on it.
• Mobile device management events where the fleet is managed, and helpdesk reports where it is not.

How to respond

• Kill the process and quarantine the file.
• Isolate the device if the behaviour suggests spread rather than a single execution.
• Block outbound command and control connections.
• Disable the account when credentials may already have been used. Isolating a laptop does not help when the identity is what was taken.
• Terminate the remote session and revoke the tool's access, then check whether it was installed anywhere else.
• Roll back to a known clean state when analysis costs more than rebuilding.

Each option carries a false positive cost. Which one you choose is a risk appetite decision, and the playbook should record that decision once rather than reopening it during an incident.

Stage 3, Persistence: How Attackers Stay After You Think It Is Over

Once code has run, the objective changes from getting in to staying in. Persistence survives reboots and password resets. Defence evasion makes the investigation harder.

In mailbox terms this is where forwarding rules appear, where a rule quietly moves messages from one sender into a folder nobody opens, and where audit logging gets switched off.

Voice led intrusions persist differently. The attacker keeps the relationship rather than the access: they call back, they are now a known contact, and the second call is easier than the first. Registering their own number as a recovery method is quieter than any registry key.

How to detect it

• New or modified mailbox rules created shortly after a sign in from an unfamiliar location or device. This one signal catches a large share of business email compromise.
• Registry changes, new scheduled tasks, unusual parent process relationships.
• Tamper alerts on security tooling: disabled protections, cleared logs, downgraded policies.
• Behavioural comparison between the suspected host and a known clean baseline.
• Changes to recovery contacts, MFA methods and forwarding numbers. These are identity events, not endpoint events, and they are frequently unmonitored.

How to respond

• Hunt for the same artefact across the estate before closing the case. Persistence is rarely deployed once.
• Rotate identities and revoke active sessions, including non human identities, which are the ones usually missed.
• Remove the mailbox rule and alert on any recreation of it.
• Audit recovery methods and remove anything added during the incident window.
• Run a log integrity check. A suspiciously clean log is itself a finding.
• Redeploy from a known good image where rootkit level persistence is suspected.

Stage 4, Credential Access and Lateral Movement: The Internal Phishing Problem

With a foothold and one set of credentials, the attacker maps the environment and moves toward the accounts that matter. This is where phishing turns internal, and internal phishing works far better than the original lure because the message now comes from a real colleague on a real domain.

Targets at this stage are predictable: finance, HR, IT administrators, executive assistants. The goal is privileged access or a payment instruction change.

Internal SMS and voice belong here too, and they are more effective than internal email. A text from a number saved as a colleague, or a call from someone who already knows the project name and the org chart, passes scrutiny that an email would not.

Ransomware enters the picture at this stage rather than at the start. It was present somewhere in the chain of 48% of breaches in the 2026 DBIR (Verizon, 2026 Data Breach Investigations Report, 2026, p. 29).

How to detect it

• Identity threat detection: impossible travel, authentication anomalies, sudden privilege changes, new account creation.
• Internal mail patterns that do not fit the sender's history, for example a user who has never created a rule suddenly scheduling messages.
• Network detection for unexpected remote execution, protocol downgrades, abnormal access between segments.
• Credential dumping indicators and reconnaissance commands run from user endpoints.
• Helpdesk reports of internal calls or texts that turned out not to be from the named colleague. This is a human signal and it needs a route into the same queue as everything else.

How to respond

• Revoke tokens and shorten session lifetimes for the affected identity and everything it can reach.
• Force step up authentication rather than relying on a password reset alone.
• Monitor and remove mailbox rules as they are created.
• Segment first, investigate second, when the evidence points at movement rather than a single host.
• Reset the account across every environment it touches, not only the device where the alert fired.
• Tell people the campaign is running. If the attacker is calling colleagues, the fastest control is the workforce knowing about it.

When a reported message turns out to be a live campaign, analysis and containment have to happen in minutes rather than hours. That workflow is what our incident responder automates, from mailbox wide search to removal.

Stage 5, Exfiltration and Impact: Where Detection Is Already Late

At the final stage the attacker takes what they came for: data, money, or the ability to disrupt operations. Detection here does not prevent the loss. It limits it and starts the regulatory clock.

Voice led fraud usually ends here rather than in a data breach. Nothing is exfiltrated. Someone changes bank details on a genuine invoice and approves a genuine payment, and every control in the chain worked exactly as designed.

How to detect it

• Data loss prevention alerts on sensitive content moving to unapproved destinations.
• Cloud access and posture monitoring for unusual transfers and permission abuse.
• Insider risk signals, which look identical to a compromised account from the outside.
• Payment anomaly detection where bank details or invoice terms change late in a process.

How to respond

• Stop the transfer: block the connection, kill the process, isolate the host, reset the identity.
• Define the breach scope by mapping what the compromised identity could reach, not only what it did reach.
• Check the regulatory obligation and the notification clock immediately. That timing is fixed and does not wait for the investigation.
• Trigger the incident response plan formally. At this stage it is a high severity incident by definition.
• For fraudulent payments, contact the bank about recall while the transfer is still recoverable.
• Run root cause analysis and feed the finding back into the simulation programme, so the scenario gets tested rather than discussed.

The Playbook Checklist

Each stage has an owner, a detection source and a preplanned action. The channel column is what most templates leave out.

Stage 1, Initial access

Owner: mail security. Detect: authentication failures, user reports, threat intelligence, sandbox verdict. On SMS and voice: helpdesk contacts, password reset spikes, uninitiated MFA prompts. Act: quarantine across all mailboxes, block sender and domain and URL, confirm whether credentials were submitted, request takedown. On SMS and voice, move straight to identity containment.

Stage 2, Execution

Owner: security operations. Detect: endpoint telemetry, behavioural analytics, sandbox behaviour, remote access tools starting outside the support workflow. Act: kill and quarantine, isolate if spread is suspected, block command and control, terminate remote sessions, disable the account if identity is exposed.

Stage 3, Persistence

Owner: security operations. Detect: new mailbox rules, registry and scheduled task changes, tamper alerts, log gaps, changes to recovery methods. Act: hunt estate wide, rotate identities and revoke sessions, remove rules and alert on recreation, audit recovery contacts, verify log integrity.

Stage 4, Credential access and lateral movement

Owner: identity and security operations together. Detect: impossible travel, privilege changes, internal message anomalies, unexpected remote execution, helpdesk reports of internal calls. Act: revoke tokens, force step up authentication, segment, reset across all environments, warn the workforce.

Stage 5, Exfiltration and impact

Owner: incident response lead. Detect: data loss prevention, cloud posture, insider risk, payment anomalies. Act: stop the transfer, define scope, start the regulatory clock, formal incident response, bank recall where applicable, root cause analysis.

Three metrics worth tracking

Time to detect after the click. Time to contain once detected. Stage coverage: how many of the five stages you actually have telemetry for, per channel.

Where Awareness Training Fits

There is a reading of postclick response that says awareness training does not work. That is the wrong conclusion drawn from the right data.

Training changes how many people click and how many report. Detection and response change what happens to the ones who did click. Two controls, two parts of the same problem, and measuring only one of them is how a programme looks healthy while the risk stays where it was.

The measurement gap is documented. 84% of security leaders track training completion as a top programme metric (Gartner, "6 Ways to Transform Your Cybersecurity Awareness Program", G00840741, March 2026, n=65), while the human element still appeared in 62% of breaches. Completion is not containment.

A programme that works measures three things at once: how many people are susceptible, how many report, and how fast a report turns into containment. Our security awareness training covers the first two. This playbook covers the third.

Gartner's own framing points the same way. Its strategic planning assumption is that by 2029 the weaponisation of generative AI for social engineering will push 60% of security operations centres to mandate AI driven postclick behavioural monitoring (Gartner, "Don't Stop at the Gateway: Managing the Postclick Phishing Life Cycle", G00853281, 11 August 2026). That is a forecast rather than a measurement, but it matches what defenders are already reporting.