Email Incident Response Examples: Practical Playbooks for Phishing, BEC and Malware Investigation and Recovery

Email incident response examples show how security teams identify, investigate and contain malicious messages before phishing, BEC or malware causes wider damage.

This practical guide helps security and IT teams distinguish a suspicious email from a confirmed compromise or reportable breach, assign severity, preserve evidence and coordinate recovery.

The playbooks below cover scoping phishing campaigns across mailboxes, investigating suspicious sign-ins and hidden forwarding rules, responding when an employee clicks a link or opens an attachment, and limiting financial loss during business email compromise (BEC).

Microsoft 365 message trace, mailbox audits, sign-in logs, headers, URLs and attachment data give responders the evidence needed to determine who received a message, whether an account was accessed and what persistence remains.

A formal response plan also connects technical containment with employee reporting, stakeholder communication, phishing simulations and measurable readiness. These examples supply a clear framework for protecting accounts, mailboxes, devices and sensitive data while treating employees as skilled partners in detection.

Request a demo of Adaptive Security’s multi-channel phishing simulations to measure how quickly employees recognize, report and escalate a malicious email.

Email Incident Response Examples: What Each Incident Teaches Security Teams

These email incident response examples show how security teams identify, contain, investigate and recover from malicious or suspicious email events. Each case functions as a practical email incident response playbook, showing which signal should trigger action and which facts determine severity.

NIST’s 2025 SP 800-61 Rev. 3 guidance treats preparation, detection, response and recovery as one risk-management capability rather than disconnected technical tasks.

What Does Email Incident Response Mean?

Email incident response begins when a message creates credible risk to an account, device, payment process or sensitive information. That risk can come from a malicious attachment, credential-harvesting page, business email compromise (BEC), mailbox takeover, unauthorized forwarding rule, OAuth abuse, spoofed sender or accidental data exposure. The message only starts the sequence. The incident includes every action and consequence that follows.

A phishing attempt is not automatically a confirmed compromise. A suspicious email that reaches an inbox but is deleted without interaction is an attempted attack.

A security event is a broader observable occurrence, such as a user clicking a link, reporting a message or an email system detecting an unusual forwarding rule. A confirmed compromise exists when evidence shows that a cyberattacker obtained credentials, accessed a mailbox, executed malware, changed account settings or used an identity to send messages.

A reportable breach requires a separate determination. It generally involves unauthorized access to, acquisition of or disclosure of protected information that triggers legal, regulatory, contractual or customer-notification duties. Security teams should not label every phishing message a breach, but they should preserve evidence until privacy, legal and compliance teams determine whether reporting obligations apply.

This distinction prevents two costly failures. Treating every suspicious email as a breach overwhelms responders and creates unnecessary escalation. Treating a successful login or mailbox-rule change as “just phishing” gives cyberattackers time to search conversations, impersonate executives and redirect payments. A written decision path keeps the response proportional without allowing uncertainty to become inaction.

A formal plan should define who owns triage, who can disable an account, who contacts affected users, when legal counsel joins the investigation and how evidence is retained. Documenting those authorities in advance prevents responders from negotiating permissions during a live incident.

Email security incidents usually fall into several connected patterns:

• Malicious message delivery: A phishing email, spear phishing message, spoofed invoice or QR-code lure reaches one or more users.
• Credential theft: A user submits a password, multifactor authentication code, session cookie or recovery detail to an attacker-controlled page.
• Malware delivery: A recipient opens a weaponized attachment, enables unsafe content or runs a downloaded payload.
• BEC: A cyberattacker impersonates an executive, supplier or finance contact to request a payment, payroll change or sensitive document.
• Mailbox takeover: Stolen credentials or an exposed session allow unauthorized access to email, contacts, calendar data and existing conversations.
• Unauthorized forwarding: A cyberattacker creates a rule that silently copies messages to an external address or diverts payment-related correspondence.
• OAuth abuse: A user grants a malicious application access to mail, files or contacts without directly disclosing a password.
• Data exposure: An employee sends confidential information to the wrong recipient, replies to a cyberattacker or shares a document through a compromised account.

Each pattern requires a different containment action. Deleting the original message does not remediate a mailbox takeover. Resetting a password does not remove an OAuth grant or forwarding rule.

Blocking a sender does not recover funds sent after a fraudulent invoice request. The incident record must connect the initial message to every affected identity, system and business process.

Which Email Events Require Escalation?

Escalation is necessary when an email event moves beyond exposure and creates evidence of interaction, access or impact. Security teams should establish those triggers before an incident occurs because waiting for certainty during a live attack creates inconsistent decisions and delays containment.

At minimum, escalate when a user clicks a suspicious link and enters credentials, opens an attachment that executes code, approves an unexpected MFA prompt, grants an unfamiliar OAuth application, reports a suspected BEC request or confirms that a cyberattacker impersonated an internal account.

Escalate immediately when a mailbox shows unfamiliar sign-ins, deleted security alerts, new forwarding rules, new inbox rules, altered recovery details or sent messages the account owner did not write.

The number and identity of affected users also change the response. A single quarantined message can remain a help-desk matter when no one interacted with it. The same campaign becomes an incident when it targets finance, executives, administrators, privileged service accounts or a large employee group. A message sent from a compromised mailbox requires broader searching because recipients may trust the familiar address and existing conversation history.

Financial requests deserve a separate escalation path. BEC commonly relies on urgency, authority and procedural shortcuts rather than malware. The FBI Internet Crime Complaint Center’s 2025 Annual Report lists business email compromise among the major reported cybercrime loss categories, making payment verification and rapid bank-contact procedures part of email response rather than finance operations alone.

Escalation should also include possible sensitive-data exposure. Examples include a customer database sent to the wrong recipient, legal documents accessed through a compromised mailbox, employee records attached to a fraudulent reply or regulated information copied through an unauthorized application. Security teams should preserve message headers, URLs, attachment hashes, authentication logs, sign-in records, mailbox audit data, OAuth consent details and relevant endpoint evidence before making destructive changes.

The most useful email incident response examples answer five operational questions:

1. 1What was the initial reliable signal? A user report, mail-control alert, sign-in anomaly, payment request or data-loss alert.
2. 2Who interacted with the message? Identify recipients, clickers, credential submitters, attachment openers and users who approved access.
3. 3What access followed? Check authentication, mailbox searches, forwarding rules, OAuth grants, sent mail and cloud activity.
4. 4What business process was targeted? Determine whether the incident involved payments, payroll, procurement, customer data or executive communications.
5. 5What action follows? Contain accounts, remove persistence, notify stakeholders, recover assets and provide targeted training.

Employees are essential detection partners in this process. A fast report can expose a campaign before technical telemetry is complete. Teams should therefore make reporting simple and treat mistakes as signals for skill-building rather than grounds for blame. A Phish Triage workflow can classify reported messages, coordinate remediation and focus analyst attention on events that show real exposure.

How Should Teams Classify Email Incident Severity?

Severity should reflect demonstrated impact. The visual polish of a message carries little weight in that judgment. A polished executive impersonation message deserves attention, but a plain-looking lure that produced a privileged-account login represents the higher immediate risk. Classification should combine user behavior, account access, scope, business impact and data sensitivity.

A practical model uses four levels:

Low severity covers blocked or reported messages with no user interaction, no successful delivery to high-risk users and no evidence of access. Analysts should preserve indicators, search for related messages, block known infrastructure and close the event with a documented disposition.

Moderate severity covers clicks, attachment opens or suspicious replies without confirmed credential submission, code execution or account access. Responders should identify every recipient, isolate affected devices when malware is possible, inspect browser and endpoint telemetry and deliver targeted coaching to the users involved.

High severity covers credential submission, MFA approval, malware execution, suspicious OAuth consent, mailbox-rule changes, unauthorized forwarding or confirmed access to an account. The response should include account containment, session revocation, credential reset, token and application review, mailbox investigation and a search for cyberattacker-generated messages.

Critical severity covers privileged or executive-account compromise, multiple affected users, confirmed data exposure, payment diversion, ransomware delivery, widespread internal impersonation or a campaign that has already caused financial loss. The incident commander should coordinate security, IT, finance, legal, privacy, communications and affected business leaders while preserving evidence and documenting decisions.

Severity factors should be recorded as facts rather than impressions. Did the user click? Did they submit credentials? Did malware execute? Did a cyberattacker authenticate successfully? How many users received or interacted with the message? Did the account send internal or external messages? Was money transferred? Did sensitive or regulated data leave the organization? Each answer changes containment urgency and notification requirements.

The classification should remain provisional until the investigation closes key uncertainties. An incident initially rated moderate can become critical after a mailbox audit reveals hidden forwarding, unauthorized searches or a stolen session token. A frightening message can be downgraded after controls confirm that delivery was blocked and no user interacted with it.

A formal plan turns these judgments into repeatable action. It gives employees a clear reporting route, gives analysts evidence-based escalation thresholds and gives executives a defensible record of what the organization knew and when it acted. Those records also reveal which behaviors, channels and business processes require more focused preparation.

What Are the Main Phases of Email Incident Response?

Email incident response follows a six-phase lifecycle: prepare before an attack, detect and analyze the message, contain the spread, eradicate cyberattacker access, recover normal operations and document lessons learned.

