Email Incident Response Runbook: A Practical Guide to Containing Phishing, BEC and Account Takeover

Key takeaways

• An email incident response runbook converts a reported message into assigned owners, approval gates and preserved evidence before anyone deletes anything.
• Activation triggers, severity thresholds and response-time objectives belong in the email incident response runbook so classification never depends on one analyst's improvisation.
• Safe analysis requires read-only inspection, full header preservation and controlled enrichment, because a single unsafe click destroys both evidence and containment options.
• Account compromise demands session revocation, token removal, mailbox-rule review and OAuth cleanup, since a password reset leaves cyberattacker persistence untouched.
• Microsoft 365 and Google Workspace procedures translate the email incident response runbook into named console actions, approvers and reversible steps.
• Exercises, metrics and post-incident reviews keep the email incident response runbook aligned with current cyberattacker behavior, platform changes and regulatory duties.

Want more from Adaptive in your Google results?

One suspicious message can become credential theft, mailbox takeover or a completed wire transfer in the time a help desk takes to open a ticket. Most organizations discover the gap during the incident itself, when nobody can say who may quarantine mails across mailboxes, who may revoke sessions and which evidence must survive the cleanup. An email incident response runbook would solve that issue immediately.

According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, phishing and spoofing generated 191,561 complaints, the highest number of reports. This guide covers:

• Activation triggers, severity levels and role ownership that start an email incident response runbook without debate;
• Safe triage of headers, URLs, attachments and QR codes that an email incident response runbook should require before any interaction;
• Scope and severity analysis that connects one message to recipients, identities, data and business processes;
• Containment, persistence eradication and organization-wide cleanup sequenced so evidence survives;
• Microsoft 365 and Google Workspace actions mapped to approvers, evidence output and rollback options;
• Recovery validation, communications, metrics and exercises that keep the email incident response runbook operational.

Reported phishing sits in a shared inbox while cyberattackers move through mailboxes, tokens and payment workflows. Adaptive Security removes confirmed malicious mail across every affected inbox automatically.

Explore the platform

What Is an Email Incident Response Runbook and What Should It Cover?

An email incident response runbook is an approved, repeatable set of triggers, roles, decision criteria, actions and evidence requirements for handling email-borne cyber threats. It gives security, IT, legal, privacy and business teams one operating method for investigating suspicious messages, containing harm and restoring trusted operations. The runbook must preserve evidence while enabling proportionate action, because deleting a dangerous message too quickly destroys the facts needed to determine scope, attribution and reporting obligations.

What Are the Scope and Objectives of an Email Incident Response Runbook?

Email response needs a dedicated runbook because one event can escalate from a suspicious message to credential theft, account takeover, data exposure or ransomware deployment within minutes. A help desk process records a ticket and routes it onward, yet it rarely defines who can revoke sessions, quarantine messages across mailboxes, preserve headers or notify legal counsel.

Those omissions create delay at the moment cyberattackers benefit most from uncertainty. According to Verizon's 2026 Data Breach Investigations Report, 62% of confirmed breaches involve a human element, which makes the reporting-to-containment path an operational control in its own right.

The runbook should apply to messages received by employees, executives, contractors, shared mailboxes, mobile devices and monitored service accounts. It should also cover messages sent from organizational accounts when the sender may be compromised, along with trusted external accounts that cyberattackers have taken over. A message that passes normal authentication checks can still be malicious when a vendor, partner or colleague's account has been hijacked.

Its objectives should include consistent triage, controlled containment, evidence integrity and clear escalation. Every report needs an initial classification, an owner and a response deadline. Responders should stop further delivery, block active indicators and protect exposed accounts without broad action that disrupts legitimate business.

The email incident response runbook should state when an event remains a user report, when it becomes a confirmed malicious message, when an account is considered compromised and when legal, privacy, regulatory or executive notification is required. NIST's 2025 incident response guidance places verification, evidence collection, prioritization and action inside a coordinated process instead of treating each signal as an isolated ticket.

A strong runbook also protects employees from blame, because reporting a suspicious email is a defensive action whether or not the message proves malicious. The process should make reporting easy, provide immediate feedback and route the signal to trained responders. That design turns employees into an early-warning network, so nobody has to make a forensic judgment before asking for help.

Which Email Incident Types Should the Runbook Cover?

Scope should follow cyberattacker behavior, since message labels describe only what a filter already caught. A modern email incident response runbook should cover phishing and spear phishing, including messages personalized through open-source intelligence (OSINT). It should also address business email compromise (BEC), invoice fraud, payroll redirection, credential theft, malware delivery and ransomware precursors such as malicious attachments, remote-access tools or links to payloads.

Account takeover and messages sent from a compromised internal mailbox deserve their own path. These incidents require more than message removal, because a cyberattacker may have created forwarding rules, registered new authentication methods, stolen session tokens, read historical mail or targeted colleagues and customers from the account. External sender compromise carries the same weight, since a familiar supplier's mailbox can deliver a malicious request that looks more credible than a newly registered phishing domain.

Executive and vendor impersonation should have explicit decision paths. A request to change bank details, approve an urgent transfer, disclose confidential information or bypass an established process requires verification through a trusted channel. The runbook should identify which roles can approve financial holds, vendor callbacks, account restrictions and executive notifications.

Modern lures also hide in formats that keyword checks miss, so scope should include QR-code phishing, image-based cyberattacks, HTML smuggling, malicious calendar invitations and attachments that conceal links inside screenshots. A QR code can redirect a mobile user to a credential-harvesting page while the visible email stays nearly empty. Image-based cyberattacks place the call to action inside a graphic, which forces analysts to preserve the image and inspect its destination instead of reviewing only the text layer.

Thread hijacking belongs in the same group. Cyberattackers who gain access to an existing conversation can reply within a legitimate chain, quote accurate business context and insert a new payment or document request. The runbook should require responders to verify such a message against mailbox activity, sign-in history, reply-to behavior, attachment changes and the account owner's independent confirmation.

These categories should not become silos, because one email can involve several incident types at once. A malicious invoice sent from a compromised vendor account can trigger BEC, credential theft and attempted ransomware delivery in a single event. The runbook should record the primary incident type while preserving every connected indicator and escalation path.

How Should the Runbook Distinguish Email Events?

Clear distinctions prevent both underreaction and unnecessary disruption, so the email incident response runbook should define four states and the evidence that moves an event between them. Each state carries different authority, different containment actions and different notification duties. Recording the state explicitly in the incident ticket keeps later responders from mistaking a contained message for a contained cyberattacker.

• Reported suspicious email: An unvalidated signal from an employee, automated control or external party. The responder preserves the original message, assesses its indicators and determines who else received it.
• Confirmed malicious message: Evidence shows the email is harmful or part of a campaign. The response can include organization-wide search and removal, indicator blocking, affected-user notification and checks for clicks, replies, downloads or credential submission.
• Compromised account: Evidence shows unauthorized access through suspicious sign-ins, unfamiliar forwarding rules, unauthorized OAuth grants, mailbox searches, unexplained sent messages, changed authentication factors or anomalous token activity.
• Reportable breach: A legal and organizational determination that depends on the data involved, the people affected, the jurisdiction, contractual duties, evidence of access and applicable deadlines.

A confirmed malicious message never proves on its own that an account or endpoint was compromised, and absence of confirmed exfiltration never ends the breach inquiry. The breach determination belongs with authorized legal, privacy and compliance personnel rather than a help desk analyst.

What Are the Minimum Components of an Email Incident Response Runbook?

The minimum components of an email incident response runbook should stay usable during a high-pressure investigation. Decision points belong in plain language, with technical actions linked to approved procedures that name the console, the role and the expected output. Anything a responder cannot execute at 2 a.m. without asking permission is documentation rather than a runbook.

• Trigger and intake criteria: Define what starts the workflow, including employee reports, detection alerts, suspicious authentication activity, external notifications and executive or vendor complaints;
• Severity and decision criteria: Set thresholds for suspicious, malicious, account-compromise and potential-breach classifications, weighing business impact, affected users, privileged access, financial requests, sensitive data and active propagation;
• Roles and authority: Name the incident lead, email administrator, identity responder, endpoint owner, legal or privacy contact, communications lead and business owner, then state who can quarantine, disable accounts, revoke tokens and approve external notifications;
• Evidence requirements: Preserve the original message, full headers, envelope data, attachments, URLs, screenshots, QR-code images, authentication results, timestamps, mailbox locations, audit logs and analyst notes, recording who collected each item and when;
• Containment actions: Specify message search and quarantine, URL or sender blocking, session revocation, credential resets, OAuth consent removal, forwarding-rule review and endpoint isolation where malware execution is suspected;
• Stakeholder communications: Provide approved notices for affected employees, executives, vendors, customers and regulators that state what happened, what recipients must do and which verification channel is trusted;
• Recovery and validation: Require confirmation that malicious messages were removed, accounts are secure, persistence mechanisms are absent, exposed credentials were changed and business processes can resume;
• Documentation and lessons learned: Capture the timeline, decisions, evidence, scope, control gaps, response times and follow-up actions, then feed confirmed patterns into detection rules and targeted cybersecurity awareness training.

