A phishing email that reaches inboxes becomes an identity incident the moment one recipient enters a password, approves a consent prompt or hands over a session token, and most teams lose the first hour working out who received it and who clicked. This template is a ready-to-adopt playbook for responding to reported and detected phishing: intake, a severity matrix, roles, triage of the reported email, scoping, containment, eradication, recovery, notification decision points, evidence and lessons learned, with target times for each step. It follows the incident response lifecycle in NIST SP 800-61 Rev. 3 and draws on CISA, NCSC and Microsoft incident response guidance. Replace the bracketed values and approve it through your normal incident response governance.
How to use this template
- Replace text in square brackets, such as [Organisation], [Security operations] and [15 minutes], with your own teams, tools and targets.
- "Must" is mandatory; "should" is recommended. Target times run from the moment the incident is declared unless stated otherwise.
- Keep this playbook subordinate to your [Incident Response Plan]: severity, escalation and communication rules there take precedence.
- Commands and log names for Microsoft 365 and Entra ID are worked examples; map each step to your own email platform, identity provider and EDR.
1. Purpose
This playbook sets out how [Organisation] detects, triages, contains and recovers from phishing incidents, including credential phishing, adversary-in-the-middle (AiTM) phishing, malicious attachments and OAuth consent phishing. It aims to remove malicious messages quickly, find every affected identity and device, cut off attacker access to accounts, tokens and applications, and meet notification obligations.
2. Scope
- Phishing delivered by email to any [Organisation] mailbox, including shared and service mailboxes.
- Phishing through collaboration tools, SMS or QR codes where it targets [Organisation] credentials; steps 7.1 and 7.2 are adapted to the channel.
- Business email compromise that follows a successful phish is handled under this playbook until scoping shows payment fraud, when [BEC / fraud procedure] also applies. See the Email Identity and BEC Guide.
3. Roles and responsibilities
| Role | Responsibilities |
|---|---|
| [SOC analyst] (first responder) | Monitors the reporting mailbox and alerts, triages, declares the incident, runs scoping queries, executes pre-approved containment |
| [Incident manager] | Owns the incident for SEV1 and SEV2, approves bulk purges and account disablement, coordinates teams and the timeline |
| [Messaging team] | Message trace, purge, sender and URL blocks, mailbox rule and forwarding checks |
| [IAM team] | Session and token revocation, password and MFA resets, OAuth app review and disablement |
| [Endpoint team] | Device isolation, malware analysis, reimaging |
| [Data protection officer] and [Legal] | Personal data breach assessment, regulator and individual notification decisions |
| [Communications] | Staff warnings, customer and media statements where needed |
| Recipients and reporters | Report suspicious messages through [Report button / [email protected]]; tell [Service desk] at once if they clicked or entered details |
4. Definitions
- Reported email: a message submitted by a user through the report button, the [phishing@] mailbox or the service desk.
- Interaction: a recipient clicked a link, opened an attachment, replied, scanned a QR code or approved a prompt.
- Credential submission: evidence that a recipient entered a password, one-time code or approved an MFA request on an attacker-controlled page.
- Consent grant: a user or administrator granted an OAuth application permissions to [Organisation] data.
- Purge: removal of a message from all recipient mailboxes by an administrator.
5. Triggers and intake
| Trigger | Source | Initial owner | Acknowledge within |
|---|---|---|---|
| User report | Report button, [phishing@] abuse mailbox, service desk call | [SOC analyst] | [30 minutes] in hours, [2 hours] out of hours |
| Email security alert | Gateway or platform detection after delivery, URL detonation verdict change | [SOC analyst] | [15 minutes] |
| Identity alert | Risky sign-in, AiTM or anomalous token detection, new MFA method, unusual consent | [SOC analyst] | [15 minutes] |
| Endpoint alert | EDR detection of a process spawned from an email client, browser or archive tool | [SOC analyst] | [15 minutes] |
| External notification | Customer, partner, CERT or police report | [Incident manager] | [1 hour] |
The NCSC advises that users must know how to report in advance, because they "may be unable to access normal means of communication if their device is compromised". Publish a phone number as well as the report button.
6. Severity matrix
| Severity | Criteria (any one) | Example | Declare and contain within | Escalate to |
|---|---|---|---|---|
| SEV4 Low | Spam or benign; or malicious but blocked or quarantined with no recipient interaction | Credential lure caught in quarantine | [1 business day] | None |
| SEV3 Medium | Malicious message delivered to one or more inboxes, no evidence of interaction | Fake invoice link in 40 inboxes, no clicks in proxy logs | [4 hours] | [SOC lead] |
| SEV2 High | Click, attachment opened, credential submission or user-level consent grant, with no confirmed attacker access yet | Two users entered passwords on a lookalike sign-in page | [1 hour] | [Incident manager] |
| SEV1 Critical | Confirmed attacker sign-in or token use; privileged, executive or finance account affected; tenant-wide consent; malware executed; data accessed or payment redirected | AiTM-captured session used to create inbox forwarding rules | [30 minutes] | [CISO], [Legal], [DPO] |
Raise the severity as soon as scoping finds new evidence; never lower it until containment is verified.
7. Response procedure
7.1 Triage of the reported email
| Step | Action | Owner | Target |
|---|---|---|---|
| T1 | Obtain the original message with full headers (as an attachment or from the reporting tool), not a forwarded copy. | [SOC analyst] | [15 min] |
| T2 | Read the headers: Authentication-Results (SPF, DKIM, DMARC results), From against Return-Path and Reply-To, the Received chain read from the bottom up to the originating IP, and the Message-ID. | [SOC analyst] | [15 min] |
| T3 | Analyse links and attachments in a sandbox or detonation service, never on a production device. Record final landing URLs after redirects. | [SOC analyst] | [30 min] |
| T4 | Extract indicators: sender address and domain, originating IP, subject, Message-ID, URLs and domains, attachment names and SHA-256 hashes. | [SOC analyst] | [30 min] |
| T5 | Record a verdict: malicious, suspicious, spam, simulation or legitimate. Assign severity using section 6. | [SOC analyst] | [45 min] |
| T6 | Reply to the reporter with the outcome and thanks. | [SOC analyst] | [1 business day] |
7.2 Scoping: who received, who clicked, who entered credentials
| Step | Question | Evidence (Microsoft 365 example) | Target |
|---|---|---|---|
| S1 | Who received it, and is it still in mailboxes? | Message trace (Exchange admin center or Exchange Online PowerShell) by sender, subject, Message-ID or URL; Threat Explorer in Defender for Office 365. Search for variants from the same infrastructure. | [30 min] |
| S2 | Who clicked or opened? | URL click logs from the email security platform, web proxy and DNS logs, EDR process trees (an email client or browser spawning a script host), Windows event 4688 | [1 hour] |
| S3 | Who entered credentials or approved MFA? | Identity provider sign-ins for each clicker from the click time onwards: new IP, ASN, country, device or user agent; AiTM or anomalous token detections; new MFA methods registered. Record correlation and request IDs. | [1 hour] |
| S4 | Did the attacker use the account? | Mailbox audit (New-InboxRule and forwarding changes, mailbox access from attacker IPs), file downloads, sent items, delegate changes (Get-MailboxPermission) | [2 hours] |
| S5 | Did anyone grant consent? | Audit log activity "Consent to application"; check IsAdminContent, consent type (Principal or AllPrincipals) and scopes | [2 hours] |
| S6 | Was anything sent onward? | Internal phishing sent from compromised mailboxes, and external recipients who may need warning | [4 hours] |
Microsoft's phishing playbook notes that Entra sign-in and audit data can be overwritten after 30 or 90 days, and that mailbox auditing must already be on. Confirm both before you need them. See the AiTM Phishing Guide for what token theft looks like in sign-in logs.
7.3 Containment
| Step | Action | Owner | Target |
|---|---|---|---|
| C1 | Purge the message and its variants from all mailboxes using the email platform's remediation (for example, Defender for Office 365 Soft delete or Hard delete from Threat Explorer, with two-step approval for large batches). Use soft delete where evidence may be needed later. | [Messaging team] | [SEV3: 4 h; SEV1/2: 1 h] |
| C2 | Block the sender address or domain, URLs, domains and attachment hashes at the email gateway, web proxy, DNS resolver and EDR. | [Messaging team], [SOC analyst] | [1 hour] |
| C3 | For every account with credential submission or suspicious sign-in: revoke sessions and refresh tokens (Entra: Revoke sessions or Revoke-MgUserSignInSession), then reset the password. For hybrid accounts, reset in on-premises AD; Microsoft advises resetting twice where pass-the-hash is a concern. | [IAM team] | [30 min] from confirmation |
| C4 | Remove MFA methods registered by the attacker and require re-registration; check for new device registrations. | [IAM team] | [1 hour] |
| C5 | Disable malicious OAuth applications rather than only deleting them, and remove their grants. Microsoft warns that a deleted app "might return later if another user grants consent". | [IAM team] | [1 hour] |
| C6 | Remove attacker inbox rules, forwarding addresses, delegates and app passwords. | [Messaging team] | [1 hour] |
| C7 | Isolate any device where a payload ran, using EDR network containment. | [Endpoint team] | [30 min] |
| C8 | For SEV1 privileged accounts: disable the account until eradication is complete, and revoke sessions in connected SaaS applications that keep their own sessions. | [IAM team], [Incident manager] | [30 min] |
Token lifetimes matter: revoking sessions stops new tokens, but Microsoft notes access tokens last one hour by default, and Entra cannot revoke session tokens issued by applications themselves. Where applications support Continuous Access Evaluation, revocation is near real time; elsewhere, plan for the gap. See the Token and Session Security Guide.
Consent phishing: treat apps requesting Mail.*, Contacts.*, MailboxSettings.*, People.*, Files.* or Notes.* as high risk; Microsoft observed a combination of these in 99% of consent phishing attacks. Directory.AccessAsUser.All and write-capable application permissions are critical. CoPhish showed consent prompts can be wrapped in trusted Microsoft domains, so a familiar URL is not evidence of safety. See the SaaS and OAuth App Governance Guide.
7.4 Eradication
- Confirm no attacker persistence remains: inbox and transport rules, forwarding, delegates, OAuth grants, new MFA methods, registered devices, app passwords, and API keys or tokens created in SaaS applications during the exposure window.
- Remove malware and rebuild affected devices where the payload's capabilities are not fully understood.
- Hunt for the same indicators and sign-in patterns across all users for [30 days] before the first delivery.
- Rotate secrets the compromised user could read in mail or files.
7.5 Recovery
- Re-enable accounts only after password reset, MFA re-registration and a clean persistence check, with [Incident manager] approval.
- Restore wrongly purged legitimate messages from Recoverable Items.
- Monitor recovered accounts with heightened alerting for [14 days], including sign-ins from new locations and new inbox rules.
- Confirm with business owners that systems and mail flow work normally, as the joint CISA, NSA, FBI and MS-ISAC guidance advises.
8. Notification decision points
| Decision | Trigger | Owner | Deadline |
|---|---|---|---|
| Personal data breach assessment | Attacker accessed a mailbox, files or systems holding personal data | [DPO] | Start at once; GDPR and UK GDPR Article 33 require notifying the supervisory authority within 72 hours of awareness unless the breach is unlikely to result in a risk |
| Notify affected individuals | Breach likely to result in a high risk to individuals (GDPR Article 34) | [DPO], [Legal] | Without undue delay |
| Sector regulator or contractual notice | [Sector rules, customer contracts, cyber insurance policy terms] | [Legal] | [Per obligation] |
| Warn external recipients | Compromised mailbox sent phishing or false payment details to customers or suppliers | [Communications] | [Same day] |
| Report to authorities | SEV1 or SEV2; fraud or loss | [Incident manager] | UK: NCSC incident reporting, and forward phishing emails to [email protected]. US: CISA ([email protected] or (888) 282-0870) and FBI IC3 |
| Staff warning | Campaign still arriving, or many recipients | [Communications] | [1 hour] |
9. Evidence collection and preservation
- Preserve the original message (.eml or .msg) with full headers, sandbox reports and extracted indicators, with hashes of each file.
- Export message trace results, click logs, sign-in logs, mailbox audit records and consent events for the exposure window before retention expires.
- Record every containment action with time, actor and approval reference (for example, the remediation history in the email platform's action centre).
- Store evidence in [case management system] with restricted access, and follow [forensic procedure] where legal action or insurance claims are possible. See the Digital Forensics (DFIR) Guide.
10. Communication with reporters and staff
- Thank every reporter and tell them the outcome. The NCSC advises feeding back quickly so users know reports "make a difference".
- Do not blame users who clicked. In the NCSC's words, "Users who fear reprisals will not report mistakes promptly, if at all."
11. Lessons learned and metrics
Hold a post-incident review within [10 working days] for SEV1 and SEV2, and review SEV3 and SEV4 trends [monthly], recording root cause, control gaps, actions and owners. Track:
- Time to purge: first report to removal from all mailboxes (target [under 1 hour] for SEV2 and above).
- Time to revoke: confirmed credential submission to sessions revoked and password reset.
- Report rate and first-report time: share of recipients who reported, and minutes from delivery to first report.
- Compromise ratio: credential submissions per malicious message delivered.
12. Related documents and review
- [Incident Response Plan], [BEC / Fraud Procedure], [Personal Data Breach Procedure], [Email Security Standard], [Acceptable Use Policy].
- This playbook is owned by [policy owner], reviewed at least annually and after every SEV1, and exercised [twice a year].
13. Source references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- CISA, NSA, FBI and MS-ISAC: Phishing Guidance, Stopping the Attack Cycle at Phase One
- NCSC: Phishing attacks, defending your organisation
- NCSC: Report a scam email
- Microsoft Learn: Phishing investigation playbook
- Microsoft Learn: App consent grant investigation playbook
- Microsoft Learn: Remediate malicious email delivered in Office 365
- Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
Implementation guidance
- Check the prerequisites: mailbox auditing on, identity and email logs retained in [SIEM] for at least [180 days], a report button deployed, and the [phishing@] mailbox monitored.
- Pre-approve containment: agree in advance which actions the SOC may take without the incident manager (purge under [100] mailboxes, session revocation for standard users) so step C3 is not delayed by approvals.
- Save the queries: store scoping queries for S1 to S5 in [SIEM] so they run with one input: sender, URL or Message-ID.
- Automate carefully: let SOAR extract indicators, check reputation and cluster duplicate reports first; automate purges only after [3 months] of reviewed results. See the SOAR and Security Automation Guide.
- Exercise it: run a tabletop with a SEV1 AiTM scenario and a consent phishing scenario before adoption, and time each step against the targets.
- Scale to size: small organisations can merge the analyst, messaging and IAM roles into one [IT security lead] with an external retainer for SEV1; large organisations should automate S1 to S3 and keep humans for verdicts and approvals.
Each area is covered in more depth in NHI Mgmt Group guides:
- Phishing techniques and controls: Phishing Guide
- Session theft and MFA bypass: AiTM Phishing Guide
- Email authentication and filtering: Email Security Guide
- Incident response plan and lifecycle: Incident Response Guide
This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: Phishing Guide · AiTM Phishing Guide · Email Security Guide · Incident Response Guide