Build the workflow around clear owners, evidence requirements, escalation thresholds and response-time targets, then rehearse the email incident response lifecycle through exercises instead of waiting for a real phishing incident. A single reported email needs fast validation, while a campaign affecting multiple accounts requires coordinated containment, broader scoping and executive communication.

1. Preparation and Detection

Preparation determines whether a phishing report becomes a contained event or an organization-wide compromise. Create a phishing incident response plan that names the incident commander, email administrator, identity team, endpoint team, legal contacts and communications contacts.

That plan should record each person’s authority to quarantine messages, disable accounts, revoke sessions and force password resets. Store those decisions in an accessible playbook because responders cannot depend on a potentially compromised email account during an incident.

Define the evidence to preserve before anyone deletes the message. The minimum record should include the original email with full headers, sender and recipient details, delivery timestamps, URLs, attachment hashes, authentication results, mailbox actions and the user’s account of what happened.

Record whether the employee opened an attachment, entered credentials, approved a payment, replied to the sender or forwarded the message. That distinction separates a suspicious email from an attempted compromise or confirmed account exposure.

Set operational targets that match the organization’s risk. A security operations team should acknowledge a user report within 15 minutes, complete initial triage within 30 minutes and assign a severity level within one hour.

High-risk reports involving privileged accounts, finance personnel, executive impersonation, credential entry or a suspicious attachment should enter the incident queue immediately instead of waiting for batch analysis. These internal service targets are goals, and teams should adjust them for staffing, time zones and regulatory obligations.

Detection begins when a user reports a message, an email control flags it or an analyst identifies a related indicator. Make reporting simple through a Phish Alert Button or a clearly published reporting address, and tell employees that reporting a mistake protects the organization instead of exposing personal failure.

A reported email can reveal the earliest evidence of a campaign, particularly when the user reports it after clicking a link or entering information.

Analyze the message in a controlled environment. Confirm the sender infrastructure, authentication results, reply-to address, link destination, attachment behavior and language patterns. Search mailboxes for matching sender addresses, domains, subjects, URLs, file hashes and message IDs.

Also, check identity logs for unusual sign-ins, new multifactor authentication factors, inbox rules, forwarding settings and token activity. Review financial workflows when the message requests a transfer or vendor bank change.

The response path changes when one person reports one email versus when several accounts receive related messages. A single low-risk message with no click, reply or credential entry can usually be classified, removed from the user’s mailbox and logged for trend analysis.

A campaign requires organization-wide searching, message quarantine, indicator blocking, account review and a communications decision. Treat multiple reports as one coordinated incident even when the messages use different subjects or sender domains.

The 2025 NIST incident response recommendations, authored by Alexander Nelson, Sanjay Rekhi, Murugiah Souppaya and Karen Scarfone, place incident response within broader cybersecurity risk management. Their guidance states that organizations should incorporate incident response “throughout their cybersecurity risk management activities,” connecting the phishing plan to identity management, asset inventories, business continuity, legal review and executive reporting.

2. Containment and Eradication

Containment limits what cyberattackers can still reach while the team determines the full scope. For a single suspicious email, remove the message and known variants from every affected mailbox, block malicious domains and URLs where appropriate, and ask the recipient whether they interacted with the content.

If the user only opened the email, preserve the evidence and complete endpoint checks. If the user clicked, submitted credentials or opened an attachment, escalate immediately.

Set a containment target of 30 minutes after confirming malicious activity for a high-severity event. That target should include disabling a compromised account when necessary, revoking active sessions and tokens, suspending suspicious forwarding rules, isolating an affected endpoint and blocking known indicators.

Do not reset a password while leaving active sessions or unauthorized multifactor authentication methods in place. Cyberattackers often retain access through tokens, mailbox rules or newly registered authentication devices.

Containment for a campaign requires a wider blast-radius assessment. Search all mailboxes for the campaign’s indicators, including near-duplicate messages that use different sender addresses or URL shorteners. Identify every recipient, every user who opened or reported the message and every account that generated follow-on activity.

If the campaign impersonates an executive or supplier, notify finance, procurement, executive assistants and customer-facing teams so a second channel can verify payment, data-transfer or credential requests.

Use severity criteria that force consistent decisions.

• A message blocked before delivery is an event for monitoring.
• A delivered message with no interaction is a contained phishing attempt.
• A clicked link, opened payload or submitted credential is a potential compromise.
• An abnormal sign-in, mailbox-rule change, malware execution or unauthorized transaction is a confirmed incident requiring incident-command oversight and possible legal, regulatory or law-enforcement consultation.

Eradication removes the cyberattacker’s foothold and closes the entry path. Reset exposed credentials, revoke sessions, remove malicious inbox rules, delete unauthorized OAuth grants, replace compromised multifactor authentication methods and scan affected devices.

Examine related accounts for password reuse, delegated mailbox access and privilege escalation. If the email triggered a business email compromise (BEC) attempt, contact the bank or payment processor quickly and preserve transaction records. If sensitive data was accessed, involve privacy and legal teams before external notification.

Set an eradication target of four hours for a contained single-account credential compromise and one business day for a complex campaign. Escalate immediately when privileged access, regulated data or funds are involved. Document every action with a timestamp, operator, affected asset and outcome. That record allows shifts to hand off the incident and gives leadership a defensible account of what the organization knew and when it acted.

3. Recovery and Lessons Learned

Recovery returns users and business processes to trusted operation without closing the incident prematurely. Confirm that affected accounts have clean authentication methods, malicious rules and applications are gone, endpoints show no continuing indicators, and blocked domains or senders have not shifted to new infrastructure. Monitor sign-ins, mailbox changes, outbound messages and financial activity for at least one defined observation period after remediation.

A practical recovery target is four hours for a user whose credentials were exposed but whose account shows no evidence of persistent access. A campaign involving several accounts, endpoint investigation or payment workflows should receive a documented recovery estimate from the incident commander, with status updates at agreed intervals. Restore access only after the team verifies the account’s identity controls and records the reason for each decision.

Communicate with affected employees in precise, non-accusatory language. Tell them what happened, what information they should provide, which credentials or sessions were reset and how to report follow-on messages.

Employees are a critical detection signal, so a blame-oriented response suppresses the reports that help the team find the next variant. When the incident involves a supplier, customer or executive impersonation, provide verification instructions through a trusted channel rather than relying on the compromised email thread.

Close the incident with a structured review instead of a brief note that the messages were deleted. Compare actual triage, containment, eradication and recovery times with the plan’s targets.

Identify where the team lacked mailbox search capability, endpoint telemetry, authority to disable accounts, contact information or a documented decision rule. Separate control failures from human actions.

A user clicking a convincing message is evidence that the organization needs better controls, clearer verification steps or more realistic training. It should never become a reason to discourage reporting.

Update the phishing incident response plan after every significant event and exercise. Add newly observed sender patterns, impersonation themes, attachment types, URLs, mailbox rules and business-process weaknesses. Revise escalation thresholds when analysts discover that a supposedly low-risk event involved executive exposure or credential reuse. Feed recurring employee behaviors into targeted security awareness training and use realistic phishing simulations to rehearse reporting, verification and recovery actions across email, voice and SMS.

Test the plan at least quarterly through a tabletop exercise and periodic technical drills. A tabletop should guide leaders through a realistic sequence from first report to executive notification, while a technical drill should verify mailbox search, message removal, session revocation and account recovery.

Include scenarios for one reported phishing email, a broad campaign, a compromised executive account and a BEC request. Measure report-to-triage time, triage-to-containment time, the percentage of affected messages removed, accounts fully remediated and time to restore trusted access.

The National Cyber Security Centre phishing guidance recommends combining technical controls, clear reporting processes, user education and rapid incident response. No single layer catches every phishing message. That principle turns email incident response into an operating cycle that prepares people and controls, detects the signal, contains the spread, eradicates access, recovers carefully and strengthens the plan before another campaign arrives.

Email Incident Response Examples: Investigating a Phishing Campaign Across Multiple Mailboxes

Email incident response examples are most useful when they show how one reported message becomes an organization-wide investigation. Preserve the reported email, identify every matching delivery and correlate message content with headers, URLs, attachments and user activity. Determine whether the evidence describes an isolated mistake or a coordinated phishing campaign while keeping remediation reversible until the investigation is complete.

1. Scope the Campaign

A reported phishing email provides an initial signal and rarely describes the full incident. Record the reporting user, report time, mailbox, original subject, sender display name, sender address and received timestamp. Preserve the message in its original form before forwarding, editing or deleting it. Forwarding can alter headers and remove details that distinguish the original source from later copies.

The central investigative question is who else received the message. In Microsoft 365, responders can use message trace to search delivery records by time range, sender, recipient, subject or delivery status. Available fields and retention periods depend on the organization’s Microsoft 365 configuration, licensing and administrative permissions, so responders should treat the interface and results as environment-specific.

Search broadly before narrowing the query. A campaign operator can change the subject line, sender address or visible wording between waves while reusing the same infrastructure. Search the exact subject, distinctive body phrases, sender and recipient patterns, embedded URLs, attachment names, attachment hashes and the Message-ID header where available. Each signal answers a different question:

• The subject identifies obvious copies but misses altered variants.
• A distinctive phrase finds messages that use the same template with different subjects.
• Sender and return-path values expose spoofing or lookalike variations.
• A URL search connects messages that redirect to the same destination.
• An attachment hash identifies identical files even when filenames change.
• The Message-ID helps correlate the original message across mailboxes and forwarding paths.

Mailbox search adds detail that message trace alone does not provide. Use the organization’s approved Microsoft 365 search and investigation workflow to locate matching items in inboxes, junk folders, deleted items and quarantine, subject to role permissions and retention settings.

Identify original recipients as well as the people who reported the message. Include shared mailboxes, executive assistants’ mailboxes, distribution-list expansions and forwarding rules when the campaign’s scope requires them.

Recipient discovery should produce a working incident population. Separate users who received the email from users who interacted with it. Delivery evidence shows exposure, but it does not prove that a person opened, read or acted on the message.

Where Microsoft 365 or another mail platform exposes read, open, click or authentication telemetry, correlate those signals with the message identifier and time window. Treat open tracking cautiously because privacy controls, mobile clients, image blocking and automated scanners can create incomplete or misleading results.

A user who clicked a link is not automatically compromised, and a user with no recorded open event is not automatically safe. Check authentication logs, endpoint telemetry, browser activity and identity-provider alerts for signs that the message led to credential submission, malware execution or unusual account activity. Move the investigation from “who received it?” to “what happened after delivery?”

2. Preserve and Analyze Evidence

Preserve evidence before organization-wide deletion. Export or retain the original message, complete headers, body, attachments, URLs and relevant platform records in a controlled case location. Record who collected each item, when it was collected, where it came from and whether the file was transformed during export. This chain of custody gives responders a defensible record when legal, regulatory, insurance or post-incident review teams ask how conclusions were reached.

Headers provide the technical trail behind the visible email. Review the Received chain to understand the servers that handled the message, recognizing that intermediary services and forwarding can complicate the path. Compare the visible From address with Return-Path, Reply-To and envelope sender values. A mismatch does not prove maliciousness, but it identifies a point that requires verification.

Authentication results add context. SPF evaluates whether the sending infrastructure is authorized for the envelope domain. DKIM verifies whether a cryptographic signature aligns with the message and domain. DMARC evaluates domain alignment and the receiving organization’s policy.

A message can pass one check and still be malicious, especially when a cyberattacker uses a legitimate compromised account or a lookalike domain. Authentication results support analysis. They do not replace it.

URLs and attachments require separate handling. Defang URLs before placing them in tickets or chat so another analyst does not accidentally visit a live payload. Record the complete URL, redirect chain, resolved domain, registration details available to the response team and collection time. A benign landing page during the investigation does not prove that the original link was safe because cyberattackers frequently change destinations after delivery.

Calculate cryptographic hashes for attachments and preserve the original files in a restricted location. Hashes allow responders to identify identical payloads across mailboxes and compare samples without repeatedly opening them. Analyze suspicious attachments in an approved sandbox or malware-analysis environment, never on a production workstation. File type, macros, embedded links, archive structure and the attachment’s relationship to the message all matter.

A practical phishing response workflow can centralize reported messages, classification decisions and reversible mailbox remediation. Investigation quality still depends on preserving the underlying evidence. Automated classification should accelerate triage while preserving the original record until analysts understand the event.

3. Decide Whether the Event Is a Campaign or an Isolated Report

Classification should follow evidence instead of the number of reports. One employee report can represent a broad campaign if message trace identifies hundreds of recipients. Multiple reports can also describe a single harmless marketing message or a test that was misidentified as malicious. Define scope using delivery, content, infrastructure and user-action signals together.

Treat the event as a campaign when several independent indicators connect the messages. Examples include the same Message-ID pattern across recipients, a repeated subject or phrase, identical URLs, the same attachment hash, shared sending infrastructure or coordinated delivery within a narrow time window. Variations in sender address or subject do not break the relationship if body, destination or attachment evidence remains consistent.

Treat the event as an isolated report when the message appears confined to one mailbox, has no related deliveries, uses no malicious infrastructure and produces no suspicious user activity. Document that conclusion and the searches used to reach it. “No matches found” is not enough unless the case record states the time range, mailboxes, search terms and platform limitations.

The final decision should connect scope to action. For a confirmed campaign, preserve a representative sample, identify every recipient and interaction, remove matching messages from reachable mailboxes, and block or monitor malicious domains and URLs through approved controls.

Begin credential resets or endpoint review where telemetry supports those actions. Notify affected users with precise instructions, including whether they need to change a password, report a follow-up message or contact the help desk.

For an isolated report, retain the evidence, resolve the message from the reporting mailbox and provide targeted feedback without blaming the employee. Reporting a phishing email is a defensive behavior that gives responders the first usable signal. The investigation is complete only when the organization can explain what arrived, who was exposed, what users did, what evidence supports the conclusion and which controls prevent the same campaign from spreading further.

A Compromised Mailbox With Hidden Rules and Unauthorized Access | Email Incident Response Examples

Across email incident response examples, an unfamiliar sign-in alert often signals that the compromise started earlier with adversary-in-the-middle phishing and a stolen authenticated session.

Responders must identify identity and mailbox persistence signals, preserve evidence before changing the account, remove access, revoke tokens, delete malicious rules and notify affected parties. Treat the mailbox as an active intrusion until logs and configuration reviews show that the cyberattacker no longer has a path back in.

1. Detect Identity and Persistence Signals

Establish whether the alert represents a false positive, a stolen password or an active account takeover. Start with the identity provider’s sign-in timeline and compare the suspicious event with the employee’s known work pattern. A sign-in from an unfamiliar source IP, impossible travel between locations, an unrecognized device ID, a new browser or an unusual application ID requires immediate investigation.

A successful login after multiple failed attempts presents greater risk than a single blocked attempt because it indicates that a cyberattacker obtained a usable credential, session or authentication token. Session theft changes the response. An adversary-in-the-middle phishing page can capture a password, relay a multifactor authentication challenge and hand over a valid session cookie, so changing the password alone does not reliably end access.

Look for a sign-in that uses a device or application the employee never registered, a session established from a hosting provider or residential proxy and mailbox activity that begins soon after authentication.

Record the identity provider’s complete event details before filtering or closing the alert. Capture:

• Timestamp in UTC, username, sign-in result, authentication method and MFA details
• Source IP, approximate location, device ID, operating system, browser and user-agent string
• Application ID, resource or audience, client type and authentication protocol
• Correlation ID, request ID and session ID for linking identity, mailbox and application events
• Conditional-access result, risk level, policy applied and any impossible-travel or unfamiliar-device signal

A correlation ID can connect an identity event to an API request, OAuth token grant, mailbox rule change or data-access event. Google Cloud’s Google Workspace audit logging documentation explains that audit records identify who did what, where and when. Those records include events such as OAuth token activity, suspicious logins, forwarding and password changes.

Export those records to a case repository instead of leaving them only in a console where retention and permissions can change.

Inspect the mailbox for persistence. Cyberattackers often avoid deleting messages because deletion creates visible anomalies. They can create an inbox rule that moves messages containing terms such as “invoice,” “wire,” “payment” or “password” into an obscure folder, marks them as read or forwards them to an external address.

Review active and recently deleted inbox rules because a deleted rule can still establish cyberattacker activity through its creation and deletion events.

Review transport or mail-flow rules separately from mailbox rules. A tenant-level transport rule can redirect, blind-copy or alter messages before they reach the user’s mailbox. Check for recently created, modified or deleted rules, unusual external recipients, exceptions that bypass inspection and changes made by an account that should not administer mail flow.

Inspect delegates and connected applications. Look for newly added mailbox delegates, send-as or send-on-behalf permissions, unfamiliar mobile clients, newly registered applications and OAuth consent for mail, contacts, files or directory data. A malicious app does not need an interactive mailbox session if its refresh token continues to authorize API access.

2. Preserve the Compromised Mailbox

Preserve evidence before routine cleanup because password resets, token revocation and rule deletion can alter the timeline. If cyberattackers are actively sending messages, deleting mail or exfiltrating sensitive information, contain the account immediately while documenting each action and preserving the evidence already available.

Do not ask the employee to delete suspicious messages, sign out of every device or clean up the mailbox before responders capture its relevant state.

Export identity events, mailbox audit records, administrative audit logs, application-consent records, email headers and suspicious messages. Preserve original message files when possible, including full headers, authentication results, attachment metadata and embedded links. Use screenshots only as a secondary record because they omit machine-readable fields and can lose context.

Create a time-bounded evidence window that starts before the suspicious sign-in and extends through containment. Include:

• Identity-provider sign-ins, MFA challenges, session creation and session termination
• Password, recovery method, MFA device and security-key changes
• Inbox rules, forwarding settings, delegates and mailbox permission changes
• Transport rules, connectors, approved senders and administrative changes
• OAuth consent, application registrations, token issuance, token use and revocation
• Sent, deleted, archived and moved messages, including messages sent externally
• File, calendar, contact and directory access performed through the account or app

Preserve the mailbox in a way that keeps the employee’s work available for business continuity. A legal hold, eDiscovery export or provider-supported investigation copy is preferable to manually forwarding messages into another mailbox. Coordinate with privacy, legal and compliance teams before reviewing personal content, particularly when the mailbox contains regulated data or communications involving customers, patients or legal matters.