CISA's 2024 Cybersecurity Incident and Vulnerability Response Playbooks direct responders to preserve evidence after containment and use the findings to adjust detection and response controls. That principle matters in email incidents because aggressive deletion can stop exposure while erasing the headers, delivery history and account activity that the next decision depends on.

A practical runbook should connect to phishing response and phish triage workflows without collapsing every report into an automated verdict. Automation can classify messages, locate copies across mailboxes and trigger reversible remediation. Human responders still decide whether the incident involves account compromise, regulated information, fraud, malware execution or external notification.

The email incident response runbook is complete when a responder can answer five questions without improvising: what happened, who owns the decision, what action is safe now, what evidence must be preserved and what condition forces escalation. An incident commander reading the finished document should be able to name the approver for every destructive action on the page.

Build the reporting path into a workflow that classifies, searches and remediates confirmed phishing before the second recipient clicks, using Adaptive Security's automated phish triage and employee risk scoring.

Take a self-guided tour

How Should an Organization Prepare an Email Incident Response Runbook?

Preparation means defining activation triggers, assigning decision rights, setting response-time objectives and documenting evidence and communication procedures before an alert arrives. The workflow should be built around user reports, identity signals, mailbox changes, malware indicators, financial requests and security-tool detections, then tested with realistic exercises. An email incident response runbook must still work when email itself is compromised, when key personnel are unavailable and when legal decisions arrive under pressure.

1. Define Email Incident Response Runbook Activation Triggers

State exactly when the runbook starts. Leaving activation to an analyst's judgment creates inconsistent thresholds, delays containment and produces incomplete records. One user report should open a triage record immediately, even when the message later proves benign.

A reported email becomes an active incident when any of these conditions is present:

• A confirmed malicious URL, attachment, QR code or redirect;
• The same message reaches multiple recipients or departments;
• A user submits credentials, approves an MFA prompt or enters payment information;
• The identity provider records a suspicious sign-in, impossible-travel signal, unfamiliar device or MFA change;
• A mailbox rule, forwarding address, delegate permission or transport rule appears unexpectedly;
• A user grants suspicious OAuth consent or an unfamiliar application receives mailbox access;
• Malware executes, an endpoint protection alert fires or a downloaded file launches;
• Sensitive data is exposed, sent externally or accessed from an unusual location;
• A payment-change request, vendor-bank update, payroll instruction or executive impersonation attempt appears;
• A mail security, identity, endpoint or data-loss prevention tool generates a high-confidence alert.

User reporting is a security signal in its own right. CISA's 2023 phishing guidance emphasizes interrupting the cyberattack cycle at its earliest phase, so the runbook should retain the original message and begin triage before an analyst determines whether compromise occurred. A documented no-action threshold covers spam, newsletters and nuisance mail while retaining the report and its disposition.

Severity levels connect evidence to action. Severity 1 covers confirmed account takeover, malware execution, data exposure, successful credential submission, unauthorized payment activity or a widespread campaign. It carries a 15-minute acknowledgment objective, immediate security-lead escalation and notification of executive, legal, privacy or finance stakeholders as applicable.

Severity 2 covers a confirmed malicious message, suspicious sign-in, mailbox persistence or multiple targeted recipients without confirmed compromise, acknowledged inside 30 minutes and escalated to the incident commander and identity or mail administrator. Severity 3 covers an isolated suspicious report or unconfirmed signal, acknowledged within four business hours and closed only after documented analysis.

NIST's 2025 SP 800-61 Revision 3 incident-response guidance places incident response inside broader cybersecurity risk management, so activation criteria, ownership and improvement actions belong in the operating model in preference to an analyst's personal checklist. Escalation timers should override silence. When the assigned responder fails to acknowledge the ticket within the objective, the system or duty manager notifies the backup role automatically.

2. Assign Roles, Permissions and Escalation Paths in the Email Incident Response Runbook

Assign one accountable owner to each decision, because a runbook that names only "IT" or "security" creates a queue in place of a response capability. The incident commander owns severity, priorities, handoffs and closure. The security triage analyst validates the message, identifies recipients, correlates identity and endpoint signals and records every action taken.

The identity administrator revokes sessions, resets credentials, removes unauthorized MFA methods and blocks suspicious applications. The mail administrator searches and quarantines messages, removes malicious copies, reviews forwarding and delegate settings and preserves message metadata. Endpoint response owns host isolation, process collection, malware analysis and recovery whenever an attachment or link executes.

Legal and privacy reviewers determine privilege, notification duties, evidence holds, contractual obligations and regulator engagement. Finance validates payment changes, contacts banks and pauses transactions, while communications prepares employee, customer, partner and media messaging. An executive decision-maker approves business-impacting shutdowns, public statements and material risk acceptance.

Permissions belong in place before an incident. The triage role needs read-only access to mail headers, message trace, threat detections, identity alerts and endpoint context. The mail administrator needs scoped search, quarantine, purge and mailbox-rule permissions, while the identity responder needs session revocation, credential reset, MFA-method removal and OAuth-consent controls.

The endpoint responder needs isolation and forensic-collection authority. Legal and privacy personnel need the incident record and evidence index without receiving unnecessary message content. For Microsoft 365 environments, the email incident response runbook should document approved Microsoft Defender, Exchange Online, Microsoft Entra ID and Microsoft Purview actions by role.

For Google Workspace environments, document the corresponding Gmail, Admin console, investigation, alert-center and identity actions. These platform examples are illustrative rather than universal requirements. Record the exact command, console action, approver and timestamp so responders never improvise destructive steps during a crisis.

3. Prepare Prerequisites and Communication Fallbacks

Access, telemetry and contacts should be assembled before the runbook is needed. Required prerequisites include mail-flow and message-trace logs, identity-provider sign-in and audit logs, endpoint detection telemetry, DNS and proxy records, URL and attachment sandbox access, cloud application logs, data-loss prevention alerts, threat-intelligence lookups and administrative audit trails.

Retain enough history to compare the suspicious event with normal behavior, and verify that clock synchronization and time-zone settings match across systems. An access matrix should show who can perform mail searches, export headers, quarantine messages, revoke sessions, disable accounts, remove OAuth grants, isolate endpoints and place evidence under hold. Every permission needs a quarterly test in a nonproduction exercise, since a permission that exists only on paper fails when the incident commander reaches for it.

The contact register should list primary and backup responders, cloud administrators, legal and privacy counsel, finance contacts, public relations, executive leadership, cyber insurer, outside breach counsel, forensic providers, critical vendors and relevant regulators, with time zones, mobile numbers, escalation order and availability windows. Store the register outside the corporate mail system.

The fallback channel is mandatory. An out-of-band channel such as a managed phone bridge, emergency messaging group, hardware-token-protected collaboration space or designated conference line keeps coordination alive when mail cannot be trusted, and offline instructions for activating it belong with the register.

When a cyberattacker controls mailboxes, the affected email thread must never carry containment coordination, payment approvals or evidence distribution. High-risk instructions require confirmation through a second trusted channel, and two-person approval should gate account disablement, mass purge, wire changes and external notifications. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, internet crime drove $20.877 billion in reported losses, a 26% jump over the prior year ($16.6 billion in 2024).

4. Standardize the Incident Ticket and Evidence Schema

Every incident record should be searchable, auditable and usable by the next responder, which means one ticket structure for suspected phishing, BEC, malware delivery, account takeover and data exposure. Required fields include incident ID, severity, detection source, reporter, affected user, department, sender, recipient list, subject, message ID, URLs, attachment names and hashes, suspected tactic, affected systems, current owner, business impact, data classification, legal-hold status, regulator considerations and closure reason.

UTC serves as the canonical timestamp, with local time recorded whenever a human action or business event matters. Capture detection time, report time, acknowledgment time, first containment action, identity action, mail-remediation start and end, endpoint action, legal review, finance notification, executive decision, recovery validation and closure approval. Those timestamps expose the delay between user reporting and containment, which gives the program a measurable improvement target.

A consistent evidence-naming convention such as INC-2026-0042_2026-05-14T161530Z_mail-header_user123_v01.eml keeps exports traceable. Include the incident ID, UTC timestamp, evidence type, pseudonymized subject identifier and version. Preserve the original message in its native format alongside full headers, attachment hash, URL-expanded destination, screenshots, sandbox result, relevant logs, administrator actions and analyst notes, and never edit an original artifact to make it easier to read.