Before disabling the account, document its current groups, roles, delegates, forwarding destinations, active sessions, registered devices, authentication methods and authorized applications. Capture the full definition of each attacker-controlled rule alongside its name.

Record whether each rule was created, modified or deleted, when the event occurred and which administrator or application performed it. That record supports scoping and distinguishes cyberattacker changes from remediation changes.

3. Remove Access and Persistence

Containment should match the evidence. Force a password reset when the password was entered into a phishing page, reused elsewhere, exposed in a credential leak or changed without the user’s approval. Require a new password through a trusted recovery process, and never through an email link or phone number supplied by the suspected cyberattacker.

Revoke active sessions and refresh tokens after suspected session theft or adversary-in-the-middle phishing. Disable the account temporarily when the cyberattacker is actively accessing the mailbox, the user cannot be reached for verification or the account has privileged access. Blocking sign-ins from the suspicious IP or device can reduce immediate activity, but IP blocking alone is not containment because cyberattackers can change infrastructure.

Remove persistence in a deliberate order. Delete malicious inbox and transport rules, remove unauthorized forwarding, revoke unfamiliar mailbox delegates and disable unapproved application registrations. Revoke OAuth consent and tokens for malicious applications, and verify that the application cannot request new consent under another identity. Review administrative roles and group memberships because a cyberattacker who gained elevated access may have created a second route into the environment.

Search the organization for messages sent or forwarded by the compromised account. Quarantine malicious messages, remove copies from recipient mailboxes where authorized and identify external recipients who received sensitive information. Reset credentials for accounts that interacted with the cyberattacker’s messages or approved changes based on the compromised mailbox. If the mailbox handled payment instructions, notify finance and require out-of-band verification for pending transfers and vendor-account changes.

Notify affected parties after the scope is sufficiently clear. Give the employee a plain-language explanation of what happened, which devices to stop using and how to complete recovery. Tell internal recipients which messages are fraudulent and what actions to take.

Customers, vendors, regulators or law enforcement may require notification when personal data, payment instructions or regulated information was exposed. Keep the notification factual and avoid blaming the employee. The objective is to help people recognize the same attack pattern.

Close the incident only after a clean sign-in review shows no new suspicious sessions, mailbox auditing shows no continued access, rules and delegates remain authorized, OAuth grants are accounted for and affected recipients have received corrective guidance.

Strengthen conditional-access policies, require phishing-resistant MFA for high-risk roles and rehearse mailbox-compromise scenarios through phishing simulations that include business email compromise and multi-channel social engineering.

A compromised mailbox is not only an email problem. It creates an identity, persistence and trust problem that requires evidence-led containment from the first suspicious sign-in through final notification.

Email Incident Response Examples: A User Clicked a Phishing Link or Opened a Suspicious Attachment

These email incident response examples treat a clicked phishing link, submitted password, opened attachment, or executed payload as a reportable security event. None of those actions should be recorded as an employee failure.

The employee should stop interacting, report through the approved channel, preserve evidence, and follow instructions to isolate the device or change credentials from a known-safe device.

Responders must distinguish a click-only event from credential compromise or malware execution by examining endpoint, identity, mailbox, and network evidence.

Immediate Employee Response

The opening minutes determine whether responders receive usable evidence before cyberattackers change the account or expand access. Stop clicking, typing, replying, downloading, forwarding, or deleting anything connected to the message. Do not revisit the link to check whether it still works or open the attachment again.

Report the event through the approved channel, such as the Phish Alert Button, security hotline, service desk ticket, or incident chat channel.

Include the original message if the reporting process supports it, along with the approximate time, device used, link clicked, attachment opened, information entered, and any screen, browser, or system behavior that followed. If the message remains open, leave it available for responders unless the organization’s procedure directs otherwise.

The employee should provide facts without trying to diagnose the incident. State whether a password, multifactor authentication code, payment detail, customer record, or other sensitive information was entered. Also report whether the browser displayed a login page, downloaded a file, requested permissions, launched a program, opened a command window, or triggered an unexpected sign-in prompt.

Use this immediate response path:

• Stop interacting with the message, website, attachment, or prompt.
• Report the event through the approved channel and preserve the original email.
• Disconnect from the network or isolate the device only when instructed by the security or IT team, unless the organization’s incident plan explicitly authorizes immediate isolation.
• Change exposed credentials from a known-safe device when responders direct that action, beginning with the affected account and any account that reused the same password.
• Do not delete the email, browser history, downloaded file, security alerts, or other evidence.

A suspicious event still deserves a fast report even when nothing obvious happened. A click can redirect through several domains, submit browser data, or trigger an identity prompt without producing a visible infection. Prompt reporting gives responders time to revoke sessions, block indicators, quarantine related messages, and protect other employees before the campaign expands.

Triage the Account and Device

Responders must establish exactly what happened because a click-only event requires a different response from a stolen password or executed malware. Build a timeline from message delivery, employee interaction, authentication activity, endpoint telemetry, mailbox changes, and network connections.

The CISA Cybersecurity Incident and Vulnerability Response Playbook organizes response around detection, analysis, containment, eradication, and recovery, helping teams preserve evidence before beginning cleanup.

Click-only branch. In a click-only event, the employee visited the link but did not submit credentials, download a file, approve a prompt, or execute content.

Responders should inspect secure web gateway, DNS, proxy, browser, and email telemetry to confirm the destination, redirect chain, timestamp, user agent, and any download or script activity. Search for the same URL, sender, domain, and message pattern across the organization, then remove matching messages where authorized.

Endpoint evidence should show whether a file was downloaded, whether a browser process created a child process, and whether a new persistence mechanism appeared. Useful checks include process creation, file writes, scheduled tasks, services, startup items, browser extensions, and endpoint detection alerts around the event time.

If those signals remain clean and identity logs show no suspicious authentication, the case can proceed through monitoring and targeted employee follow-up instead of full account-takeover containment.

Credential compromise branch. A submitted password changes the response immediately, even when the employee did not complete the login or received an error.

Revoke active sessions and refresh tokens, reset the affected password, invalidate remembered browser sessions, and review recent sign-ins for unfamiliar locations, devices, applications, impossible-travel patterns, or unusual authentication methods.

Check whether the cyberattacker registered a new multifactor device, created an app password, added an OAuth application, changed recovery details, or modified conditional access settings.

Identity review must extend beyond the reported account. Search for password reuse across privileged, financial, administrative, service, and personal accounts where organizational policy permits.

Examine mailbox evidence for forwarding rules, inbox rules, deleted messages, sent messages, delegate changes, and searches involving invoices, payroll, contracts, or customer data. Business email compromise (BEC) often depends on quiet mailbox manipulation, so an account with no suspicious sign-in still requires a rule and outbound-message review.

Malware execution branch. An opened attachment becomes a higher-severity event when it launches a process, enables macros or active content, exploits a reader, installs software, or causes unusual system behavior.

The security team should isolate the endpoint through its approved management process when instructed, keeping the device powered on if that preserves volatile evidence and following the organization’s forensic procedure.

Employees should not run antivirus scans, uninstall programs, reboot repeatedly, or attempt manual cleanup unless responders direct them to do so.

Endpoint responders should compare process trees, command-line activity, file hashes, quarantine events, memory alerts, persistence locations, and local account changes against the attachment’s execution time.

Network evidence should identify outbound connections, DNS lookups, encrypted sessions, downloads, command-and-control indicators, and access to internal systems. Identity and server logs should determine whether the device authenticated to file shares, cloud applications, administrative consoles, or other endpoints after execution.

Mailbox and network evidence complete the timeline. Investigators should search for messages sent from the account, newly created forwarding rules, additional recipients, internal reconnaissance, unusual file access, and connections from the endpoint to systems outside its normal working pattern.

Lateral movement becomes more credible when endpoint and identity records show remote execution, new service creation, privileged authentication, repeated authentication failures followed by success, or access to multiple hosts in a short period.

Organizations can standardize this work through phishing response and phish triage workflows that preserve the report, classify the message, and coordinate mailbox remediation without asking employees to investigate the cyberthreat themselves. Automation should support analyst judgment, preserve original evidence, and keep a case open until identity and endpoint checks are complete.

Escalate Based on Impact

Escalation should follow demonstrated impact. Embarrassment and the employee’s job title should carry no weight in that decision.

A click-only event with no download, credential submission, suspicious sign-in, or endpoint signal can remain a low-impact case with documented monitoring and focused coaching. The employee should still receive feedback on the decision point that caused the interaction, because a respectful review turns a near miss into a repeatable reporting skill.

Credential compromise requires account containment and an expanded scope review. Escalate to the incident response lead when the account accessed sensitive data, sent internal phishing messages, handled payments, belonged to an executive or administrator, or showed evidence of mailbox persistence. Finance, legal, privacy, human resources, and communications teams should join when the incident involves payment instructions, regulated data, customer information, contractual obligations, or external notification requirements.

Malware execution requires device containment and threat hunting when the payload establishes persistence, contacts an external system, disables security controls, accesses credentials, or reaches internal resources. Escalate further when responders find lateral movement, ransomware behavior, data staging, privilege escalation, or activity on more than one endpoint. Preserve forensic images, logs, message artifacts, and decision records according to the organization’s retention and legal-hold requirements.

Every branch should end with recovery and prevention actions. Restore the device only after responders confirm that malicious processes and persistence are removed. Rotate any credentials exposed during the event, confirm mailbox rules and multifactor settings are clean, then monitor the account and endpoint for recurrence.

Search for related messages and indicators across the environment, update phishing simulations and role-specific training, and strengthen reporting and verification procedures around the behavior that created the incident.

The employee remains part of the response throughout. Thank the person for reporting, explain what the investigation found, and avoid punitive language when the employee acted in good faith. A trusted reporting culture produces earlier signals, giving responders more time to contain the incident before one suspicious message becomes an organization-wide exposure.

Business Email Compromise Response Example: Handling a Fraudulent Payment Request

A business email compromise response must contain financial loss, preserve evidence, investigate mailbox access and determine whether an attempted payment became a confirmed loss.

Move quickly on financial containment, evidence preservation, affected systems and coordinated communications with legal counsel, insurers, customers, regulators and law enforcement.

Email incident response examples show that every payment request should be treated as potentially recoverable until the bank confirms otherwise. Investigators should not classify an attempted fraud as a reportable breach until the exposure review is documented.

Stop Financial Loss and Preserve the Incident

The immediate objective is to stop money from moving. Open one incident channel with the security lead, finance leader, executive sponsor, legal counsel and the employee or vendor whose identity was impersonated. Assign an incident commander to approve actions and maintain a timeline so conflicting instructions do not cost critical minutes.

Contact the originating bank’s fraud department immediately and request a payment recall, hold or freeze. Provide the transaction amount, date and time, originating and receiving account details, wire confirmation, invoice, beneficiary information, email headers and the exact messages that authorized the transfer. Ask the bank to contact the receiving institution through its fraud channel. Record the case number, contact name, escalation path and every response time.

If the transfer is pending, request cancellation before settlement. If it has settled, request a recall and coordinate with the receiving bank and law enforcement without waiting for the internal investigation to finish.

Classify the event precisely:

• Attempted fraud: A fraudulent message or payment instruction was sent, but no payment was released.
• Blocked transaction: The organization initiated a payment, but the bank stopped, rejected or froze it.
• Confirmed loss: The payment settled or funds were withdrawn, and the bank has not confirmed recovery.
• Potential secondary exposure: A cyberattacker accessed credentials, payment data, customer information or internal conversations that could support another fraud attempt.

This distinction controls escalation, insurance notices and later reporting. Do not describe an attempted payment as a financial loss. Do not describe a blocked payment as harmless until investigators establish whether credentials, mailbox content or vendor records were exposed.

The FBI’s 2025 IC3 Annual Report treats business email compromise as a distinct cyber-enabled crime category. File a complaint with the Internet Crime Complaint Center when appropriate, preserve the submission number and provide it to counsel, the insurer and the bank. Contact local or national law enforcement when the loss is material, cyberattackers targeted multiple parties, a customer was impersonated or investigators need assistance with preservation and recovery.

Contain the cyberattacker’s access without destroying evidence. Reset the affected user’s password, revoke active sessions and refresh tokens, require multifactor authentication, disable suspicious forwarding and remove unauthorized application consent. If an executive, vendor or finance employee was impersonated without mailbox takeover, preserve the message and investigate the source account before changing unrelated systems.

If the mailbox was compromised, use a controlled account-recovery process. Have the identity team confirm that recovery addresses, authentication methods and delegated permissions are legitimate before restoring access.

A focused phishing response and email remediation workflow can help security teams classify reported messages, identify recipients and remove fraudulent email from additional inboxes. Keep remediation reversible where possible, and export the original message, headers, attachments and platform audit records before bulk deletion.

Investigate Exposure and Impersonation

Determine how the request was created and what cyberattackers could reach. Start with the affected mailbox, identity provider, email platform, endpoint and financial systems, and expand to connected accounts and recipients of the fraudulent message. Preserve logs in their original format and record the time zone used for every timestamp.

Investigators should answer five questions:

1. 1Was the real mailbox compromised, or did a cyberattacker spoof or register a lookalike account?
2. 2Which messages, attachments, contacts, calendars and payment instructions could the cyberattacker read?
3. 3Did the cyberattacker create inbox rules, forwarding rules, transport rules, filters or hidden folders?
4. 4Did the account have delegated access to executive, finance, shared or customer-service mailboxes?
5. 5Did stolen credentials provide access to cloud storage, collaboration tools, vendor portals or payment platforms?

Review sign-in history for unfamiliar locations, devices, user agents, impossible travel, unusual authentication failures and new multifactor methods. Examine mailbox audit logs for searches, downloads, message reads, sent items, deleted items, rule creation and delegate changes. Search for terms involving invoices, wire transfers, payroll, tax forms, customer records and password resets.

A fraudulent message becomes more convincing when a cyberattacker has read earlier conversations and copied an established writing style. Investigate lateral movement rather than stopping at the mailbox. Confirm whether the user accessed file repositories, customer relationship systems, enterprise resource planning platforms, human resources systems or banking portals during the exposure window.

Review OAuth grants and connected applications, browser sessions, saved credentials and endpoint alerts. If the compromised identity belonged to a finance employee, inspect approval workflows and vendor-master records for altered bank details. If it belonged to an executive, inspect assistants’ delegated access and shared calendars for deal, payroll or payment context.

Treat personally identifiable information as an investigation question instead of an assumption. Identify whether the mailbox or connected storage contained names, addresses, government identifiers, tax documents, bank details, payment cards, health information or authentication data. Record the data categories, affected individuals, countries, access period and evidence supporting actual access.

The existence of a document in a mailbox does not prove that a cyberattacker opened it. The absence of proof does not eliminate risk. Document what investigators can confirm, what remains unknown and which controls address the uncertainty.

Scope fraudulent messages across internal and external recipients. Search message trace, quarantine, sent-mail and recipient logs for the sender address, lookalike domains, reply-to values, invoice numbers, payment instructions and attachment hashes. Notify recipients through a trusted channel that the request was fraudulent. Tell them not to reply or use the supplied payment details, and provide a verified contact method.

If a vendor’s mailbox was compromised, coordinate directly with that vendor through a previously validated phone number rather than the number in the email. That verification step protects the investigation from a second impersonation attempt.

Coordinate Notification, Counsel and Recovery

Place the facts under controlled legal and communications review. Notify internal or outside counsel early when payment data, customer information, employee records or regulated information may have been accessed. Counsel can help preserve privilege, coordinate forensic work, interpret contracts and assess notification duties in each relevant jurisdiction. Security teams should provide evidence and timelines without making legal conclusions.

Notify the cyber insurer according to the policy’s requirements. Use the insurer’s approved breach counsel, forensic firm or incident-response provider when required. Late notice, unauthorized communications or unapproved remediation can complicate coverage, so document when the incident was discovered, when the insurer was contacted and which instructions it provided.

Keep the bank, insurer, counsel and investigators aligned on the difference between suspected exposure, confirmed access, attempted fraud and confirmed loss. Consistent classification prevents inaccurate customer notices and conflicting regulatory statements.

Regulatory and privacy analysis should follow the evidence. Counsel and the privacy team should evaluate applicable breach-notification laws, contractual notice clauses, sector requirements, payment-network rules and cross-border obligations. Determine whether customers, employees, vendors, regulators or business partners need notice, which facts can be confirmed and whether notification timing is measured from discovery, confirmation or another legally defined event.

Do not promise that no personal information was exposed until mailbox, identity, endpoint and cloud investigations are complete. Avoid publishing technical details that would help cyberattackers, but communicate the practical risk clearly.

Affected customers and vendors need precise instructions. Explain what happened, which payment or message was affected, what the organization has done, what recipients should do and how they can verify future requests. For a fraudulent invoice, tell recipients to disregard the payment instructions and verify account changes through an established channel. For exposed credentials, force resets and provide clear instructions for monitoring suspicious activity.

Close the incident only after recovery and control validation. Confirm whether funds were recovered, malicious rules and sessions were removed, delegated access is legitimate, affected recipients were reached and required reports were submitted. Complete a post-incident review that identifies the control failure without blaming the employee who received the request.

Update payment-verification procedures, require independent callbacks for account changes, restrict mailbox delegation, improve logging and rehearse the scenario with finance, executives and vendors. Track time to bank notification, time to payment freeze, recipients reached, confirmed versus attempted fraud, accounts reset, rules removed, data categories assessed and corrective actions completed.

Those measures turn one business email compromise into a tested email incident response program, giving the organization clearer signals when the next payment request arrives.

Email Incident Response Examples: How Should Organizations Contain, Eradicate and Recover From an Email Incident?

Email incident response examples become useful when they turn past failures into a repeatable decision framework. Organizations should contain the cyberthreat by stopping delivery, access and execution; eradicate persistence across mailboxes, identities and endpoints; and recover through staged validation and heightened monitoring.

Preserve evidence before destructive actions when the incident could involve fraud, legal exposure, credential theft or broader compromise. Documented email incident response best practices keep each of those decisions defensible after the fact.

1. Short-Term Containment