Chain-of-custody fields should record evidence ID, collector, collection date and UTC time, source system, acquisition method, hash, storage location, access history, transfer details and disposition, with access limited to authorized responders. When legal counsel issues an evidence hold, the ticket records it and routine retention jobs stop deleting relevant mail, logs, endpoint data or chat records.

A phish triage workflow supports consistent classification and remediation, though it never replaces documented ownership, evidence handling or legal review. Closure requires that malicious messages are removed or contained, sessions and credentials are secured, mailbox persistence is eliminated, affected endpoints are assessed, exposed data and payment risks are addressed, required notifications are complete and the incident commander approves the record. The closing entry should name the root cause, control gaps, user-support needs and a corrective-action owner with a due date.

How long does a reported phishing email sit in a shared mailbox before anyone assigns an owner? Adaptive Security compresses that window to minutes with automated classification and remediation.

Book a demo

How Should Analysts Use an Email Incident Response Runbook to Analyze and Classify a Suspicious Email Safely?

An email incident response runbook should move every report through one sequence: capture the reporter's observations, preserve the original message, inspect artifacts without activating them, enrich indicators in controlled tools and classify the event by impact and confidence. Analysts must separate what the email contains from what the recipient did with it. A harmless-looking message becomes an incident the moment someone clicks, submits credentials, opens an attachment or transfers data, so uncertainty justifies preservation and escalation rather than dismissal.

1. Capture the Report Before Investigating the Message

The event should be recorded in the reporter's own words before anyone deletes, forwards, replies to or interacts with the email. The help desk or security analyst documents what the person saw, when the message arrived, where it was viewed, which device and account were active and what action followed. A vague note that the email looked strange establishes neither exposure nor the cyberattack path.

Record the subject, displayed sender name, sender address, reply-to address, recipient mailbox, arrival time and time zone, mailbox folder and the mail client involved. Document whether the user clicked a link, scanned a QR code, opened an attachment, enabled content, replied, called a phone number, entered credentials, submitted payment information, approved a multifactor authentication prompt or contacted the supposed sender through another channel.

Relationship context often matters more than spelling errors, so the intake questions should establish whether the message was part of an existing conversation, whether the sender normally communicates with the recipient and whether the request matched the recipient's role. A familiar vendor requesting new bank details, an executive demanding secrecy or a colleague suddenly sharing a cloud document deserves the same scrutiny as an obviously deceptive message.

Preserve the original message as an attachment or export rather than a screenshot, which documents appearance while omitting routing data, authentication results, message identifiers and the exact links or attachments the investigation needs. Assign a case ID, preserve the original mailbox location and record every action already taken. That record stops a later analyst from mistaking a containment step for user behavior.

2. Inspect the Message and Artifacts in a Read-Only Environment

Safe email analysis begins with a read-only preview that renders the message without executing its content. The preview should disable JavaScript and other scripts, macros, embedded objects, active content, automatic image loading, external requests and clickable links. Analysts should avoid opening the message in a normal mailbox, visiting a destination URL, calling a number, scanning a QR code or opening an attachment on a production device.

Work from a preserved copy inside an isolated analysis workstation or approved detonation environment. Display URLs as inert text, including the full destination behind shortened links, buttons, images and QR codes. Image-only messages are active evidence, so optical character recognition can extract text in a controlled environment while separate analysis inspects the graphic for brand impersonation, payment instructions, credential prompts and hidden QR codes.

Collect full headers before forwarding the message anywhere. The evidence package should include From, Sender, Reply-To, Return-Path, Message-ID, Date, subject, MIME structure, authentication results and every Received header in order. Record sender and reply-to mismatches, SPF, DKIM and DMARC outcomes, alignment status, sending and relay IP addresses, URLs, domains, attachment names, file types, cryptographic hashes, timestamps, mailbox locations and relevant sign-in telemetry.

Authentication results need comparison against business context. A message can pass authentication and still be malicious when a cyberattacker uses a legitimate compromised account or a lookalike domain with valid mail records, while a failed result is a strong warning short of a verdict. Preserve the raw headers and body, since security tools can rewrite, normalize or remove fields during forwarding and remediation.

3. Enrich Indicators Without Exposing Organizational Data

Controlled enrichment turns message artifacts into investigation signals. Query domains, URLs, sending IP addresses, file hashes and message IDs through approved threat-intelligence services, URL reputation systems, malware sandboxes, passive DNS and domain-registration records. Reputation results are evidence rather than verdicts, because a new domain can be malicious before any database lists it while a legitimate hosting provider serves both safe and harmful content.

Submit only the minimum necessary data to external services. URLs can carry email addresses, customer identifiers, tokens, document names or internal case information, and attachments can contain regulated material. Defang URLs when sharing them, strip secrets from query strings where the workflow permits, use private analysis environments for sensitive files and follow organizational rules on data residency and third-party processing.

Analyze the domain's registration date, registrar, name servers, historical resolution records, certificate details and hosting relationships, then examine whether the visible sender, reply-to domain, linked domain, attachment brand and business relationship form a coherent chain. A newly registered lookalike domain combined with a mismatched reply-to address and a payment request should move immediately to high-risk review.

Polished writing no longer supports a classification by itself, since generative tools produce correct grammar, realistic executive tone, multilingual text and individualized spear phishing. Analysts should weigh relationship anomalies, unusual payment or payroll requests, pressure to bypass approvals, unexpected secrecy, thread hijacking and requests that change established processes. According to Sumsub's 2025–2026 Identity Fraud Report, sophisticated fraud surged 180% YoY including deepfakes, synthetics, and telemetry tampering.

Deepfake-linked lures extend the same campaign into voice and video. The apparent 2024 deepfake call targeting U.S. Sen. Ben Cardin, in which a caller posed as former Ukrainian Foreign Minister Dmytro Kuleba, shows why trusted voice and video communication still require independent verification, as NBC News reported in 2024. The email incident response runbook should therefore instruct analysts to capture related calls, meetings and messages as part of the same incident record.

4. Classify the Message, Account and Business Impact

Classification should reflect both the artifact and the recipient's actions. Analysts use the narrowest accurate label, document the supporting evidence and record what would change the decision. This decision tree stops a suspicious email from being marked safe merely because no payload was found.

CISA's 2025 StopRansomware Guide emphasizes preserving volatile evidence and collecting incident artifacts when unauthorized activity is suspected. Applied to email, that means searching for the same sender, message ID, URL, attachment hash, subject and recipient pattern across the organization before deleting every copy.

When evidence stays incomplete, the case is classified as suspicious with the resolving test written into the ticket. Credential entry separates the account investigation from the message classification and starts containment immediately, while submitted data requires identifying what was sent, where it went and who accessed it. An executed attachment or redirected QR code forces correlation across endpoint, browser, identity and mailbox telemetry.

A disciplined email incident response runbook gives analysts a defensible record from intake through disposition, while automated phish triage standardizes classification and remediation without removing analyst judgment. Every closed ticket should show the label applied, the evidence behind it and the analyst who signed off.

Every reported message deserves a classified, remediated and documented outcome, and Adaptive Security produces that record automatically while analysts concentrate on incidents needing human judgment and escalation.

Take a self-guided tour

How Should the Email Incident Response Runbook Determine Scope and Severity?

An email incident response runbook turns one suspicious message into a defensible impact assessment by tracing recipients, actions, identities, assets and business consequences. Responders preserve evidence, establish whether the message caused compromise and assign severity using documented thresholds in place of intuition. The final assessment has to survive review by legal, privacy, leadership, insurers, customers and regulators.

1. Scope the Message and Every Recipient

Message scoping begins with the original artifact rather than a screenshot or forwarded copy. Preserve the full message source, headers, attachments, URLs, authentication results, timestamps, sender infrastructure, message ID, reply-to address and embedded tracking identifiers. Record who reported it, when the report arrived and whether it came from a shared mailbox, executive account, finance queue or external contact.

Search the mail environment for the message ID, normalized subject, sender address, sending domain, attachment hash, URL, reply-to value and campaign-specific phrases. Extend the search to aliases, distribution lists, shared mailboxes, mobile mail, archived mail and quarantine. One delivered message can create far broader exposure through automatic forwarding, delegated access, mailing-list expansion or a reply chain that reaches external recipients.

Build a recipient map that separates direct recipients from copied recipients, blind-copy recipients, distribution-list members, forwarded recipients and people who replied. Identify duplicate messages that used different subjects or slightly altered content. Include external mailboxes, suppliers, customers, personal addresses and partner domains, because internal mail logs alone cannot establish customer impact.

The record should capture message status for every identity:

• Delivered: The message reached a mailbox or device;
• Opened: The recipient accessed the message, which falls short of proving interaction;
• Clicked: The recipient interacted with a URL;
• Downloaded: The recipient accessed an attachment or payload;
• Submitted credentials: The recipient provided credentials, creating materially higher risk;
• Consented to OAuth: The recipient granted cloud access that can persist without password entry;
• Replied: The recipient exposed information or validated an active account to the cyberattacker.

Preserve a timeline that joins mail-delivery records with URL telemetry, attachment detonation, identity-provider events, endpoint detections, cloud-audit logs and payment-system activity. The 2025 NIST incident-response recommendations emphasize integrating incident response with broader cybersecurity risk management, so the assessment must connect the email event to affected systems and business operations instead of stopping at message removal.

2. Determine User and Asset Impact

Impact analysis starts with the identity that interacted with the message, then expands to the privileges and systems reachable from it. Confirm whether the user held administrator rights, finance approval authority or access to customer records, source code, regulated data, executive correspondence or payment platforms. An ordinary employee account and a finance administrator can receive identical emails and produce very different incidents.

Correlate the message timeline with identity and endpoint activity. Check for sign-ins from unfamiliar locations or devices, impossible-travel indicators, new multifactor authentication methods, password resets, token issuance, mailbox access from unusual clients, inbox rules, forwarding rules, deleted messages and changes to delegated access. Cloud logs should surface OAuth application consent, unusual API calls, bulk downloads and access to shared drives.

Endpoint review covers downloaded files, script execution, browser credential theft, persistence mechanisms and lateral movement. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials were involved in 39% of breaches across the full attack chain, which is why credential submission changes the investigation immediately.

Mailbox-rule creation and OAuth consent are persistence indicators that outlast the credential itself. A stolen password is one event, while a cyberattacker-created forwarding rule keeps exporting mail after the password changes. An authorized cloud token can likewise survive a password reset until the organization revokes sessions, removes the application grant and checks for additional tokens.

Data sensitivity and business consequence need separate assessment. Identify whether the cyberattacker reached personal data, payment information, employee records, privileged legal communications, trade secrets, credentials or customer material. Determine whether the event interrupted payroll, payments, clinical services, production, customer support, safety operations or regulatory reporting.

Executive and finance requests receive special handling. When the email requested a wire transfer, vendor-bank-detail change, payroll change, gift-card purchase, tax document or confidential acquisition information, the request requires verification through an independently sourced channel, never the phone number, reply address or meeting link supplied in the message. For vendor-bank changes, freeze the transaction, contact the supplier through an established record and preserve the approval trail.

Partner involvement extends the same discipline outward. When a partner mailbox was involved, ask the partner to preserve logs and confirm whether its account, forwarding rules or payment instructions were altered. That request should go through a verified contact already held in the vendor master record.

Severity should move upward when new evidence demonstrates broader identity exposure, privilege, persistence, sensitive-data access, financial loss or customer impact. It moves downward only after responders complete the relevant searches, preserve evidence and document negative findings. "No evidence found" carries a different weight from "evidence of no access."

3. Decide Whether to Escalate and Notify

Escalation converts the classification into obligations. Legal counsel belongs in the response whenever personal data, regulated information, privileged communications, contractual data, payment instructions, cross-border processing or material business disruption is possible. Privacy counsel determines whether affected individuals, regulators or customers require notice, and leadership needs a fact-based record covering what happened, which identities and systems were involved, what remains unknown and what containment is complete.

Law enforcement notification applies to financial loss, extortion, danger to public safety, significant fraud, critical-service impact or a credible need to preserve external investigative evidence. Insurer notification follows the policy's incident-reporting terms, since late notice or unauthorized vendor engagement can create coverage problems. Customers and suppliers enter the process when their data, domains, payment details, accounts or personnel were exposed, coordinated through approved contacts and never the compromised mailbox.

Regulator notification depends on personal-data exposure, sector-specific obligations, critical infrastructure duties, financial services rules, healthcare requirements, government information or contractual reporting terms. No notification date should be promised before counsel confirms the trigger, affected population and required content. Containment continues throughout that assessment, so responders revoke sessions, remove malicious rules, reset credentials, disable unauthorized applications, block indicators and protect payment workflows while the legal classification is still open.

Closure requires an evidence-backed narrative stating the initial report, confirmed scope, user and asset impact, containment actions, severity changes, notification decisions, unresolved questions and corrective actions. A reviewer opening that file six months later should be able to reconstruct who decided what, and when, without calling anyone.

When a finance approver cannot verify an unusual payment request in under a minute, the control has already failed. Adaptive Security rehearses that decision before a real invoice arrives.

Book a demo

How Should Responders Handle Containment and Eradication in an Email Incident Response Runbook?

Containment and eradication should move from immediate isolation to persistence removal and organization-wide cleanup. Responders preserve evidence, quarantine the cyber threat, restrict compromised identities, remove malicious content and verify that no cyberattacker-controlled access remains. Every destructive action needs an approval checkpoint, because deleting messages, disabling accounts or purging a tenant can destroy evidence and interrupt legitimate business.

Speed and evidence discipline have to coexist here. According to the CrowdStrike 2026 Global Threat Report, the average adversary breakout time, the window between initial access and lateral movement, dropped to 29 minutes, with the fastest measured at just 27 seconds.

1. Short-Term Containment

Classify the event as a single-user event, mailbox compromise or broad campaign before choosing actions. A single-user event involves one suspicious message or employee interaction with no evidence of unauthorized account access. A mailbox compromise includes suspicious sign-ins, unexplained sent messages, inbox access, forwarding, OAuth activity or credential theft, while a broad campaign affects multiple recipients, domains, mailboxes, devices or business processes.

Create the incident record before changing anything. Capture the original message as an export or forensic copy, including full headers, message ID, sender infrastructure, URLs, attachments, timestamps, authentication results and recipient list. Preserve endpoint telemetry, mailbox audit logs, sign-in records, browser history and relevant chat or payment instructions under an evidence hold.

Wiping a device, deleting a message or revoking every session before documenting the activity that establishes scope destroys the basis for later decisions. When malware is executed, isolate the endpoint from the network while preserving volatile data if the response team has that capability.

For a single-user event, quarantine the message and matching copies, then block the malicious URL, attachment hash, sender address and sending domain where confidence is high. Ask the recipient whether they opened the link, entered credentials, downloaded a file or approved a payment. A reported message that was never opened usually needs message removal, browser-session review and targeted user guidance, while a clicked link, submitted credential or executed attachment forces identity and endpoint investigation before closure.

For a mailbox compromise, restrict the account's ability to send external mail, revoke active sessions and access tokens and disable the account when misuse continues or privileged access is involved. Reset the password through a trusted administrative channel and require MFA re-enrollment whenever the factor, recovery method or device could have been exposed. A password reset alone falls short of eradication, since cyberattackers holding stolen refresh tokens, app permissions or delegated access can return afterward.

For a broad campaign, quarantine messages using stable indicators such as message IDs, attachment hashes, URL reputation, sender infrastructure and campaign-specific subjects. Display names are unreliable, because legitimate senders can be impersonated and compromised accounts send convincing internal mail. Use a staged purge that starts with a review set in a limited group before expanding across the organization.

CISA's 2026 red-team advisory on rapid isolation and cloud-token remediation recommends clear responder authority, endpoint isolation and established procedures for detecting, remediating and revoking access and refresh tokens. Before a mass deletion, account disablement or organization-wide purge, the incident commander and system owner should approve a record documenting:

• The indicator set and affected users;
• Business impact and expected disruption;
• Evidence-preservation status;

• Legal and regulatory considerations;
• Rollback method;
• Expected completion time.

When payment instructions, payroll changes or vendor banking details appear in the messages, finance joins the response and verifies out of band through a trusted number or previously validated contact. No transfer, vendor change or executive request should proceed merely because the message appears to come from a known account.

2. Persistence Eradication

Once immediate spread is contained, the investigation shifts to how the cyberattacker retained access. Start with the mailbox, where persistence survives message deletion and password changes. Review inbox rules, forwarding rules, transport rules, hidden folders, automatic replies, delegated access, shared mailbox permissions, send-as rights and send-on-behalf permissions, then remove rules that hide, redirect, delete or alter security notifications while confirming that legitimate business rules stay intact.

Examine suspicious inbox access through sign-ins, mailbox audit events, IP addresses, device identifiers, user agents, folders accessed, search activity, message reads, downloads and outbound sends. Compare those events against the user's normal geography, work schedule and devices. Search specifically for access to sensitive conversations covering finance, payroll, legal matters, executives, customer data and password resets, and treat those business processes as compromised when the cyberattacker reached payment or identity information.