Short-term containment limits additional exposure while investigators determine what happened. Define the incident boundary by identifying the original message, every recipient, delivery time, sender infrastructure, embedded URL, attachment hash, related replies and reported user actions. Treat a single malicious email as a potential campaign until message tracing proves otherwise.

Use message tracing to find every copy across inboxes, archives, quarantine areas and mobile synchronization services. Purge the message only after confirming it is malicious, checking that no legal hold applies and capturing the headers, body, attachments, URLs, timestamps and delivery records. Deleting the email too early can remove evidence needed to establish the attack path, determine scope or support a fraud investigation.

Recall is narrower than purge. Use it only when the mail system can reliably remove the message from recipients’ mailboxes and the organization can verify completion. A recall confirmation does not prove containment because recipients may have forwarded, downloaded, printed or opened the content. If the message remains unclassified, quarantine it and preserve the original.

Block indicators that can cause further harm. Add the sender address, sending domain, reply-to address, malicious URL, attachment hash, lookalike domain and known infrastructure to the appropriate controls. Cyberattackers rotate domains and addresses quickly, so block exact indicators before assessing broader domain or URL-category restrictions that could disrupt legitimate business traffic. Record each block, its owner and its expiration review date so emergency rules do not become invisible operational debt.

Contain the account when evidence shows that a user entered credentials, approved an unexpected multifactor prompt, opened a weaponized attachment or sent messages from the mailbox. Disable sign-in or suspend the account, revoke active sessions, invalidate refresh tokens and reset the password through a trusted administrative channel.

Require multifactor authentication re-enrollment where necessary, and remove unfamiliar authentication methods, app passwords and recovery addresses. A password reset without session and token revocation leaves existing authenticated access intact.

Remove suspicious OAuth grants and connected applications before restoring access. Review consent history, delegated mailbox permissions, inbox rules, forwarding addresses and transport rules for changes made near the incident time. A cyberattacker using consent or a stolen token can retain access after a password change, so identity containment must cover credentials and authorization.

Escalate containment when the incident involves a privileged user, finance employee, executive, customer data or business email compromise (BEC). For a finance mailbox, pause high-risk payment instructions and require independent confirmation through a previously trusted phone number or in-person channel.

For an executive account, notify the executive’s assistant and security team through a separate channel before responding to urgent requests. For customer-facing messages, prepare a controlled communication plan so recipients receive accurate instructions rather than conflicting warnings.

Document every action in a timeline and assign an owner to each unresolved question. NIST’s 2025 SP 800-61 Rev. 3 incident response guidance places response and recovery inside broader cybersecurity risk management, so containment records should support immediate decisions and later improvements. Before declaring the email contained, confirm that no additional copies remain, no active identity sessions remain untrusted and no related sender or URL continues reaching users.

2. Eradication and Persistence Checks

Effective eradication reaches past the visible email and closes every foothold the cyberattacker established. Begin with the affected mailbox because persistence often survives in rules, forwarding settings, delegated access or third-party applications. Compare the current configuration with a known-good baseline, and inspect rules that hide, move, delete or forward messages containing terms such as invoice, payment, password or verification.

Export suspicious rule and forwarding configurations, record their modification history and remove unauthorized changes. Confirm that legitimate business rules remain intact, then test delivery with controlled messages. Review mailbox audit logs for sent messages, deleted items, searches, permission changes and unusual access locations. If the mailbox sent malicious messages, identify every outbound recipient and coordinate notification or message removal with those organizations.

Identity eradication must cover every authentication path. Reset credentials, revoke sessions and tokens, remove malicious OAuth consent, rotate exposed API keys and review administrator activity. If the account belongs to a service, vendor or shared mailbox, rotate the associated secret and check every system that uses it. A clean password does not establish a clean identity when a cyberattacker accessed a token, delegated permission or application credential.

Investigate the endpoint when the user opened an attachment, ran a downloaded file, enabled macros, installed software or entered credentials into a suspicious page. Isolate the device from the network when malware execution or active compromise is plausible.

Preserve volatile evidence and disk artifacts according to the organization’s investigation policy before reimaging. A fast rebuild restores productivity, but it can also destroy evidence and conceal the vulnerability that enabled the attack.

Eradication also requires fixing the condition that made the incident possible. Patch the exploited application, remove the exposed public file, correct email authentication, tighten conditional access, restrict risky OAuth consent or change payment-verification procedures.

If the email exploited employee trust rather than a technical defect, assign targeted training based on the observed behavior. A short module on vendor impersonation, BEC or suspicious OAuth prompts gives employees a practical response pattern without blaming them for an attack designed to look legitimate.

Search for reinfection across the environment before restoring normal access. Hunt for the same URL, attachment hash, sender infrastructure, subject pattern, rule name, OAuth application and authentication anomaly. Repeat the search after remediation using a new time window because cyberattackers can deliver a follow-up message after the original campaign is removed.

Do not close eradication while any of these conditions remains unresolved:

• An unexplained sign-in is active.
• A mailbox rule has no owner.
• A forwarding address is unverified.
• An OAuth grant is unexplained.
• A malicious file remains on an endpoint.
• A vulnerability is still exposed.

Assign residual risk to a named leader and define a closure deadline instead of treating uncertainty as recovery. That decision creates a measurable standard for restoring access without reopening the original attack path.

3. Recovery Validation

Recovery begins only after containment and eradication produce a defensible clean state. Restore mailbox access in stages, starting with the affected user and expanding to related accounts after validation. Re-enable a disabled identity only when authentication logs are clean, credentials have been reset, multifactor authentication works through a trusted method and all active sessions and refresh tokens have been revoked.

Validate the mailbox before normal use. Confirm that inbox rules match the approved baseline, forwarding settings point only to authorized destinations, delegated permissions are expected and sent, deleted and archived folders contain no unexplained activity.

Test inbound and outbound delivery with benign messages, and verify that security controls still inspect links and attachments. If the organization restored a mailbox from backup, compare its configuration and message state with audit records to identify changes introduced after the backup point.

Validate the endpoint independently from the mailbox. Remove isolation only after malware scans, endpoint telemetry and forensic review show no active cyberthreat. Check browser extensions, saved credentials, downloaded files, scheduled tasks and local persistence locations. When compromise cannot be disproved, reimage the device and issue fresh credentials rather than relying on a scan result.

Validate business recovery with people as well as tools. Ask the user to confirm that expected messages, calendar items and contacts are present and that no unauthorized message or payment request was sent from the account. For BEC or customer-facing incidents, obtain confirmation from affected customers, vendors or partners that fraudulent instructions were rejected and legitimate instructions were re-established through a trusted channel.

Place recovered accounts under heightened monitoring for a defined period. Alert on impossible travel, new devices, unfamiliar applications, forwarding changes, unusual mailbox searches, bulk downloads, new authentication methods and outbound messages to high-risk recipients. Monitor related accounts and domains as well because cyberattackers often return through a second compromised identity after the original account is secured.

Close the incident only when recovery validation is documented, affected parties have received necessary confirmation and monitoring shows no reinfection.

Record the root cause, time to contain, time to revoke access, messages removed, accounts affected and required control changes. Use those findings to improve phishing response and email remediation workflows, and test the revised process with a controlled email incident response exercise.

Recovery is complete when the organization can prove that access is clean, business communications are trustworthy and the same attack path no longer works.

Email Incident Response Examples: Who Owns an Email Incident and What Should the Response Emails Say?

These email incident response examples show how ownership and communication should work during an active phishing warning, a confirmed mailbox compromise, a regulator or partner update, and an internal closure notice.

The incident commander coordinates decisions while security operations contains the cyberthreat and preserves evidence. IT or identity teams secure accounts, email administrators remove malicious messages, and legal, privacy, communications, HR, finance, leadership and customer support manage the business consequences.

Internal warnings prioritize speed and safe employee action. Customer, regulator and partner messages prioritize accuracy, impact and required follow-up. Every message should state what is known, identify what remains unknown, provide one reporting route and avoid blaming employees who reported or interacted with the threat.

Roles and Escalation Ownership

Clearly assigned email incident response team roles prevent an email incident from becoming a series of disconnected technical and business decisions. The incident commander owns the timeline, severity rating, action log, meeting cadence and final escalation decision. Security operations validates indicators, investigates message delivery and user activity, preserves evidence, hunts for related activity and recommends containment.

The IT or identity team disables compromised sessions, resets credentials, reviews multifactor authentication changes and checks forwarding rules, OAuth grants and privileged access. The email administrator searches for copies of the message, quarantines or retracts it where possible, blocks confirmed indicators and preserves headers before deletion. Legal counsel determines privilege, contractual duties, law-enforcement considerations and litigation risk, while privacy assesses whether personal data was accessed and coordinates required notifications.

Communications drafts approved messages and controls external statements. HR supports employee coordination without turning the investigation into a disciplinary exercise. Finance validates payment instructions, freezes suspicious transfers and contacts banks when money is at risk. Leadership sets business priorities and approves material external communications, while customer support receives a short script, an escalation route and verified answers to prevent conflicting explanations.

A written phishing response process can connect employee reports to triage, containment and remediation without routing every decision through one analyst. The CISA 2024 incident response playbooks organize response around detection, analysis, containment, eradication and recovery, giving the incident commander a practical structure for assigning work while communications continue.

Employee Warning Template