Inspect app registrations, enterprise applications, service principals and OAuth consent grants. Revoke malicious or unnecessary applications, remove excessive delegated and application permissions, delete unknown client secrets and certificates and review application owners. Mail, file and directory permissions deserve particular attention because they let an application read, write or send messages without an interactive sign-in, so record the application identity and permission set before removal.

Review every authentication path in addition to the primary password. Check additional authentication methods, newly enrolled devices, recovery email addresses, phone numbers, alternate addresses, passkeys, app passwords, legacy protocols and registered authenticator applications. Remove unauthorized methods, require MFA re-enrollment through a trusted process, revoke sessions and tokens after the identity changes and confirm that new sign-ins demand the expected factors and device or location controls.

For a confirmed account compromise, temporary disablement applies when containment cannot be trusted, privileged access is involved or malicious activity continues. Coordinate disablement with the account owner and business manager to prevent unsafe workarounds, and preserve the mailbox and identity audit trail first. Credentials for connected services, shared accounts, mail-enabled applications and password-reset workflows exposed in the mailbox need rotation without interrupting critical operations.

Endpoint and mobile containment follows the evidence. Isolate a workstation when a malicious attachment is executed, credentials were entered into a suspicious site, browser tokens may have been stolen or the device shows command-and-control activity. Place a mobile device under conditional-access restriction or revoke its mail session when it is lost, jailbroken, unmanaged or linked to suspicious sign-ins, and delay reimaging until forensic collection finishes.

Malicious emails, attachments, links and malware come out only after evidence copies are secured. Delete or quarantine confirmed campaign messages, block verified indicators, remove malware from affected endpoints and search for related artifacts across mailboxes, browsers, cloud storage and collaboration tools. Keep hashes, filenames, URLs, headers, screenshots, timestamps and exported messages under the evidence hold, since a clean inbox proves nothing about the wider environment.

3. Organization-Wide Cleanup

Organization-wide cleanup begins once responders understand the campaign's full indicator set and have tested remediation against a controlled group. Search every mailbox, shared mailbox, archive, mobile client and quarantine for the malicious sender, domain, URL, attachment hash, message ID, reply-to address and related lures. Extend the search to alternate addresses and aliases, which cyberattackers target precisely because users do not recognize them as separate accounts.

Use a reversible purge where the mail platform supports it, retain a deletion log and record how many messages were removed from each mailbox. Ambiguous matches belong in quarantine for analyst review instead of automatic deletion. Approval remains mandatory before an organization-wide purge, and the incident commander should confirm that legal hold, records retention, regulatory notification and business continuity requirements are satisfied.

Sender and domain controls apply at the narrowest effective scope. Block a malicious domain when its infrastructure is clearly hostile or disposable, while avoiding a block on an entire legitimate provider when only one address, subdomain or URL is involved. Add URL and hash blocks to endpoint, browser and mail controls, test for false positives and monitor attempted access.

Because cyberattackers rotate domains and files, behavioral indicators need retention alongside static ones: unusual reply-to changes, urgent payment language, newly registered domains, abnormal attachment types and atypical login patterns. Those patterns outlive any single campaign and feed detection tuning. According to Verizon's 2026 Data Breach Investigations Report, ransomware or extortion appeared in 88% of breaches at small and midsize businesses (SMBs), and these organizations often face unpatched devices, compromised credentials, and limited recovery capacity.

Complete a mailbox access review for executives, finance, payroll, administrators, help desk staff and every user who received the campaign. Confirm that forwarding rules, delegated access, OAuth grants, app registrations, additional authentication methods, alternate addresses and suspicious inbox access are clean. Reconcile sent items, deleted items and audit logs to identify messages the cyberattacker removed, then contact external recipients through a verified channel when the compromised account sent malicious payment, credential or data-sharing instructions.

Closure criteria differ by event type. A single-user event closes once the message is removed and the account and endpoint show no unauthorized activity, while a mailbox compromise requires completed identity remediation, token revocation, application review and business-process verification. A broad campaign additionally requires a tenant-wide search, approved purge, indicator blocking, affected-user notification and heightened monitoring for recurrence.

Document every action, approval, exception and residual risk. Confirmed indicators and observed behaviors should feed future phishing response and email remediation workflows, and the runbook then gets tested with a controlled exercise. Clear ownership, evidence rules and approval thresholds cut the minutes a responder spends asking who is allowed to act.

Manual mailbox-by-mailbox cleanup measures response in hours while cyberattackers measure their breakout window in minutes. Adaptive Security removes confirmed malicious mail across every affected inbox within seconds.

Explore the platform

Which Microsoft 365 and Google Workspace Actions Belong in the Email Incident Response Runbook?

An email incident response runbook has to translate broad containment steps into precise Microsoft 365 and Google Workspace actions that administrators can execute under pressure. Microsoft 365 concentrates response across Microsoft Defender, Exchange Online, Microsoft Entra ID and Microsoft Purview, while Google Workspace distributes comparable work across the Admin console, Gmail investigation tools, the security investigation tool and endpoint controls. Each platform needs defined privileges, approval gates, preserved evidence and a fallback procedure, since message deletion, token revocation and password changes can disrupt legitimate business activity.

Microsoft 365 Action Mapping

Microsoft 365 procedures should name the administrative plane, required role and evidence output for every action. A responder can begin in Microsoft Defender by searching matching sender addresses, subjects, URLs, attachment hashes, message IDs or authentication results, then move to Microsoft Purview or Exchange Online for broader mailbox discovery and remediation. Permission mapping belongs in the published runbook, because investigators cannot assume that every administrator can search, export or remediate messages.

Message search and purge stay controlled containment actions in preference to automatic first responses. The runbook should require responders to preserve the search query, match count, sample headers, message IDs and timestamps before requesting removal. Once a message is confirmed malicious, an authorized administrator can place it into remediation or purge it according to tenant policy.

While a message remains suspicious and unconfirmed, quarantine, temporary delivery restrictions or user notification preserve investigation options without destroying evidence. Recall is unreliable containment, because its outcome depends on message state, recipient context and tenant behavior. According to IBM's Cost of a Data Breach Report 2026, phishing remained the top initial attack vector for the fourth consecutive year, with voice and SMS phishing (vishing/smishing) involved in 17% of breaches and carrying the highest average breach cost.

Audit-log review should cover mailbox access, message operations, inbox-rule creation, forwarding changes, sign-in activity, consent grants, role changes and administrator actions. Capture the actor, target account, source IP address, user agent, timestamp, operation name and correlation identifier. Comparing those events against the original email timeline shows whether a cyberattacker only delivered a message or also read mail, created persistence and sent further BEC messages from the account.

Risky sign-in investigation belongs beside mail review instead of a separate identity appendix. Check unfamiliar locations, impossible-travel indicators, new devices, legacy authentication, unfamiliar user agents, multifactor authentication changes and sign-ins immediately before or after the email event. Session and refresh-token revocation contains active access, though the runbook must state which sessions are affected, which applications require reauthentication and whether revocation interrupts critical workflows.

Password reset and MFA re-registration need separate approval language. Reset the password when credential compromise is credible, while treating active sessions as a distinct problem that the reset does not solve. Require the user to re-register MFA through a verified channel whenever an authenticator, phone number or recovery method is suspect, and record who approved the action, which factors were removed, which factors were enrolled and how the user's identity was verified.

Mailbox persistence checks should include inbox rules, transport rules, forwarding addresses, delegates, shared-mailbox permissions, send-as rights and send-on-behalf rights. Export each rule definition before disabling it, including conditions, actions, destination addresses and creation or modification time. Transport and routing-rule changes need separate review, because they affect many users and hide messages without touching individual mailbox settings.

Forensic artifacts come out before the incident closes. Preserve original message files, full headers, URLs, attachment metadata, audit results, sign-in records, rule exports, identity changes, remediation results and administrator command history. The workflow connects to phishing response and email remediation capabilities once the runbook has documented the evidence and approval controls that make those actions defensible.

Google Workspace Action Mapping

Google Workspace runbooks should map each action to the Admin console area, investigation privilege and evidence format. Gmail message searches start with sender, recipient, subject, date, message ID, attachment or URL indicators, and the record should document whether results include delivered, quarantined, spam, trash or deleted messages. Search and purge follow a confirmation step capturing the query, result count, representative headers and affected users before deletion or quarantine.

Administrators should distinguish quarantine from deletion. Quarantine holds messages for review and preserves the option to release a false positive, while deletion removes access and can complicate later analysis depending on retention and Google Vault settings. The runbook should specify when to quarantine, when to delete, when to notify recipients and when to consult legal, privacy or records-management owners about preservation requirements.

Audit review covers Gmail message activity, login events, administrator activity, OAuth grants, application access, forwarding configuration, filters, delegation and changes to recovery or multifactor settings, captured with the account, event type, timestamp, IP address, client details and exported report identifier. Those records reveal whether a cyberattacker created a Gmail filter that archives or marks messages as read, configured automatic forwarding, added a delegate or granted an external application access to mail and files.

Risky sign-in investigation should examine unfamiliar devices, locations, browser sessions, recovery changes and authentication events that break the employee's normal pattern. Record session revocation and password reset as separate actions, since changing a password leaves no record of which browser sessions, application sessions or third-party grants remain active. Revoke application access when an OAuth application is untrusted, excessive or newly authorized during the incident, preserving the application name, client identifier, scopes, grant time and affected user before removal.

MFA re-registration requires a verified identity check and a documented recovery path, so responders confirm whether the factor itself was compromised, whether a new factor was added and whether the user can be reached through an alternate channel. Mobile-device controls cover device inventory, managed-device status, account-wipe or lock authority, work-profile removal and the evidence each action generates.

Mailbox and routing review must include Gmail filters, forwarding addresses, delegation, routing rules, compliance rules and domain-level delivery settings. Export each relevant configuration before changing it. A domain routing rule reaches many recipients, so its approval owner should differ from the owner for an individual mailbox filter, and Google Vault retention requirements need checking before responders delete content.

Permission, Approval and Fallback Safeguards in the Email Incident Response Runbook

A practical comparison shows what an administrator can do, who approves it, what evidence survives and how the action reverses. The table below belongs in the operator appendix of the email incident response runbook, where responders can reach it without scrolling through narrative guidance. Console labels and permission boundaries change, so each row needs revalidation whenever the tenant configuration changes.

Destructive actions should require two-person approval whenever an incident involves executives, regulated data, shared mailboxes or organization-wide routing. API permissions, administrative roles, retention settings and tenant policies all need verification before publication.

When the mail platform, identity provider or response tooling is unavailable, a documented degraded-mode procedure keeps containment moving. Responders compile the recipient list manually from sent-mail records or business owners, preserve message files and screenshots with synchronized timestamps and contact affected users through approved alternate communications. Every manual action goes into a temporary incident ledger, reconciled against platform logs and final exports once systems return.

Console permissions that nobody tested fail at the moment an administrator needs to purge a live campaign. Adaptive Security removes malicious mail across Google and Microsoft environments through API integration.

Book a demo

How Should an Email Incident Response Runbook Preserve Evidence, Recover Operations and Communicate?

An email incident response runbook should move the organization from containment to trustworthy recovery without destroying evidence or restoring a compromised pathway. Responders preserve the record, validate every affected identity and device and communicate only what each audience needs in order to act safely. Recovery stays incomplete until business workflows operate normally and residual risk is documented in the incident file.

1. Preserve Evidence and Establish Chain of Custody

Evidence preservation starts before cleanup. Place an evidence hold on relevant mailboxes, identity systems, endpoints, cloud applications and payment systems, and assign one incident lead to maintain the chain of custody. Record who collected each item, when, from which system, using what method, where it is stored and every subsequent transfer or access event.

Capture the original messages, complete headers, attachments, embedded URLs, file hashes, mail-flow logs, authentication telemetry, screenshots, user statements and endpoint findings. Preserve mailbox rules, forwarding changes, delegated access, OAuth grants, administrative actions and payment records, since these details show how the incident progressed and what the cyberattacker attempted. Create forensic copies where possible, calculate hashes for collected files and protect originals from alteration.

Retention limits require discipline. Preserve enough message telemetry to reconstruct sender authentication, delivery paths, recipient actions, URLs, attachment metadata, rule changes and identity events while holding back unnecessary message bodies. Minimize sensitive content in working copies, restrict access by role, encrypt the evidence store and log every retrieval.

NIST's Incident Response Recommendations and Considerations for Cybersecurity Risk Management, published in 2025, places incident response inside broader cybersecurity risk management, which reinforces that evidence handling must support both immediate action and later governance. The same file supports insurance claims, regulator questions and any civil proceeding that follows.

2. Verify Recovery Before Restoring Trust

Recovery verification tests each affected control instead of assuming a password reset ended the incident. Confirm account ownership, revoke active sessions, rotate passwords and recovery methods, re-enroll or validate MFA authentication, remove unauthorized mailbox rules, review delegated access and revoke suspicious OAuth grants. Check sign-in history, identity telemetry, conditional-access decisions and administrator activity for evidence of persistence.

Validate affected devices through endpoint findings, security-tool status, browser extensions, credential stores and local mail configurations. Restore mailboxes from trusted records only after confirming that malicious rules, forwarding addresses and delegated permissions are gone. Recheck mail-flow controls, quarantine behavior, reporting channels and administrative roles before releasing the account back to its owner.

Operational recovery also covers the business workflow the cyberattacker targeted. Independently confirm supplier bank details, payment instructions, payroll changes, purchase orders and executive approvals through a known channel. Run a controlled test of authentication, mailbox delivery, reporting and payment controls, then obtain signoff from security, IT and the process owner.

Ransom demands complicate this stage when malware follows the email. According to Verizon's 2026 Data Breach Investigations Report, 69% of victims refused to pay ransoms in 2025, up from 65% the prior year, and the median payment fell to $139,875 from $150,000. Recovery planning therefore assumes restoration from preserved backups and validated identities as the primary path.

3. Coordinate Communications and Complete the Post-Incident Report

Communications should match each recipient's decision rights. Employees need the indicators to report, the actions to avoid and the approved verification channel, while executives need business impact, decisions, exposure and residual risk. Customers and suppliers need confirmed effects, protective steps and reliable contacts.

Regulators, insurers and law enforcement need accurate timelines, evidence status, legal notifications and points of contact. Unverified scope, investigative techniques, personal data, credentials, internal control gaps and attribution guesses stay out of every external statement. Route those statements through legal, privacy and communications leaders, and preserve one approved timeline so different audiences never receive conflicting accounts.

Notification follows law, contract, insurance policy or material risk. The email incident response runbook closes with a post-incident report covering the cause, timeline, scope, affected identities and systems, cost, response actions, control failures, key decisions, residual risk and corrective actions.

Every corrective action needs an owner and a deadline, including rule hardening, access review, payment verification, employee guidance, detection improvements and runbook changes. A corrective-action register with named owners means the next incident starts with tested controls instead of a rediscovery of the same gap.

Adaptive Security connects each confirmed email cyberattack to the employee it reached, assigns targeted cybersecurity awareness training and updates that employee's risk score in the same reporting cycle.

Take a self-guided tour

How Should an Email Incident Response Runbook Handle BEC, AI-Generated and Modern Email Cyberattacks?

An email incident response runbook must treat BEC, AI-generated messages and coordinated social engineering as identity and transaction cyber threats in place of ordinary phishing. Verification has to cover identity, payment authority, message context and every channel reinforcing a request. A deleted email never ends the incident when follow-up calls, text messages or hijacked threads keep the fraud credible.

How Should the Runbook Handle BEC and Payment Fraud?

BEC requires a financial-control response alongside the mailbox investigation. The runbook should preserve the message, headers, attachments, URLs, authentication results, related mailbox activity and conversation history immediately. Analysts then identify whether the request involves a wire transfer, changed banking details, payroll, gift cards, tax documents, vendor records or privileged access, and classify it as a high-risk transaction however familiar the sender appears.

Executive impersonation and vendor fraud share one escalation path. A CEO asking to bypass approval, a supplier requesting an invoice change or a payroll manager seeking a direct-deposit update requires verification through a contact record the organization already holds. The phone number, reply address, signature, QR code and meeting link supplied in the suspicious message are all unusable for that purpose.

Finance joins the response as soon as money or account details are involved. The team attempts a payment recall, contacts the originating and receiving banks, freezes or reviews pending transfers and confirms vendor changes through a known contact in the procurement department. Preserve the original request and approval trail for legal, insurance, regulatory and law-enforcement reporting.

The financial exposure justifies that speed. According to the FBI Internet Crime Complaint Center's 2025 Internet Crime Report, BEC losses reached $3.04 billion in the U.S. alone. Every hour of delay reduces the chance that a receiving bank can freeze or reverse the transfer.

How Should the Runbook Handle AI-Assisted and Evasive Content?

AI-generated phishing emails remove many traditional warning signs, so polished grammar, correct branding, natural tone and a familiar writing style carry no evidential weight. Analysts should compare the request against the sender's normal behavior, inspect authentication and delivery signals, identify unusual urgency or secrecy and search for related messages across the organization.