An active internal warning should be brief, specific and operational. Do not repeat a live malicious link, attach the suspect file or include screenshots that expose clickable content. Send through a trusted channel and give employees one reporting route, such as the Phish Alert Button or a security team address.

> Subject: Action required: Report suspicious email claiming to be from [sender]

>

> We are investigating emails that appear to come from [sender] and request [payment, credentials or file access]. Do not click links, open attachments, reply to or forward the message. If you received it, report it through [approved reporting route] and leave it in your inbox unless Security instructs otherwise.

>

> Known: [confirmed facts and affected systems].

> Unknown: [facts still under investigation].

> What to do now: [required action]. Contact [single help route] if you already clicked, replied or shared information. We will provide an update by [time] or sooner if the facts change.

The message should protect employees who speak up. Remove language such as “careless” or “failed,” which turns reporting into a personal risk and can delay containment. If the investigation changes the scope, issue a correction rather than allowing an outdated warning to circulate.

Customer and Stakeholder Communication Template

Customer notifications should distinguish mailbox abuse from confirmed data access. State the affected account or service, the investigation window, the information involved if known, containment completed, protective steps customers should take and the time of the following update. Do not speculate about cyberattacker identity, claim that no data was accessed before review is complete or send customers to unverified contact details.

> Subject: Security update regarding communications from [organization]

>

> We identified unauthorized access to [mailbox or account] between [date and time]. During that period, messages may have been sent without authorization. We have secured the account, revoked active sessions and are reviewing message and data access.

>

> Confirmed: [known activity].

> Still under review: [unknown scope or data].

> Do not respond to suspicious messages or use links or attachments in them. Verify requests through [official channel] and report concerns to [single contact route]. We will provide an update by [date and time].

A regulator or partner update should add the incident identifier, current risk assessment, notification basis, containment actions, evidence status and a named contact for follow-up. Under UK GDPR, the Information Commissioner’s Office breach guidance states that a notifiable breach should be reported within 72 hours where feasible, even when the investigation is incomplete, with further information supplied later.

An internal closure notice should explain the confirmed cause, affected scope, completed controls, remaining monitoring and lessons learned. It should thank employees for reporting, identify any policy or training change and state who owns follow-up. Closure means the response phase is complete. It does not mean that every risk has disappeared, so continued monitoring remains part of responsible recovery.

Which Controls Reduce the Impact of Email Incidents? | Email Incident Response Examples

Email incident response examples show that layered controls outperform any single safeguard. Spoofing, credential theft, malware, business email compromise (BEC), and malicious forwarding fail at different points, so SPF, DKIM, DMARC, MFA, filtering, endpoint detection and response (EDR), and response workflows must work together.

Employees provide the signal that turns a suspicious message into a contained incident when they can report it quickly and without fear of blame.

Prevent Spoofing and Unauthorized Access

Implementing SPF, DKIM and DMARC reduces domain impersonation, while identity controls limit the damage after someone interacts with a fraudulent message. SPF identifies permitted sending servers, DKIM verifies message integrity through cryptographic signatures, and DMARC tells receiving systems how to handle messages that fail those checks.

These controls target domain spoofing and do not stop impersonation from a compromised legitimate account. Finance and executive teams still need verification procedures for payment, payroll and sensitive-data requests.

Phishing-resistant MFA, including FIDO2 security keys and passkeys, addresses credential theft more directly than passwords or one-time codes that cyberattackers can intercept through a proxy. Apply it to email, administrator accounts, remote access and financial systems, then remove legacy authentication paths that bypass the stronger factor.

The Cybersecurity Performance Goals 2.0 from CISA identify phishing resistant MFA as a priority control, making identity hardening a practical first layer rather than a complete response plan.

Least privilege limits the blast radius when an account is compromised. A mailbox user should not automatically have authority to create forwarding rules, approve payments, access every customer record or administer cloud applications. Restrict external forwarding, alert on new inbox rules, require additional approval for high-value transactions and audit delegated mailbox access.

Secure, tested backups support recovery when an email-borne attachment leads to ransomware or destructive account activity. Test restoration under pressure, because an unverified backup does not provide a dependable recovery path.

Detect and Automate Response

Detection controls determine whether a suspicious email becomes a reported event, a contained account or a wider compromise. Email filtering should inspect sender reputation, authentication results, attachment behavior, URLs and impersonation signals, but security teams must assume that a convincing BEC message can pass technical inspection. EDR looks for the consequences on the endpoint, including unusual process launches, credential theft, malware execution and connections following a clicked attachment.

A SIEM centralizes mailbox audit logs, identity events, endpoint alerts, authentication failures and data-access activity so analysts can connect separate signals. SOAR workflows can disable a compromised session, revoke tokens, remove malicious messages from multiple inboxes, quarantine an endpoint and open an investigation ticket. NIST’s SP 800-61 Revision 3 in 2025 places incident response within broader cybersecurity risk management and emphasizes preparation, detection, analysis, containment, recovery and improvement.

Mailbox auditing is essential when an incident involves account takeover. Review sign-ins, suspicious inbox rules, sent-mail anomalies, OAuth grants, delegate changes and forwarding destinations. A stolen password often causes damage through persistence and concealment as well as through the initial login. Alerts for high-risk changes should reach the security team while logs remain available for investigation.

Build Employee Reporting and Behavioral Readiness

Reporting channels close the gap between a control failure and a security response. Give employees one obvious route, such as a Phish Alert Button, dedicated mailbox or chat workflow, and define what happens after submission. Analysts should classify the message, search for matching deliveries, remove confirmed cyberthreats, assess whether credentials were exposed and provide feedback without blaming the reporter.

Phishing awareness training should use role-based scenarios rather than generic annual content. Finance teams need BEC and invoice-manipulation practice, executives need impersonation and malicious-forwarding drills, and administrators need credential-reset and MFA-fatigue scenarios. Phishing simulation tests rehearse email decisions, while vishing simulation and smishing simulation test whether employees verify requests across voice and SMS when email controls are irrelevant.

A multi-channel phishing simulation program should measure reporting speed, verification behavior and repeat exposure alongside click rates. Review results by role, attack channel and failure mode, then trigger targeted refreshers after risky behavior or a real incident. That feedback loop gives responders the evidence they need to identify, contain and recover from email incidents through a defined sequence.

How Should Teams Test and Improve an Email Incident Response Plan?

An email incident response plan becomes operational only when teams rehearse it, measure response, and close gaps. Test single-user incidents, broad phishing campaigns, mailbox compromise and business email compromise (BEC), converting each finding into an owner, deadline, playbook update or targeted cybersecurity awareness training action. Isolate exercises from real employees and production systems so teams can expose process failures without creating a new incident.

1. Design Safe Tabletop Exercises and Simulations

Start with a tabletop exercise using fictional identities, sanitized screenshots and a dedicated test tenant. Do not send simulated messages through production mailboxes, collect real passwords, modify live forwarding rules or request actual financial transfers. Create test accounts with dummy data, preapproved domains and a written stop condition that allows the exercise director to halt activity immediately.

Build four scenarios that increase in scope:

• Single-user incident: Test whether an employee can report a suspicious message and whether the help desk can preserve evidence.
• Phishing campaign: Test mass notification, message search and organization-wide removal.
• Mailbox compromise: Test password reset, session revocation, malicious inbox-rule removal and sent-mail review.
• BEC incident: Test payment verification, executive escalation, finance involvement and legal or regulatory notification decisions.

Use a controlled phishing simulation to test behavior as well as technical detection. Record whether participants open the message, click a link, submit dummy credentials or report the email. Never capture real credentials or send users to an external service.

The National Institute of Standards and Technology’s 2024 Cybersecurity Framework 2.0 implementation examples identify tabletop exercises, simulations and lessons-learned sessions as ways to improve future incident response activities. Each exercise should be treated as a systems test of the process, never as a judgment of the employee.

2. Set Metrics and Response-Time Targets

Metrics turn an email incident response plan from a document into an operating capability. Establish baseline times during the initial exercise, set targets according to business impact and track results consistently across every scenario. The most useful measures cover human behavior and analyst execution:

• Time to report: Minutes from delivery or discovery to the employee’s report.
• Time to triage: Minutes from report receipt to a Safe, Spam or Malicious decision.
• Time to contain: Time to disable accounts, revoke sessions, block indicators or stop further delivery.
• Time to eradicate: Time to remove malicious rules, malware, persistence and related messages.
• Time to recover: Time to restore normal access, validate affected systems and return the user to work.
• Affected users: Number of recipients, compromised accounts and exposed departments.
• Click and credential-submission rates: Measures of simulation interaction and unsafe follow-through.
• Malware execution: Number of endpoints or accounts where a payload runs.
• Messages removed: Copies removed from inboxes, sent folders and shared mailboxes.
• Financial exposure and incident cost: Requested or transferred funds, investigation time, recovery expenses and business interruption.

Set separate targets for a single suspicious email and a BEC campaign. A five-minute reporting target is reasonable for high-risk finance requests. Containment targets should be tighter when an account shows confirmed compromise. Measure the median and slowest result because one delayed executive mailbox can matter more than a strong average.

3. Run a Postmortem and Continuous Improvement Cycle

Complete the after-action review within five business days while evidence and participant recollections remain fresh. Record the scenario, timeline, detection point, decisions, missed signals, communication gaps and technical blockers. Ask what made the correct action easy or difficult instead of asking which employee failed.