The investigation must cover image-based lures, QR-code phishing, newly weaponized links, thread hijacking and relationship-aware social engineering. A malicious QR code moves the interaction from a monitored corporate inbox to a personal mobile device, an image hides a call to action from text-based analysis and a hijacked thread inherits genuine correspondence and trusted context. Each is a distinct delivery mechanism under identical escalation, containment and verification requirements.

A defined phish triage workflow gives analysts a consistent path for preserving reported messages, searching for matching indicators and removing malicious content across affected inboxes. That process extends beyond email whenever the evidence points to a coordinated campaign across voice, SMS or collaboration platforms.

Deepfake-linked requests deserve particular handling because an email is often only the first signal. In 2024, criminals used a deepfake video call to induce an employee in Hong Kong to authorize approximately $25 million in transfers, as the 2024 Reuters report on the Arup deepfake fraud documents. The runbook should therefore capture related calendar invitations, voice calls, video meetings, SMS messages and collaboration-platform activity as one case before closing the incident.

How Should Cross-Channel Verification Work?

Cross-channel verification is the control that stops a plausible message from becoming an approved transaction. Out-of-band confirmation applies to finance, payroll, privileged-access, executive, vendor-bank-change and sensitive-data requests. The verifier initiates contact using a trusted directory, vendor master record, HR system or previously validated phone number, then documents who confirmed the request, when confirmation occurred and which independent details were checked.

The runbook should define a clear employee reporting path. Employees who report a suspicious email, unexpected text, vishing call or deepfake request deliver an early-warning signal, and the security team preserves the report, searches for matching indicators, removes malicious messages and explains concisely what made the request risky.

Phishing simulations and role-specific cybersecurity awareness training reduce repeat exposure by rehearsing the decisions employees make under pressure. Finance teams practice payment verification, executives practice impersonation resistance and help-desk staff practice privileged-access checks. Reviewing those results without blame, then adjusting controls and scripts around the behavior that created exposure, keeps the verification step from being skipped when the request looks routine.

What stops a finance approver from acting on a convincing vendor-bank-change request at 4:55 p.m. on a Friday? Adaptive Security rehearses that moment across email, SMS and voice.

Take a self-guided tour

How Should an Email Incident Response Runbook Be Tested and Improved?

An email incident response runbook needs a defined testing cadence, a measured handoff at every step and an owner with a deadline for each gap. Tabletop exercises, controlled phishing reports, breach-and-attack simulations, mailbox-purge drills, fallback-channel tests and permission reviews validate human decisions alongside technical execution. Review follows incidents, platform changes, new cyberattack patterns, regulatory changes and failed exercises so the document stays operational.

1. Establish Effectiveness Metrics and Baselines

A baseline comes before any change to the runbook. Teams measure time to report, time to detect, time to classify, time to contain, time to eradicate and time to recover. Click rates, credential-submission rates, report quality, false positives, duplicate-investigation rates, analyst workload, automation accuracy, messages purged, users reached and unresolved residual risk complete the picture.

Segment results by role, department, seniority, location and channel. Finance users handling vendor-payment requests should not be measured against employees who rarely receive external mail, and email, mobile, voice, SMS and collaboration results stay separate when an incident crosses channels. That segmentation shows whether the process fails during reporting, triage, containment or recovery.

Each metric needs a definition before collection. "Time to detect" runs from the first validated signal to analyst recognition, while "time to contain" runs from confirmation to completed mailbox action. Report quality is scored on whether the employee included the original message, sender details, requested action and any link or attachment.

Privacy protections belong in the measurement design through role-based dashboard access, aggregated management reporting, retention limits for individual data and exercise records that exclude unnecessary message content. As NIST computer scientist Julie Haney and University of Maryland Associate Professor Wayne Lutters concluded in their peer-reviewed analysis published in Computer (October 2020), compliance metrics do not tell the whole story and fail to measure the effectiveness of the program in a sustained change in employee attitudes and behaviors.

A baseline creates a defensible improvement target. When a drill produces a 22-minute classification time, the team sets a lower target, identifies the bottleneck and tracks performance across later exercises. Numbers without an owner produce dashboards nobody acts on.

2. Design Exercises That Test the Full Response Path

A short tabletop each quarter and a technical breach-and-attack simulation at least twice a year keep the email incident response runbook current. Scenarios should reflect current exposure, including a BEC request, malicious attachment, credential-harvesting page, compromised supplier, vishing call that confirms an email request or smishing message that follows the initial email. Exercises measure whether employees use the reporting path, preserve evidence, verify unusual requests and escalate appropriately, rather than grading them on instant recognition of every lure.

Each exercise should test these control points:

• Send controlled phishing reports to selected roles with clear reporting instructions and a known exercise marker for facilitators;
• Run a mailbox-purge drill confirming that analysts can identify affected users, remove messages, preserve evidence, reverse an incorrect action and document completion;
• Test a fallback channel such as a phone tree, approved messaging system or out-of-band status page when email is unavailable or untrusted;
• Review permissions for reporting tools, mailbox search, purge actions, audit logs and emergency communications, removing stale access and verifying that at least two authorized people can perform critical actions;
• Inject duplicate reports and false positives to measure triage quality, automation accuracy, duplicate-investigation rates and analyst workload.

Record users reached, messages purged, time spent, failed handoffs and financial losses prevented within the scenario's assumptions. Linking the reporting workflow to phishing response and phish triage practices lets employees and analysts rehearse the same path they will use during a live event. The Cybersecurity and Infrastructure Security Agency's 2025 year-in-review findings reported that 94% of participants in 148 cyber and physical security exercises said their preparedness improved.

3. Convert Findings Into Updates, Owners and Deadlines

A review within five business days of every exercise or incident separates root causes from symptoms. A slow purge might reflect an unclear approval rule, excessive permissions, incomplete API coverage or an analyst working without a reliable affected-user list. Naming the cause determines whether the fix belongs in documentation, tooling or authority.

Every finding receives one accountable owner, a severity rating, a remediation deadline and a verification test. The runbook changes when an incident exposes a missing decision, a platform change alters a procedure, a new cyberattack pattern introduces another channel, a regulatory change modifies evidence requirements or an exercise fails its success criteria.

Contact lists, escalation thresholds, vendor details, retention rules, mailbox-search syntax, automation thresholds and fallback communications all need rechecking after every material change. A version history should record what changed, why it changed, who approved it and which exercise validated the update. Failed steps get re-run instead of being marked complete after a meeting, so the next drill starts from a verified position.

Run the tabletop, then measure what employees actually do when the next lure arrives, using Adaptive Security's multi-channel phishing simulations, reporting analytics and automatic role-based coaching assignments.

Explore the platform

How the Email Incident Response Runbook Connects to Human Risk Management

Email response is a core control in human risk management because employee decisions determine whether a cyberattack stops or spreads. Response data shows where employees need clearer reporting guidance, stronger verification habits and realistic practice across email, voice and messaging channels. The email incident response runbook therefore produces training inputs alongside containment records.

What Response Signals Reveal About Human Risk

Email response generates behavioral signals in addition to security alerts. A delayed report, opened attachment, credential submission, forwarded suspicious message or successful out-of-band verification each describes a different learning need. Treating every event as a generic user mistake hides the difference between unclear guidance, workflow friction and a sophisticated spear phishing cyberattack.

Response controls and cybersecurity awareness training controls serve different purposes. Response controls quarantine messages, revoke sessions, reset credentials, block malicious indicators, preserve evidence and notify affected teams, while cybersecurity awareness training teaches employees to recognize pressure tactics, report suspicious activity and verify unusual requests. One contains the current event and the other reduces the likelihood and impact of recurrence.

That separation also protects employee privacy. Security teams should aggregate patterns by department, role, cyberattack type and workflow before examining individual records. Anonymized telemetry can show that finance employees struggle with vendor payment verification or that executives receive frequent impersonation attempts without turning learning data into personnel judgments.

Useful signals extend past clicks. Track time to report, report accuracy, time to containment, verification-channel use, repeat exposure and the cyberattack path involved. An employee who reports a malicious email within two minutes presents a different risk profile from someone who clicks and then alerts the security team, and the coaching should match the behavior.

How Can Response Data Drive Targeted Behavioral Change?

Targeted behavioral change starts with a specific failure mode. Employees who report suspicious emails without distinguishing spam from credential theft need short reporting and classification microlearning. Finance staff who approve urgent payment changes without independent confirmation need role-specific BEC exercises and documented practice with the verification path, while a help desk receiving convincing voice requests needs vishing scenarios that test identity checks.

Practice should cover the channels cyberattackers combine, since spear phishing can establish context, smishing can create urgency and vishing can supply apparently personal confirmation. A deepfake video or AI-generated lure reinforces the request through a trusted face or voice. Exercises should mirror those sequences while avoiding sensitive personal data and clearly separating phishing simulations from real incidents.

An AI-native cybersecurity awareness training platform can connect multi-channel phishing simulations, OSINT-informed personalization, automated phish triage and a unified human-risk view. That connection requires explicit governance covering which OSINT fields are relevant, which inferences are prohibited, who holds access and how behavior data supports risk reduction.

The resulting risk score should guide action without labeling people permanently. A high score can trigger targeted microlearning, additional phishing simulations or a manager-supported review of verification procedures, and improvement should lower the score when behavior changes. Security leaders can use human risk management practices to connect exposure, phishing simulation outcomes and response behavior alongside professional judgment.

How Should Governance and Reporting Use These Signals?

Governance turns response telemetry into accountable decisions. A monthly review should connect incident volume with report rates, median time to report, containment time, repeat failure patterns and cybersecurity awareness training completion by role. Board reporting should emphasize exposure and trend direction, because "finance reduced repeat payment-verification failures" supports a clearer risk discussion than a completion percentage.

Board engagement correlates with resilience. According to the World Economic Forum's 2026 Global Cybersecurity Outlook, 52% of highly resilient organizations indicate that board members receive regular cybersecurity updates, and 48% report that board members are actively engaged with cybersecurity issues. Email incident metrics give those updates something concrete to discuss.

Executives require a separate exposure review, since their identities, voices and public schedules support highly personalized impersonation. That review covers publicly available exposure, recent impersonation attempts and the effectiveness of second-channel verification, and it produces a control plan covering approval thresholds, callback procedures and delegated authority.

The strongest operating model creates a feedback loop: response contains the current event, triage identifies the cyberattack pattern, anonymized data reveals the behavioral gap, targeted cybersecurity awareness training rehearses the safer action and a later phishing simulation tests whether the gap is closing. Each cycle gives the next reported message a shorter path to containment.

Which reported email actually changed an employee's behavior last quarter? Adaptive Security converts each detected cyberattack into role-based coaching and an updated risk score before the next campaign arrives.

Book a demo

What Should the Final Email Incident Response Runbook Checklist Include?

A final email incident response runbook checklist converts detection into assigned actions, approval gates and recoverable evidence. Each item carries an owner, a status and an evidence location, so readiness can be demonstrated rather than asserted. NIST's Computer Security Incident Response Guide, SP 800-61 Rev. 3 (2025) organizes incident response around detecting, responding to and recovering from cybersecurity incidents, while the email-specific rows below carry the organization's own owners and permissions.

What Must Be Confirmed Before an Incident?

This section is completed before the runbook is approved for production use. Each row should be testable during a tabletop exercise, access review or controlled phishing simulation. A row that cannot be demonstrated with current administrator accounts stays open regardless of how thoroughly the procedure is written.

What Must Be Recorded During Investigation and Containment?

During an active incident, the checklist prevents two failures: acting before evidence is preserved, and containing one mailbox while the same campaign continues elsewhere. Every row below produces an artifact that the incident commander can review in real time. Missing artifacts signal that an action was taken outside the approved path.

What Must Be Verified After Recovery and Closure?

Recovery is incomplete until the organization proves the cyber threat is inactive and affected employees know what to do next. The final review measures technical containment alongside human response, which is why user follow-up sits in the same table as validation queries. Review dates belong in the record so the corrective actions survive the incident that produced them.

Testing this checklist against realistic spear phishing, vishing follow-ups and BEC scenarios exposes gaps in permissions, evidence handling and employee guidance while there is still time to correct them. An organization that can produce every artifact in the right-hand column has a runbook rather than a policy document.

Checklists prove readiness only when someone has actually run them under pressure. Adaptive Security exercises reporting, triage and response across email, SMS and voice on a repeatable cadence.

Take a self-guided tour

Strengthening Email Incident Response With Adaptive Security

Security teams measure success by how quickly a reported message becomes a contained incident with a clean evidence trail. Adaptive Security supports that outcome by detecting advanced phishing and BEC that native filters miss, then removing confirmed malicious mail across every inbox it reached. Cloud Email Security connects to Google Workspace and Microsoft 365 through API integration, so detection and remediation start without MX record changes or mail-flow disruption.

Detection alone leaves the human layer untouched, which is where most email incident response runbook activations begin. Every cyberattack Adaptive Security detects feeds automated phish triage, employee risk scores and targeted cybersecurity awareness training, so the message that reaches an employee becomes the lesson assigned to that employee. Reported phishing also improves detection accuracy, which shortens the queue analysts work through during the next campaign.

Governance obligations sit beside that operational work. Compliance Training documents policy coverage for auditors and regulators, while AI Governance surfaces shadow AI use and personal-account data risk that widen the same exposure an email incident response runbook is written to contain. Together they give security leaders one record of detection, response and human behavior.

Detection, remediation, triage and cybersecurity awareness training belong in one record instead of four consoles. Adaptive Security connects every detected email cyberattack to the employee it targeted.

Book a demo

Frequently Asked Questions About the Email Incident Response Runbook

What Should Trigger an Email Incident Response Runbook?

An email incident response runbook should activate when a message presents credible risk of credential theft, malware, account compromise, data exposure or financial fraud. Triggers include a user report, a confirmed malicious URL or attachment, multiple recipients, credential submission, suspicious sign-in, mailbox-rule creation, unexpected OAuth consent, payment-change request, malware execution or a high-confidence security-tool alert. CISA advises organizations to document incident handling and promptly report phishing incidents in its Phishing Guidance published in 2023. Severity criteria then determine whether the event needs help-desk triage, identity containment, legal review, finance escalation or organization-wide response.

How Long Should It Take to Respond to a Phishing Email Incident?

A phishing email incident should receive initial human or automated review within minutes, with containment urgency set by clicks, credential entry, malware execution, privilege and spread. A reported message with no interaction needs rapid triage and recipient scoping, while credential submission, suspicious sign-in, malware execution or privileged-account exposure warrants immediate identity and endpoint action with evidence preserved. Measurable targets for time to report, classify, contain, eradicate and recover work better than one universal deadline. CISA's phishing guidance directs people to report suspected phishing, which supports rapid intake as the operational starting point.

What Is the Difference Between Phishing and BEC in an Email Incident Response Runbook?

Phishing is a broad technique that uses deceptive messages to obtain credentials, deliver malware or provoke an unsafe action, while business email compromise (BEC) targets trusted relationships, payment workflows and sensitive business decisions. The runbook treats phishing as a message and user-interaction investigation, then adds BEC controls when an executive, supplier or finance process is impersonated or a mailbox is compromised. Payment and account-change requests require verification through a trusted out-of-band channel before any approval. That distinction determines whether finance, legal and the bank join the response in the first hour.

Should an Organization Disable an Account After a User Clicks a Phishing Link?

Automatic disablement after every phishing click causes unnecessary disruption. The organization should first assess whether the user entered credentials, opened a file, approved OAuth access, triggered a download or generated suspicious sign-in activity. Credential exposure or confirmed compromise supports rapid password reset, session and token revocation, MFA review, mailbox-rule inspection and temporary account restriction or disablement, while a click without credential entry or execution can justify monitoring, targeted containment and user support. CISA advises users to change passwords immediately after suspected exposure in its business guidance on phishing, and relevant evidence should be preserved before destructive cleanup.

How Often Should an Email Incident Response Runbook Be Tested and Updated?

An email incident response runbook should be exercised at least annually and updated after every incident, failed exercise, major platform change, new cyberattack pattern or material regulatory change. Tabletop exercises, controlled phishing reports, mailbox-purge drills, fallback-channel tests and permission reviews expose gaps in roles, access, evidence handling and escalation. NIST's SP 800-84 guidance covers designing, conducting and evaluating test, training and exercise events.

Does AI Use by Employees Affect Email Incident Response?

Employee AI use widens the evidence an email incident response runbook has to consider, because sensitive message content, customer data and internal instructions can leave the organization through unapproved tools during an investigation. According to the National Cybersecurity Alliance's 2025–2026 Oh Behave! The Annual Cybersecurity Attitudes and Behaviors Report, 43% of employed participants admitted to sharing sensitive work information with AI tools. Runbooks should therefore state which analysis tools are approved for message content, which data may be submitted externally and how AI-assisted triage decisions are recorded.

A reported message is only useful when someone owns it, contains it and closes the loop with the employee who reported it. Adaptive Security runs that path end to end.

Explore the platform