Assign every finding to a named owner with a deadline and measurable completion condition. The email administrator can own an automated inbox-removal workflow, the identity team can own session revocation, finance can own callback verification and the security awareness manager can own a targeted BEC module. Update the playbook with exact commands, escalation paths, approval requirements and contact details, and retest each changed procedure during the next exercise.

Use results to target training instead of assigning generic annual content. Employees who click a simulated invoice request need practice verifying payment changes. Analysts who misclassify a malicious message need triage calibration. Executives and finance staff need rehearsals for authority-driven requests, including vishing and deepfake scenarios.

Review metrics monthly, repeat the highest-risk scenario quarterly and close the loop through phishing simulations and response training. A plan improves only when every exercise produces a documented change and the next test confirms that change works. That discipline turns individual reports into the signals security teams need to contain wider attacks.

How Cybersecurity Awareness Training Fits Into a Modern Human Risk Program

Cybersecurity awareness training is effective only when it builds operational readiness across email, voice, SMS and synthetic media. Email incident response examples show that readiness goes beyond an inbox metric. Readiness functions as a human risk management signal measuring how quickly employees recognize danger, report it, provide useful context and change behavior.

A 2025 randomized study of more than 19,500 UC San Diego Health employees found no meaningful relationship between annual training completion and resistance to phishing. Completed modules alone do not establish readiness.

From Incident Data to Behavioral Change

Incident data becomes valuable when security teams analyze patterns instead of assigning blame. A reported business email compromise (BEC) attempt can reveal whether employees verify payment changes, whether finance staff recognize vendor impersonation and whether managers reinforce escalation procedures. A spear phishing report can expose which roles are most affected by targeted language, while vishing and smishing reports show whether employees apply the same judgment outside email.

The pattern matters more than any single failure. Repeated clicks on credential lures suggest a recognition gap. Slow reporting indicates uncertainty about the process. Reports missing the sender, subject, requested action or attachment details show that employees noticed something unusual but need more practice documenting the signal.

Each pattern should trigger a specific response, such as a short microlearning lesson, a role-based scenario or a guided exercise that rehearses the correct action. Success means measurable behavioral change instead of a higher completion percentage.

Open-source intelligence (OSINT) belongs in this analysis because publicly available information shapes targeted attacks. A cyberattacker can use an employee’s job title, conference appearances, vendor relationships or public contact details to create a credible request. Training priorities should reflect the information cyberattackers can plausibly assemble about high-risk roles rather than the generic themes in an annual course.

“Taken together, our results suggest that anti-phishing training programs, in their current and commonly deployed forms, are unlikely to offer significant practical value in reducing phishing risks,” said Grant Ho, a faculty member at the University of Chicago and study co-author.

The 2025 UC San Diego study also found that embedded training reduced clicking by only 2%. Follow-up practice and behavioral measurement are essential.

Measuring Readiness Across Channels

Readiness requires a balanced view of what happens before, during and after an incident. Completion rates confirm that an employee received an assignment. They do not show whether that person can identify a deepfake-enabled executive request, challenge an urgent wire-transfer instruction or report a suspicious text message under pressure.

A modern dashboard should connect several signals:

• Time to report: Measures how quickly an employee moves a suspicious message to the security team, limiting exposure and accelerating investigation.
• Repeat susceptibility: Identifies recurring patterns across phishing, spear phishing, BEC, vishing, smishing and AI-generated social engineering.
• High-risk roles: Focuses additional practice on finance, executives, help desk staff, procurement and employees with privileged access.
• Executive exposure: Tracks how publicly available information and impersonation risk increase the likelihood of targeted attacks.
• Response quality: Evaluates whether reports include enough detail for analysts to classify, contain and remediate the incident.

These measures give the board a clearer view of human risk than a 98% completion rate. Leaders can report median time to report, the percentage of repeat failures, the highest-exposure departments and the quality of employee-submitted reports.

They can also distinguish a growing reporting rate from a growing incident rate. More reports usually indicate that employees are detecting and escalating cyberthreats earlier. They rarely indicate that the organization suddenly became less secure.

CISA instructs organizations to teach employees how to recognize phishing and make clear whom to notify and how to report it. That guidance supports a practical readiness standard: every employee should know the reporting path before an incident occurs, and every report should reach the right team quickly through a defined phishing response process.

Building a Continuous Improvement Loop

A human-risk program turns response data into a repeating cycle. Security teams review real incidents and simulated events by channel, role and failure mode. They assign targeted microlearning that addresses the exact behavior, such as verifying a payment request through a second channel or reporting a suspicious SMS without replying. They test the same skill after a reasonable interval and compare time to report, repeat susceptibility and response quality.

The cycle must include positive reinforcement. Employees who report suspicious messages accurately should see that reporting leads to a fast, professional response. Employees who fail a simulation should receive useful coaching and another opportunity to practice instead of public criticism. This approach treats employees as a distributed detection network whose value increases when the organization provides clear procedures and timely feedback.

Board reporting should show movement over time rather than isolated scores. A useful quarterly view connects training activity to operational outcomes, including fewer repeat failures among finance staff, faster reporting from executives, stronger evidence in submitted reports and improved performance across voice and SMS exercises. It should also identify unresolved exposure, including roles that repeatedly encounter high-consequence requests or teams that lack confidence in escalation procedures.

Email incident readiness belongs inside the broader cybersecurity awareness training program instead of beside it. Response data identifies the behavior to change, role-specific training builds the skill, simulations test whether the skill holds and board metrics show whether exposure is falling. Those signals create the foundation for examining how an email incident moves from initial detection through containment and recovery.

Email Incident Response FAQs

What Is the Difference Between an Email Security Event, an Email Incident and a Reportable Breach?

An email security event is a suspicious or malicious occurrence. An email incident is a confirmed event that threatens confidentiality, integrity or availability. A reportable breach is unauthorized access or disclosure that triggers a legal or contractual notification duty. A phishing message that reaches one inbox is an event. A clicked link, compromised mailbox, or unauthorized forwarding rule is an incident.

Exposed personal or regulated data requires legal and privacy review to determine whether notification is mandatory. NIST SP 800-61 Rev. 3 directs incident handlers to verify incidents, analyze evidence, prioritize response, and document decisions. Classify quickly, preserve facts, and involve counsel before making breach-notification decisions.

What Should an Employee Do Immediately After Clicking a Suspicious Email Link?

After clicking a suspicious email link, stop interacting with the page, report the message through the approved channel, and contact security or IT immediately. Do not enter credentials, download files, approve MFA prompts, or delete the email. If credentials were submitted, tell responders exactly what was entered and change the affected password from a known-safe device when instructed.

If a file opened or the device behaves unexpectedly, disconnect it from networks only according to the organization’s response procedure and await guidance. CISA phishing guidance emphasizes reporting suspicious messages and avoiding further interaction. Fast, blame-free reporting gives responders the best chance to revoke access and contain spread.

How Can an Organization Tell Whether a Malicious Email Was Opened or Read?

An organization can establish delivery and recipient scope reliably, but it usually cannot prove that a malicious email was read from delivery data alone. Microsoft 365 message trace identifies mail-flow activity, while mailbox, audit, identity, proxy, safe-link, endpoint, and authentication records can show interactions such as a link visit, attachment access, sign-in, or credential submission.

Read receipts are inconsistent and should not be treated as definitive evidence. Microsoft Learn’s message-trace documentation explains that message trace tracks message events rather than user comprehension. Record each evidence source, its timestamp, retention limits, and confidence level before concluding that exposure occurred.

When Should an Organization Delete or Recall a Malicious Email From Every Mailbox?

An organization should purge or recall a malicious email after responders capture the message and essential metadata, confirm the search scope, and determine that removal will reduce active risk. Use immediate removal when the message contains credential theft, malware, a malicious attachment, or a live phishing URL and remains accessible to recipients.

Preserve a controlled forensic copy, headers, URLs, attachment hashes, Message-ID, recipient list, and relevant audit records before deletion. Microsoft 365 guidance documents reporting for malicious messages and zero-hour auto purge activity. Coordinate removal with account containment, URL blocking, endpoint review, and user communications so deletion does not conceal evidence or leave a second delivery path.

What Evidence Should Be Preserved During an Email Incident Investigation?

Preserve the original message, complete headers, Message-ID, sender and recipient data, timestamps, URLs, attachment hashes, authentication results, mailbox audit records, message-trace results, sign-in logs, endpoint telemetry, browser history, network activity, forwarding rules, delegates, OAuth grants, and relevant communications.

Capture evidence before purging mail, resetting accounts, rebuilding devices, or changing configurations, and record who collected each item, when, how, and where it was stored. NIST digital evidence guidance warns that digital evidence can be disclosed or altered during handling. A complete, time-aligned record reveals impact and turns response findings into priorities for continuous security awareness training.

Strengthen Employee Readiness Across Every Attack Channel

Email incidents expose gaps in reporting speed, decision-making, and response consistency across the human layer. Continuous, multi-channel training turns those findings into practiced behaviors and measurable readiness for phishing, vishing, smishing, spear phishing, and deepfake attacks. Evaluate multi-channel phishing simulations for the organization’s human-risk program.