Phishing Email Decision Tree: 5 Questions to Spot, Verify, and Report Suspicious Messages Safely Before Acting

Key takeaways

• A phishing email decision tree asks five questions in order: whether the message was expected, whether the sender and domain match, whether the request makes sense, whether links and attachments lead where expected, and whether the message creates pressure.
• One failed check is enough to pause, avoid interaction, and verify the request through a channel the employee selects independently.
• Passing every check lowers suspicion but does not prove safety, because compromised accounts and abused services can pass technical checks.
• Fast, blame-free reporting through one approved channel gives security teams time to remove related messages, revoke access, and protect other employees.
• Training programs should measure reporting rate, report time, and credential submissions by role, since completion records alone do not show whether behavior has changed.

Want more from Adaptive in your Google results?

A phishing email decision tree gives employees a repeatable way to assess suspicious messages before a click, reply, download, payment, or data disclosure turns a warning sign into an incident. This guide shows employees and security leaders how to apply five checks across desktop, mobile, Gmail, Outlook, and other email platforms.

The checks cover sender identity, links, attachments, QR codes, authentication signals, urgency, and unusual requests, all inspected without interacting with potentially harmful content. The guide also explains how to verify sensitive requests through trusted channels, report messages without spreading them, preserve useful evidence, and respond quickly after a click or disclosure.

The same process applies to spear phishing, business email compromise (BEC), compromised familiar accounts, automated notifications, and AI-generated social engineering. Passing every check does not prove a message is safe, and a failed check does not call for blame. Each check simply creates a clear pause point.

CISA guidance reinforces independent verification, careful reporting, and rapid action after mistakes. Applied consistently, the decision tree turns phishing awareness into measurable human-risk behavior that supports faster detection and safer decisions. Organizations that want to connect employee reports to faster analysis can pair the process with Adaptive Security’s phishing triage workflow.

Phishing Email Decision Tree: The Five Questions to Ask Before Acting

A phishing email decision tree replaces instinct with a repeatable sequence. Employees check the context, identity, request, destination, and pressure before taking action.

The same five questions apply every time. The employee pauses at the first failed check and verifies the message through a trusted channel. Replying, clicking, and opening an attachment all wait until verification is complete.

Passing all five checks lowers suspicion but does not prove that an email is safe. Convincing phishing attacks can imitate legitimate senders, familiar workflows, and trusted business relationships.

1. Use the Five-Question Flowchart

A decision tree slows the moment when a cyberattacker wants an automatic response. Rules such as “look for spelling errors” fail against polished, AI-generated messages. A sequence forces the recipient to compare several independent signals before trust turns into action.

Single cues also perform worse in real inboxes than in the lab. A study on cue utilization and phishing detection in the Journal of Cognitive Engineering and Decision Making found that cue utilization and cognitive reflection helped participants in controlled phishing tasks. Neither trait predicted performance in naturalistic phishing simulations.

The following five-question flow applies to any unexpected message, including one that appears to come from a colleague, supplier, executive, or familiar service:

1. 1Was this expected?

The first question is whether the recipient was waiting for the invoice, document, password reset, delivery notice, or shared file. An unexpected message is not automatically malicious, but it starts the review. Check whether the timing fits a known business process.

A vendor that suddenly sends new bank details, or an executive who requests an urgent transfer without prior context, is a reason to pause before continuing.

1. 1Do the sender and domain match?

Inspect the complete sender address along with the display name. Compare the domain letter by letter with the organization’s normal domain. Cyberattackers use lookalike domains, extra words, substituted characters, and free-mail accounts to imitate trusted contacts.

A message from “Finance Director” that arrives from an unrelated domain fails this check, even when the signature, logo, and writing style look correct.

1. 1Does the request make sense?

Identify the action the sender wants. The request should fit the sender’s role, the organization’s normal approval process, and the relationship between the parties. A human resources employee requesting payroll data could be expected, while a marketing contact requesting administrator credentials is not.

A familiar request can still be malicious when it changes payment instructions, asks for secrecy, or bypasses an established approval step.

1. 1Do the links or attachments lead where expected?

On a desktop, hover over a link without clicking to preview its destination. On a mobile device, press and hold the link to reveal the address without opening it. Compare the destination with the service named in the message.

Treat shortened links, unexpected cloud-storage shares, password-protected archives, and attachments that prompt the reader to enable macros or sign in as high risk. Visible text can say one thing while the actual destination leads somewhere else.

1. 1Is the message creating urgency or asking for sensitive action?

Pressure is a manipulation tactic. Requests to act before a deadline, keep the matter confidential, bypass a colleague, or transfer money deserve independent verification. The same applies to requests for passwords, multifactor authentication codes, tax records, customer data, or internal documents.

CISA’s phishing guidance, “Stopping the Attack Cycle at Phase One,” published in October 2023, advises users to recognize suspicious messages, avoid harmful links and attachments, and report them through the organization’s established process.

One rule governs every branch: one failed check means pause, do not click, and verify through a trusted channel. The email’s reply button and contact information are off limits when verifying a high-risk request.

Safe verification routes include the company directory, a known phone number, a new message to a verified address, or an in-person confirmation. Payment changes and credential requests should also require a second person or an established approval workflow.

2. Interpret What a Yes or No Outcome Means

A “yes” answer does not mean “safe.” It means only that the message passed one checkpoint. A legitimate-looking sender can be compromised, a real account can send a malicious message, and a familiar business process can be hijacked. Employees should continue through all five questions before interacting with the content.

A “no” answer identifies a reason to stop. Employees do not need to prove that a message is malicious before reporting it. Suspicion is enough to trigger caution. Early reporting gives the security team time to investigate, warn other recipients, and remove related messages.

The distinction between suspicious and confirmed malicious matters:

• A suspicious message contains one or more warning signs, such as an unexpected request, domain mismatch, unusual attachment, or pressure to act. Leave it unopened or stop interacting with it, then report it for review.
• A confirmed malicious message has been validated as harmful through security analysis, a known campaign, a malicious destination, credential-harvesting behavior, or another reliable signal. Do not forward it casually, reply to it, or test its links. Follow the organization’s incident-reporting process.
• A message that passes the checks remains unverified. If it requests money, sensitive information, privileged access, or an unusual exception, confirm it through a separate trusted channel anyway.

This approach protects employees from blame and gives them a practical threshold for action. Recipients do not need forensic skills. The aim is to make stopping and verifying the normal response when a message does not fit the expected pattern.

An employee who clicked a link or opened an attachment before noticing the warning signs should prioritize speed over embarrassment. The right steps are to disconnect from the affected session if the organization instructs it, avoid entering additional information, report the event immediately, and preserve the original message.

3. Apply the Quick Decision Tree on Desktop or Mobile

Employees need a version they can use while handling a crowded inbox, a phone notification, or a message during a busy workday. Security teams can keep this compact decision tree near the reporting button or include it in security awareness training:

1. 1A new or unexpected email arrives. Was it expected?

No: Stop. Do not click or open anything. Report the message or verify it through a trusted channel.

Yes: Continue.

1. 1Do the sender name and full domain match the expected person or organization?

No: Treat the message as suspicious. Do not reply. Report it and verify independently.

Yes: Continue.

1. 1Does the request fit the sender’s role and the organization’s normal process?

No: Pause. Confirm with the sender through a known contact method and involve the required approver.

Yes: Continue.

1. 1Does every link and attachment lead where expected?

No, or cannot confirm: Do not click or open anything. Report the message for review.

Yes: Continue.

1. 1Does the message create pressure or request sensitive action?

Yes: Stop and verify through a separate trusted channel, even if the previous checks passed.

No: Proceed only after a final review of the sender, request, and destination.

On a phone, employees can expand the sender details before judging the message. A suspicious destination should stay out of the browser entirely, including any attempt to paste it in “just to see what happens.” If the phone interface hides key details, the employee can move the message to a desktop or report it without further inspection.

A careful employee who reports an uncertain message has made the correct security decision, even when the message later proves legitimate. The first safe action is behavioral: stop, avoid interaction, and create time for verification.

Organizations can reinforce this process with a Phish Triage workflow that gives employees a clear reporting path and helps security teams classify messages consistently.

How Can Employees Tell Whether an Email Is Phishing? Use a Phishing Email Decision Tree

A phishing email is a deceptive message designed to make someone click, open, disclose information, transfer money, or bypass a security process. A phishing email decision tree turns that uncertainty into a repeatable check of the sender, request, language, branding, and context before anyone acts.

Legitimate-looking details, perfect grammar, and a familiar name no longer prove authenticity, because cyberattackers can copy real accounts and generate convincing messages with AI. A broader guide on how to spot a phishing email covers the individual red flags in more depth.

What Types of Phishing Emails Should Employees Recognize?

Phishing is the broad category, and cyberattackers adapt each message to the target and the outcome they want. Plain-language distinctions help employees identify risk without memorizing technical terminology.

• Spear phishing targets a specific person or team with details drawn from company websites, social media, previous correspondence, or open-source intelligence (OSINT). A message that mentions a real project, customer, colleague, or upcoming meeting can still be fraudulent.
• Business email compromise (BEC) impersonates an executive, supplier, attorney, or employee to trigger a payment, payroll change, gift-card purchase, data disclosure, or account takeover. The message often avoids malware and relies on authority and pressure.
• Whaling is spear phishing aimed at senior leaders or high-value decision-makers. A chief financial officer, chief executive officer, board member, or administrator receives a request designed to exploit access, influence, or approval authority.
• QR-code phishing, also called quishing, places a malicious QR code inside an email, PDF, image, or meeting invitation. Scanning the code can move the cyberattack to a mobile browser, where the employee may not see familiar desktop security indicators.
• AI-generated phishing emails use generative AI to create fluent, personalized messages at scale. They can imitate a company’s tone, refer to public events, and remove the spelling mistakes that once made suspicious emails easier to spot.

Every category calls for the same response. Employees stop before clicking, replying, paying, scanning, or sharing credentials, then verify the request through a trusted channel that the message did not provide. No one is expected to make a perfect judgment from one clue. Employees are expected to pause, inspect several signals, and report uncertainty.

Identity and Display-Name Deception

The sender identity is the first branch in the decision tree, and the visible name alone is insufficient. Email applications often display “Maria Chen, CFO” or “IT Support” while hiding the underlying address. That gap allows a cyberattacker to borrow authority without owning the real mailbox.

Employees should open the sender details and compare the complete address with a known address from the company directory. Adaptive Security’s guide to checking a phishing email sender address walks through that comparison step by step.

A mismatch between the display name and the actual account is a warning signal. So is a lookalike domain that changes one character, adds a word, uses an unusual country-code ending, or substitutes a visually similar letter. An address such as finance@company.co deserves scrutiny when the organization normally uses company.com.

A familiar account does not end the inspection. Cyberattackers can compromise a supplier, executive, customer, or colleague and send a malicious request from a genuine mailbox. If the message is unusual for that person, arrives at an unexpected time, or asks for a new action, the employee should verify it independently.

The same principle applies to replies and forwarded threads. A real conversation can be hijacked, and a trusted sender can become the delivery channel for a fraudulent request. Identity counts as one signal among several. When the address, thread, or behavior does not fit, the employee should report the email through the organization’s approved process.

Urgency and Unusual Requests

This branch tests what the message wants and how quickly it demands action. Phishing frequently turns a routine business task into an emergency. The message may claim that a payment will be delayed, an account will close, a contract will be lost, or a manager is waiting for an immediate response.

A request to change bank details, redirect payroll, buy gift cards, disclose a password, approve a login, or send a file outside the normal system deserves independent verification. Requests to bypass approval procedures are especially significant.

Phrases such as “I am traveling,” “keep this confidential,” or “the usual approver is unavailable” do not override segregation of duties, dual approval, callback verification, or documented change control.

Payment changes require separate confirmation even when the email comes from a known vendor. Employees should use the supplier record, call the established contact, and confirm the account change with the responsible finance employee. A reply on the same email thread is insufficient to validate a new payment destination.

Password and multifactor authentication requests follow the same rule. No legitimate urgency makes it safe to send a password, provide a one-time code, or sign in through an unsolicited link. Employees should open the service through a saved bookmark or manually typed address and inspect the account there. If the request does not appear in the official system, the message should be reported.

Pop-ups and browser warnings inside an email can create another layer of pressure. A message might claim that malware was detected or that the employee must call support immediately.

The employee should not call the displayed number or install remote-access software. The safe response is to close the message, contact internal IT through the published help desk channel, and preserve the email for investigation.

CISA’s guidance on recognizing and reporting phishing recommends resisting urgent requests, avoiding suspicious links and attachments, and contacting a person or organization through an independently verified channel. That sequence protects employees from the pressure the cyberattacker designed into the message.

Writing, Branding, and Context Clues

Writing and visual design provide useful context, but neither works as a pass-or-fail test. Generic greetings, unusual wording, inconsistent terminology, strange formatting, unexpected attachments, and requests that do not match the employee’s role can reveal a mismatch between the sender’s claim and the situation.

Branding does not establish legitimacy. Cyberattackers can copy legitimate logos, color schemes, email signatures, invoice templates, login pages, and legal disclaimers. A polished message can still direct the recipient to a lookalike domain or malicious file. When a message matters, the employee should navigate independently to the organization’s known website or application.

Personalization also deserves careful interpretation. A message that includes an employee’s name, department, manager, recent project, or customer relationship can reflect information gathered from public profiles or stolen correspondence. Personal details increase credibility, but they do not validate the request. Employees should match the content to an expected business event and verify the action separately.

Perfect grammar is no longer reassuring. AI can produce clear, professional wording in an organization’s preferred style, translate messages quickly, and generate tailored versions for different recipients. A message with no spelling errors can still be phishing, while a genuine message can contain a typo. Identity, intent, requested action, channel, and process deserve more weight than the writer’s grammar.

A real-world example shows why context must outrank familiarity. In 2024, a caller posing as former Ukrainian Foreign Affairs Minister Dmytro Kuleba reached U.S. Sen. Ben Cardin through an apparently authentic video call.

According to NBC News’ account of the incident, the interaction became suspicious when the caller acted out of character and pressed for politically sensitive answers. Cardin’s staff did not need to spot a visual flaw. They ended the call, contacted the State Department through a separate channel, and notified authorities.

The same discipline applies to email. If identity, intent, language, branding, or context raises a question, the employee should stop the transaction, verify independently, and report the message.

Organizations can reinforce that behavior through phishing simulations that rehearse BEC, spear phishing, and QR-code attacks, giving employees practice before a high-pressure request reaches a real inbox.

How to Inspect Links, Attachments, and Authentication Signals With a Phishing Email Decision Tree

A phishing email decision tree should show employees how to inspect a message without activating its payload. Employees should isolate the message and review links, attachments, QR codes, sender details, and authentication indicators from the safest available view.

Each signal counts as evidence, and none of them counts as proof. Inspection stops when a message demands credentials, payment, downloads, or urgent action.

1. Reveal a Link’s True Destination Without Opening It

On a desktop, moving the pointer over a link without clicking reveals its destination. Most email clients show that address in a status bar or preview window. Employees should read the full web address and focus on the domain, which is the part that ends at the first slash. That domain determines where the link leads, whatever the visible link text says.

A message can display company.com while sending the reader to company-login.example.net. It can also use a lookalike domain such as micros0ft.com, add a misleading subdomain such as microsoft.com.attacker-site.com, or replace a familiar top-level domain with an unfamiliar one.

Employees should compare the destination with the organization’s known website. Branding, logos, colors, and a familiar display name carry no weight in that comparison. More detail on safe handling appears in Adaptive Security’s guide to phishing email links and attachments.

Shortened URLs conceal the final destination. A suspicious URL that may contain private information, a session token, or an internal document reference should stay out of public link-expanding services. The better path is to report the message through the approved process and let security staff analyze it in a controlled environment.

Mobile apps generally have no hover state. A long press can reveal a destination, but it can also open a context menu with options such as opening, downloading, or sharing. Employees should press and hold a link only when the application clearly separates preview from activation.

If the destination is hidden, truncated, or difficult to interpret on a phone, the employee can defer inspection until a managed desktop is available or report the message directly.

A QR code is simply a link in visual form, and it carries the same risk. Employees should use the camera or QR reader’s preview function only when it displays the decoded destination before opening it. The full URL may reveal a mismatched domain, shortened redirect, unexpected login page, or unfamiliar file download.

A QR code that leads to a Microsoft 365, Google, banking, payroll, or VPN login page deserves the same scrutiny as a credential link in an email. Employees should not authenticate through it. The safe route is a known bookmark or a manually entered address.

Calendar invitations and cloud-share notifications require the same inspection. An unexpected meeting request can contain a conference link, a fake cancellation notice, or a request to “verify” attendance. A cloud-storage alert can imitate a document-sharing service while directing the reader to a credential-harvesting page.

Employees should open the calendar or storage platform directly and check whether the event or shared file exists inside the trusted application. The email’s button is not a valid way to confirm it.

2. Identify High-Risk Attachments Before Downloading

Attachments require a separate branch in the decision tree because their payloads can activate during download, preview, extraction, or opening. Employees should not open, download, reply to, unsubscribe from, or forward suspicious content normally. They should report it through the approved mechanism, preserve the original message if policy requires it, and wait for confirmation from security staff.

File extensions provide a warning signal, but they do not establish safety. Executable and script-capable files such as .exe, .msi, .bat, .js, and .vbs call for particular caution. Archives in .zip and .rar format are also high risk because they can conceal those files, use misleading filenames, or bypass simple attachment filters.

A file named invoice.pdf.exe is an executable, even though its name suggests a PDF. On systems that hide extensions, employees should enable the option that displays complete filenames before evaluating an attachment. Adaptive Security’s overview of phishing email attachment types lists the formats that appear most often.

Office documents can also carry risk when they prompt the reader to enable macros or other active content. Any spreadsheet that asks the reader to click “Enable Content,” “Enable Editing,” or “Enable Macros” to display an invoice, unlock a salary report, or correct a document should be closed and reported.

Employees should not lower security settings, install a viewer, copy a command into a terminal, or move a file into a trusted folder simply because an attachment says to.

Automatic downloads create another danger. Some messages trigger downloads when a user previews content, clicks a calendar file, opens a cloud-share notification, or follows an externally hosted image. If a download begins unexpectedly, the employee should cancel it without opening the file.

Double-clicking the file, dragging it to another application, or uploading it to an unapproved website all put the device at risk. Security teams can examine the original attachment in a sandbox without exposing the employee’s device.

File icons and names are unreliable evidence. Cyberattackers can make an executable resemble a document, use a familiar supplier’s name, or attach a password-protected archive whose password appears in the email.

Password protection does not make an attachment trustworthy, and it can prevent mail scanners from inspecting the contents. Unexpected invoices, wire instructions, contracts, tax forms, and shared documents should be verified through a separate, known channel.

Organizations can reinforce this behavior through phishing simulations that include attachment, QR code, and cloud-share scenarios. Practice should teach employees what to do after a suspicious file appears. Encountering a realistic lure should never lead to punishment.

3. Interpret SPF, DKIM, and DMARC as Supporting Signals

Email authentication indicators can establish whether a message passed technical sender checks, but they cannot prove that the message is safe. Sender Policy Framework (SPF) checks whether the sending server is authorized to send mail for a domain.

DomainKeys Identified Mail (DKIM) uses a cryptographic signature to show that designated domain infrastructure signed the message and that key content was not altered in transit. Domain-based Message Authentication, Reporting, and Conformance (DMARC) evaluates domain alignment and tells receiving systems what to do when a message does not produce an aligned pass.

These results appear in the message’s security details, which carry more information than the visible sender line. A “pass” result supports the claim that the message came through an authorized service. It does not confirm that the sender is legitimate, the request is safe, or the account owner wrote it.

A compromised mailbox can send a malicious message that passes authentication. Cyberattackers can also abuse a trusted marketing, file-sharing, payment, or collaboration service. Adaptive Security’s comparison of SPF, DKIM, and DMARC explains what each protocol can and cannot confirm.

A “fail” result is a strong warning, while a “pass” result only clears one technical hurdle. Employees and analysts should check the authenticated domain and whether it aligns with the visible From address. A message that claims to be from a supplier but authenticates against an unrelated domain requires verification. A matching display name confirms nothing on its own.

CISA’s October 2023 phishing guidance treats SPF, DKIM, and DMARC as controls that support email authentication alongside attachment and link protections. These controls reduce spoofing opportunities, but human judgment and independent verification remain necessary.

4. Stop When the Message Requests Trust or Action

Inspection should end when the message asks for credentials, payment, confidential data, software installation, or a change to a known process. Replying to ask whether the sender is genuine is unsafe, because a cyberattacker can answer from the same compromised account.

The phone number, reply address, calendar link, and contact information supplied in the suspicious message are all off limits. Verification should run through a directory entry, a known company number, or an established internal channel.

An employee who already clicked, downloaded, scanned, replied, or entered credentials should report the action immediately. Speed gives security staff time to revoke sessions, reset credentials, remove related messages, and check for additional targets. Under pressure, the decision tree aims for three outcomes: a safe stop, a reliable report, and a verified path forward.

How to Use a Phishing Email Decision Tree to Verify a Suspicious Email

A phishing email decision tree should end with a verified action. “Looks legitimate” is not a valid endpoint. A message can pass basic checks and still feel unusual. In that case, the employee should pause, inspect it without interacting, and verify the request through a separate trusted channel. The task itself should be completed only through an approved portal or documented process.

Urgency, authority, payment changes, password resets, and sensitive-document requests all trigger stronger verification, even when the sender’s name, logo, thread, or account appears familiar.

1. Check the Message Without Interacting With It

Verification starts with observation. The employee identifies what the message asks for, who appears to be asking, what deadline it creates, and whether the request fits the sender’s normal responsibilities.

While that assessment is underway, the employee should not reply, click a link, open an attachment, scan a QR code, call a number in the signature, or use a “secure document” button.

A familiar appearance does not establish authenticity. Cyberattackers can compromise a real mailbox, copy a legitimate email thread, spoof a display name, reproduce a company logo, or send a message from an account the recipient recognizes. A correct signature shows only that the sender’s information was copied or that the account may be genuine. Authorization is a separate question.

Employees should separate two questions:

• Is the message genuine? Determine whether it came from the person or service it claims to represent.
• Is the request legitimate? Determine whether the person intended the action and whether the action follows business policy.

An authentic account can send a fraudulent request after compromise. A legitimate automated notification can also require careful handling if a cyberattacker triggered it. In both cases, the employee should verify the underlying event independently and set the message’s instructions aside.

A change in behavior is a stronger warning than a spelling error. An executive who normally routes payments through procurement may suddenly request a wire transfer. A vendor may ask for new bank details from an unfamiliar domain.

A colleague may demand an approval bypass because a deal is closing. A password-reset alert may arrive when the recipient did not attempt to sign in. Each mismatch increases the need for out-of-band confirmation.

2. Verify Through an Independent Channel

Independent verification means contacting the supposed sender through a channel the employee selected before opening or replying to the message. Suitable options include a phone number already saved in the employee’s contacts, a number in the corporate directory, a known internal chat conversation, or an official website reached separately.

Contact details in the suspicious email are unusable for this purpose, even if they match the organization’s branding.

A good confirmation question avoids repeating the cyberattacker’s instructions as fact. Examples include “Did you request a $48,000 wire to this beneficiary?” or “Did you ask me to upload the contract?” Naming the exact action, amount, destination, and deadline helps the person spot a manipulation attempt quickly.

For supplier requests, the employee should use the number in the vendor-management system or an established contract. The number in the new message does not qualify.

Executive requests should require a callback or second-channel confirmation before any transfer, gift-card purchase, credential disclosure, or confidential-data release. A request that says “do not call me” or “keep this between us” is a reason to escalate. It creates no exception to the process.

If the executive is unavailable, the employee should wait for confirmation or route the request through finance, legal, procurement, or the designated incident channel.

Organizations should formalize this rule so employees do not have to improvise. A documented callback process should specify who can approve a high-risk request, which directory or phone record is authoritative, what the employee must confirm, and where the confirmation is recorded. That structure protects employees from pressure and gives them permission to pause without appearing unhelpful.

Verification habits matter at scale. The FBI’s 2025 Internet Crime Report recorded 191,561 phishing and spoofing complaints, more than any other crime type in the report. A clear verification habit turns that volume into a repeatable defensive action.

3. Validate Business and Payment Requests

Payment changes require the strongest verification, because a convincing message can produce an irreversible financial loss in minutes. Every executive wire-transfer request, new beneficiary, bank-account change, invoice replacement, refund instruction, payroll update, or urgent procurement request is high risk, however familiar the sender appears.

Finance employees should compare the request with the organization’s records before processing it. Useful records include the vendor master file, purchase order, contract, prior invoice, approved banking details, and existing payment history.

The next step is to contact the vendor or internal requester through an established channel. A reply on the suspicious thread does not count as confirmation, because the cyberattacker may control the conversation. Adaptive Security’s guide on how to prevent business email compromise covers these payment controls in more detail.

Dual approval should apply when the request changes payment instructions, exceeds a defined amount, involves an unusual country or currency, or asks someone to bypass separation of duties. The second approver should review the original records independently. Approving the first employee’s conclusion without that review adds no protection.

High-value transfers should require a callback to a known number, and the name of the person who confirmed the details should be documented.

The same discipline applies when a message asks the recipient to bypass normal approval. Claims such as “The CFO approved this,” “legal is waiting,” or “the system is down, so use this temporary account” do not suspend any control. The employee should verify the claimed exception with the process owner and record the approval in the organization’s normal system.

A request that cannot survive ordinary review should not receive extraordinary access.

Sensitive-document exchanges need their own checkpoint. Employees should not upload tax records, employee data, acquisition documents, credentials, customer lists, or signed contracts to a link supplied by an unexpected email.

The safe route is the organization’s known client or file-sharing portal, opened by typing its saved address, using a bookmark, or navigating from the official company website. Before uploading anything, the employee should confirm the intended recipient, folder, permissions, and retention settings.

Organizations should define when out-of-band confirmation is mandatory. At minimum, the rule should cover payment or bank-detail changes, executive impersonation requests, credential disclosure, sensitive-document transfers, new external recipients, requests to disable security controls, and any instruction to bypass approval. It should apply even when the message arrives from a previously trusted account.

4. Complete Requested Tasks Through Trusted Portals

Trusted portals reduce the number of decisions made inside an untrusted message. An email may claim that an account is locked, an invoice is ready, a document needs signing, or a security alert requires action. In each case, the employee should skip the embedded button. The service should be opened through a known bookmark, the company’s official website, a managed application launcher, or the normal single sign-on page.

Once inside the portal, the employee looks for the event that supposedly triggered the email. A real password-reset request should appear in the account’s security activity. A real invoice should appear in the approved procurement system, and a real client document should appear in the established workspace.

If the event is absent, the employee should stop and report the message. If it is present, the task should be completed within the portal, with no return to the email link.

Legitimate automated notifications still deserve controlled handling. Password managers, identity platforms, banks, payroll systems, ticketing tools, and cloud services routinely send alerts, and cyberattackers imitate these messages because recipients expect them. Employees should verify a notification by signing in to the service independently.

No unexpected email justifies disclosing a password, multifactor authentication code, recovery key, or payment detail. A genuine service does not require anyone to surrender a one-time code to a person who made unsolicited contact.

Security teams can make the safe path faster by publishing approved portal addresses, maintaining accurate vendor and employee directories, and placing callback instructions inside finance and procurement workflows.

A phishing simulations program can rehearse executive requests, invoice changes, password resets, and document-sharing scenarios. Employees then practice pausing, verifying, and reporting without being shamed for an honest mistake.

When verification fails, the employee should stop investigating through the suspicious message. The employee should report it through the organization’s one-click phishing report button or designated security channel, preserve the original email, and describe any action already taken.

If credentials were entered, the employee should notify security immediately and change the password through the official portal. If money was transferred or banking details were changed, the financial institution and internal incident team need to hear about it without delay.

A sound decision tree ends with a controlled action, and appearance plays no part in the final judgment. Familiarity lowers suspicion, but only independent confirmation establishes trust.

How to Report, Preserve, and Delete a Suspected Phishing Email

Once a phishing email decision tree flags a message as untrustworthy, the employee should stop interacting with it and control where it goes. The message should be reported through the employer’s approved channel, and the original evidence should be preserved without exposing coworkers. Deletion comes only after the appropriate team confirms that preservation is complete.

Messages involving fraud, threats of violence, harassment, extortion, or suspected criminal conduct are evidence and deserve more care than ordinary spam.

1. Report the Message Through the Organization’s Channel First

The organization’s reporting button comes before any reply, click, or forward. Many workplaces provide a one-click phishing report button in Outlook or Gmail, while others use a security mailbox, service desk, incident form, or designated security channel.

The established process preserves context and routes the message to people who can inspect headers, search for copies, and remove the cyberthreat from other inboxes. Adaptive Security’s guide on how to report a phishing email covers the reporting options for each major platform.

Where a reporting button exists, the employee should select the suspicious message and submit it without opening links or attachments. A short note explaining what triggered concern helps analysts. Examples include an unexpected payment request, a login prompt, a mismatched sender domain, or a request to bypass normal approval.

Sensitive business information belongs in a restricted incident-reporting channel, when the organization provides one, and should stay out of general help desk tickets.

Security teams should receive the original message or a system-generated copy whenever possible. A screenshot alone does not preserve the routing information needed to determine where the message came from. A controlled reporting workflow also allows analysts to classify the message, identify other recipients, and remove matching copies before employees interact with them.

Platforms with a dedicated Phish Triage workflow can centralize reports, classify messages, and support reversible inbox remediation, so employees never need to circulate the suspected email.

Messages received at a personal address should be reported through the email provider’s phishing or abuse function. Individuals can also report phishing to the relevant national anti-phishing organization or government service. In the United States, the Federal Trade Commission accepts fraud reports, and the FBI’s Internet Crime Complaint Center accepts reports involving cyber-enabled fraud and crime.

The FBI IC3 complaint form instructs complainants to retain evidence. The original material should therefore be kept in a controlled location, and deletion should wait.

2. Preserve Evidence Without Spreading the Message

Evidence should be preserved before deleting an email that could support an investigation, financial recovery, disciplinary action, or criminal complaint. The employee can keep the original message in the mailbox or export it in the format the security team requests, such as an .eml or .msg file.

The message should stay out of shared folders, unapproved file-sharing services, and group mailboxes where someone could open it accidentally.

Useful evidence includes:

• Complete message headers
• Sender and recipient addresses
• Delivery timestamp and time zone
• Subject line and message body
• Embedded URLs
• Attachment names and original attachments
• Message ID, if the email client displays one

Headers can show the path the message took through mail systems and reveal differences between the visible sender name and the actual sending domain. The exact spelling of domains, including lookalike characters and unusual subdomains, should be preserved.

Screenshots help when they add context that an exported message does not show. A useful screenshot includes the sender display name, full address if available, subject, date, time, visible request, and any warning banner added by the email provider.

Screenshots of suspicious landing pages should be captured only when the security team asks for them. Employees should not revisit a link from an ordinary browser, enter credentials to test it, or download an attachment for inspection. Security analysts can examine files and URLs in a controlled environment.

A short evidence record should state when the message arrived and when it was reported. It should also note whether the employee opened it, clicked a link, entered credentials, or downloaded or opened an attachment. This timeline helps responders distinguish exposure from interaction.

Any click, submission, or opened file should be disclosed immediately. Early disclosure allows the security team to revoke sessions, reset credentials, isolate a device, or contact a bank before the cyberattacker acts.

Forwarding requires particular care. A suspicious message should be forwarded normally only when the organization’s documented process explicitly calls for it and the recipient is trained to handle it. Normal forwarding can alter headers, activate tracking content, or place a dangerous link directly in another person’s inbox.

When a security team requests the message, the employee should use the client’s “forward as attachment” function. This generally preserves the original message as a file and keeps its contents from displaying as a new email. Each organization should still define its approved method.

A suspected phishing email should never be forwarded to coworkers for awareness, posted in a team chat, or sent to a manager merely to ask whether it looks legitimate. Those actions turn one exposure into many. When broad notification is necessary, a sanitized screenshot or sender domain is enough, and the security team should distribute the advisory.

3. Handle Messages That Moved to Spam or Were Deleted

A message in a spam or quarantine folder can still support an investigation. The folder should stay intact, and the item should not be permanently deleted until the security team confirms it has the evidence it needs.

Employees should use the provider’s “not spam” or restore function only when instructed, because moving the message can change labels, timestamps, or available metadata.

An employee who deleted the email should check Deleted Items, Trash, archive, quarantine, and recovery folders. Retention settings differ by organization and account type, so the security team needs to know exactly when the message was deleted and from which folder. Repeated recovery attempts can overwrite the item or create confusion about which copy is original.

If the message is no longer recoverable, the employee should preserve whatever remains. That includes the sender, recipient, subject, approximate delivery time, visible text, URLs, attachment names, and reason for deletion.

Screenshots, browser history, endpoint alerts, email-provider notifications, and a colleague’s intact copy can help reconstruct the incident. The employee should not ask a coworker to resend the message. A coworker holding a copy should preserve it and submit it directly through the approved reporting channel.

4. Escalate Fraud, Threatening Messages, and Criminal Content

Escalation should be immediate when an email requests a wire transfer, payroll change, gift cards, credentials, regulated data, or an urgent vendor-payment change. The employee should contact the organization’s security and legal teams. If money moved, the bank or payment provider and law enforcement need to be contacted at once, since recovery procedures can depend on rapid notification.

Adaptive Security’s phishing incident response playbook outlines how security teams can structure that escalation.

Threats of violence, extortion, stalking, blackmail, child exploitation, and other potentially criminal content belong with law enforcement. Employees should not reply to the sender, negotiate, or test whether the threat is credible.

The original email, headers, attachments, screenshots, delivery details, and related messages should be preserved in a restricted evidence repository. Investigators’ instructions govern how the material is transferred.

Offensive or criminal content creates a second risk. Casual handling can destroy evidence, and unnecessary forwarding can expose coworkers to traumatic or illegal material. Employees should not copy explicit images into tickets, paste threatening text into public channels, or ask colleagues to review it.

The better approach is to tell the security, legal, human resources, or law enforcement contact what the message contains, then provide the original through the controlled process they specify.

After reporting and preservation are complete, the message can be removed from the inbox through the approved workflow. Until the security team confirms preservation, the message should remain untouched and out of view. The desired end state is a documented report, a protected evidence record, and a verified removal process that keeps the cyberthreat away from everyone else.

Phishing Email Decision Tree: What to Do After Clicking a Phishing Link or Opening an Attachment

After a click on a phishing link or an opened attachment, the phishing email decision tree shifts to response: stop interacting, preserve what happened, report it immediately, and follow the organization’s incident-response instructions.

A click alone calls for different follow-up from entering credentials, enabling macros, approving a multifactor authentication (MFA) prompt, replying, or sending data. Fast reporting gives the security team more time to contain access, protect other employees, and determine whether the message was part of a wider campaign. Adaptive Security’s phishing email response checklist lists the follow-up steps in order.

1. Stop Interacting and Contain the Device

Immediate containment limits the cyberattacker’s opportunity to turn one interaction into account access or malware execution. The employee should stop clicking, typing, downloading, replying, forwarding, or calling any number in the message. Revisiting the page to check its legitimacy, or continuing a suspicious conversation with the sender, only extends the exposure.

If the employee clicked a link but did not enter information, the next step is to close the browser tab and report the message. A file that the page downloaded should stay unopened. An opened attachment should be closed without enabling additional content, including prompts such as “Enable Content,” “Enable Editing,” or “Run.”

A macro-enabled document can execute code once macros are enabled, so that action is a higher-severity event than opening a file alone.

If the device begins behaving abnormally, the employee should stop using it and contact the security team through a known, trusted channel. Warning signs include unexpected pop-ups, a locked screen, a new browser extension, disabled security tools, unfamiliar login prompts, rapid file changes, a continuously running fan, or inaccessible files.

If the organization’s incident-response plan directs employees to isolate suspected malware, the employee can disconnect Wi-Fi or unplug the network cable. Improvised isolation of a critical system, shared workstation, medical device, or operational technology device should wait for organizational guidance. Abrupt disconnection can interrupt operations and remove useful remote-response options.

The CISA #StopRansomware Guide advises organizations to isolate affected systems quickly while preserving evidence and coordinating response. Employees should isolate a device when compromise is plausible and the security team’s procedure calls for it, then report the incident from another device if necessary.

2. Protect Credentials, Accounts, and Money

Credential exposure requires a different response from a link click, because a cyberattacker can attempt account takeover after the phishing page disappears. An employee who entered a username, password, passcode, recovery code, security-question answer, API key, or other secret should tell the security team exactly what was entered.

The exposed password should then be changed from a known-clean device. The suspicious email, text, or page is never the place to change it.

The same password should be changed anywhere else it was reused, starting with email, identity-provider, banking, payroll, administrative, and cloud accounts. Each account should have a unique password. When the exposed credential belongs to the employer, the security team should direct the reset so it can revoke tokens, investigate sign-ins, and preserve the correct timeline.

After the reset, MFA should be enabled, preferably with the organization’s approved authenticator or a hardware security key. MFA does not make a stolen password harmless, but it adds a control the cyberattacker must defeat. Adaptive Security’s phishing-resistant MFA guide explains which methods hold up best against credential phishing.

An approved unexpected MFA prompt, a supplied one-time code, or an accepted login request the employee did not initiate means the account is actively targeted. The employee should report the approval immediately and change the password from a clean device. The security team should revoke active sessions, refresh tokens, reset MFA methods, and review recent sign-ins.

Clicking “Allow” for a browser notification, application permission, file-sharing request, OAuth connection, or remote-access tool also requires escalation. Uninstalling an unfamiliar application is insufficient on its own. Security staff need to determine what permission was granted and revoke it from the correct administrative console.

Financial exposure demands parallel action. An employee who entered card details, bank credentials, tax information, payment instructions, or authentication codes should contact the bank or card issuer through the number on the back of the card or its official website. The conversation should cover whether transactions, transfers, cards, beneficiaries, or online-banking sessions need to be blocked or monitored.

If the employee approved a wire, gift-card purchase, cryptocurrency transfer, payroll change, or vendor-payment request, the organization’s finance team and bank need to be contacted immediately through an independently verified number. Payment-recall options narrow as funds move.

The Federal Trade Commission’s January 2025 alert on QR-code phishing directs people who submitted credentials to change the password right away. The same principle applies to a phishing email, attachment, text message, vishing call, or deepfake request. The account or payment channel should be protected directly, through contact details the cyberattacker did not supply.

3. Escalate Internally and Preserve Evidence

After containment, reporting is the most useful action. Security teams can block related messages, search for other recipients, revoke access, and warn employees before the campaign spreads.

Employees can report through the organization’s one-click phishing report button, incident portal, help desk, or emergency security number. If those tools are unavailable, a known phone number or separate messaging channel works. The report should state whether the employee clicked, entered credentials, downloaded or opened a file, enabled macros, replied, approved MFA, sent data, or initiated a payment.

The original email, attachment, text message, call details, browser address, screenshots, and timestamps should all be preserved. Forwarding should happen only if the organization’s procedure requests it, because ordinary forwarding can alter headers or expose malicious content to another person.

Until the security team gives instructions, the employee should not delete the email, empty the trash, wipe the device, uninstall software, clear browser history, or run unauthorized cleanup tools. Those actions can remove indicators that help investigators identify the phishing infrastructure, determine who else was targeted, and confirm whether access occurred.

A useful report answers five practical questions. What happened? When did it happen? Which device and account were involved? What information did the employee enter, send, download, or approve? What changed afterward?

The report should include the sender address, subject line, URL, file name, phone number, payment details, and screenshots when available. Employees should state uncertainty plainly. A statement such as “I clicked the link but do not remember whether I entered my password” is useful information and does not represent a failure.

Law enforcement should be contacted when the incident involves financial fraud, extortion, threats of violence, identity theft, sensitive personal information, or significant business loss. The organization’s legal, privacy, compliance, and insurance teams may also have notification duties. Employees should not negotiate with an extortionist or send additional information without direction from the appropriate response team.

Managers have a separate responsibility when the interaction came from a phishing simulation. The correct response is prompt, private coaching. Public embarrassment and punishment have no place in it.

A manager should thank the employee for reporting, confirm whether further action is needed, explain which signal the simulation tested, and assign targeted practice on the missed behavior. Useful questions include what made the message credible, whether the reporting process was easy to find, and whether the scenario matched the employee’s work.

A failed simulation should produce better skills, clearer reporting paths, and stronger future decisions. An employee who reports quickly strengthens the organization’s defense, even when the first decision was wrong.

Each incident can also improve the wider program. Repeated failures on invoice requests point to a need for finance-team rehearsal. MFA approvals indicate a need for stronger push-fatigue training. Macro-enabled attachments call for technical controls and clearer document-handling guidance, while replies and data transfers require role-specific practice around verification and approved channels.

Phishing simulations can turn these observed behaviors into controlled, multi-channel exercises without exposing real credentials or business data.

Once the immediate response is complete, the lesson should be written down while the sequence is fresh. A decision tree works only when employees can act without fear of blame. The response sequence of stopping, containing, reporting, protecting exposed accounts, preserving evidence, and letting the response team determine the full scope gives the organization its best chance to limit damage.

How a Phishing Email Decision Tree Changes Across Gmail, Outlook, Apple Mail, Yahoo Mail, and Mobile Apps

A phishing email decision tree should lead to the same safe action whether a message appears in Gmail, Outlook, Apple Mail, Yahoo Mail, or a mobile app. The interface changes where users find sender details, URLs, reporting controls, and recovery folders.

The sequence itself stays consistent: pause, inspect without opening, verify independently, report, and delete only after preserving required evidence. Employees need platform-specific directions that do not require a different security judgment in each inbox.

Desktop Webmail and Native Mail Clients

Desktop screens make inspection easier because users can expand sender information, hover over links without selecting them, and preserve headers or screenshots before changing the message.

In Gmail, users select the message’s More menu and choose Report phishing, following Google’s Gmail phishing guidance when a message is incorrectly marked.

In Outlook, users select the message and choose Report > Report phishing. The View > View message details option can expose the sender address and internet headers, as described in Microsoft’s Outlook phishing and message-header instructions.

Apple Mail and Yahoo Mail use different labels and menu locations, but the inspection logic remains stable. Users can expand the From field to reveal the complete address and inspect the Reply-To address. Where the option exists, the context or message menu can mark the message as junk or phishing.

If the platform offers only Junk, Spam, or Block Sender, employees should also use the organization’s approved reporting address or report button.

Moving a suspicious email to spam does not necessarily create an incident record for the security team. Employees should report through the approved channel even when the mail client has already filtered the message.

Evidence should be preserved before deletion when the message involves payment instructions, credential requests, confidential data, or suspected account takeover. That record covers the sender address, subject, timestamp, visible links, attachment names, and relevant screenshots. The original message can then be forwarded as an attachment when the reporting process requests it.

If a legitimate message lands in spam or trash, the employee should recover it from that folder. Asking the sender to resend sensitive content creates unnecessary exposure.

Mobile Email Behavior

Mobile email requires stricter discipline because apps often hide the destination URL and full sender address until the user takes an additional action. Employees should not tap a link, download an attachment, call a number in the message, or reply to ask whether the request is genuine.

The safer approach is to use the message details option to inspect the sender and verify the request through a trusted phone number, known portal, or separate conversation.

Gmail for Android places reporting controls in the More menu, while Outlook mobile uses its top-right menu and offers reporting choices such as junk or phishing. Apple Mail on iPhone and iPad may route spam controls through the account provider. Organizations should therefore provide a clearly labeled reporting address or button that works inside the app. Yahoo Mail’s mobile controls also vary by account configuration.

When the mobile interface cannot expose enough evidence, the employee should stop handling the message and move to a managed desktop workflow. That pause keeps a compressed interface from forcing a rushed decision.

Organization-Managed Reporting Workflows

A consistent organization-managed workflow removes uncertainty when platform buttons differ. Employees should have one approved reporting path, such as a one-click report button, dedicated security mailbox, or in-app report action. The guidance should also state whether employees report first, preserve evidence first, or do both.

A phishing response workflow can classify the message, notify the security team, and preserve the report while analysts investigate.

Security teams should document what happens after a report. The process should identify who reviews the message, how suspicious copies are quarantined, when related messages are removed from other inboxes, and how legitimate messages are restored.

Reporting a message that turns out to be safe should carry no blame. Every report creates a useful signal, and reversible analyst actions let the team correct false positives without discouraging future reports.

Accessibility for Printable and Digital Decision Trees

Accessibility determines whether a decision tree works under pressure. Digital versions need keyboard-focusable controls, logical tab order, descriptive screen-reader labels, and text equivalents for icons such as shields, warning signs, and report buttons.

Red and green should never carry risk information on their own. Color should be paired with words such as Stop, Verify, Report, and Delete. Readable contrast, generous spacing, plain-language branches, and short instructions also help the guidance stay clear when enlarged or read aloud.

A printable flowchart should state every action in text, since arrows and symbols alone can be missed. A digital infographic should provide alt text that explains the decision path and should keep the same sequence across desktop and mobile examples. Platforms will change, and accessible guidance keeps the safety decision stable when pressure and uncertainty are highest.

How to Apply the Phishing Email Decision Tree to BEC, Spear Phishing, Quishing, and Automated Notifications

A phishing email decision tree separates ordinary warning signs from the context cyberattackers use to make targeted messages feel legitimate. Generic rules focus on spelling, unfamiliar senders, and suspicious links. A decision tree also tests identity, timing, workflow, authentication context, and the scope of the request.

Spear phishing and BEC often rely on accurate personal or business details, with few obvious errors. QR-code phishing, vendor impersonation, calendar invitations, and fake account alerts also move the risky action outside the email itself. Distrusting every message is impractical. The goal is to pause when a request conflicts with normal business behavior and verify it through a trusted path.

How Should Employees Handle Executive and Finance Requests?

Executive and finance requests require the highest level of scrutiny, because whaling and BEC exploit authority, urgency, and payment workflows. Any message that appears to come from a CEO, CFO, controller, supplier, or attorney needs verification. That applies whenever it requests a wire transfer, gift cards, payroll changes, tax documents, credentials, confidential files, or a change to vendor payment details.

The decision tree asks whether the request is expected, whether the timing makes sense, and whether the sender wants an action outside the normal workflow. Employees should compare the sender’s address and reply-to field with known records, and a familiar display name should carry no weight as proof of identity.

Employees should also check whether the request bypasses approval rules, introduces secrecy, or pressures the recipient to avoid a colleague who normally reviews the transaction.

Independent verification means calling the executive or vendor at a phone number already stored in the company directory or accounting system. Employees should open the finance or procurement platform directly and ignore any invoice link in the message. If a sensitive request cannot be confirmed through the established workflow, the employee should stop and report it.

Organizations can reinforce this behavior with phishing simulations that model BEC and vendor impersonation, giving finance and executive teams practice without assigning blame.

What Changes When the Sender Is Familiar or Possibly Compromised?

A familiar sender lowers suspicion but does not establish legitimacy. Cyberattackers can compromise a mailbox, spoof a colleague’s identity, or use a real conversation thread to deliver a malicious link, attachment, QR code, or payment request. The risk rises when the sender’s normal writing style changes, the request falls outside the person’s role, or the message arrives at an unusual time.

Employees should review the full sender address, the authentication indicators supplied by the mail service, and the message history. Authentication context can show whether the message passed the organization’s domain checks. A legitimate account can still send a malicious message after takeover, so a passing result does not clear a possibly compromised sender.

The sender should be contacted independently through chat, phone, or a new email thread, and the suspicious conversation should be left alone. For a shared document alert, the employee should open the collaboration platform directly. The checks are whether the file exists in the expected workspace, whether the sender actually shared it, and whether the requested permissions match the task.

For a calendar invitation, the employee should confirm the organizer, meeting purpose, attendees, and any attachment or conferencing details before accepting.

How Can Employees Distinguish Legitimate Automated Notifications From Phishing?

Automated messages deserve a workflow check before any trust is extended. Account-security notifications, password-reset alerts, delivery notices, shared-document messages, and calendar invitations can look polished because cyberattackers copy the language and branding of real services. The key test is whether the notification matches an action the recipient actually initiated.

Timing comes first. A password-reset message that arrives immediately after a user opened the account’s security page is consistent with normal activity. The same message received without a recent request requires investigation.

The employee should open the service through a bookmarked address or manually typed domain, then review alerts, sessions, documents, invitations, or password-reset activity inside the account portal. The message’s button should play no part in reaching that portal.

Request scope comes next. A notification that confirms an action differs from one that asks for credentials, payment, MFA codes, software installation, or permission to access unrelated files.

Quishing is especially deceptive, because scanning moves the interaction to a phone where familiar desktop inspection tools are unavailable. Employees should treat the QR code as a link and complete the task through the service’s independently accessed portal.

What Should Employees Do When Every Basic Check Passes but the Message Still Feels Wrong?

A clean sender address, valid branding, familiar context, and successful authentication checks do not eliminate risk. Sophisticated spear phishing can use relevant personal or business details, imitate normal workflows, and avoid obvious technical warnings. When the message still feels wrong, the employee should stop before clicking, scanning, replying, transferring funds, or sharing information.

The next step is out-of-band verification with the supposed sender or service owner, using independently obtained contact information. The employee should also report the message to the security team, even if no link was opened.

Security analysts can compare the message with related activity, inspect authentication and delivery data, and warn other employees if the same campaign is spreading. A cautious report is a useful security signal and reflects good judgment on the employee’s part.

How to Train and Measure Phishing Email Decision Tree Behavior

A phishing email decision tree gives employees a repeatable way to pause, inspect, verify, report, and escalate when risk remains unclear. Security teams should test that sequence across email phishing, spear phishing, vishing, smishing, deepfake-enabled impersonation, QR phishing, and sensitive-request scenarios. Programs should measure the decisions employees make, with module completion serving only as a starting point.

Simulated failures work best as coaching signals and should never be treated as evidence of personal failure. Programs should adapt to each employee’s role, exposure, workflow, language, and accessibility needs so employees become a stronger line of defense against social engineering.

1. Teach the Sequence Through Realistic Scenarios

Employees retain a decision tree when they practice it under believable conditions. Training can start with a short explanation of the sequence, then place employees in scenarios that require a decision. Recalling definitions does little to build that habit. Adaptive Security’s guide on how to train employees to recognize phishing emails describes how to structure that practice.

An email that appears to come from a supplier should test invoice verification. A spear phishing message should test whether an employee examines the sender, context, and requested action before opening a file. A QR phishing message should test whether the employee treats the phone as another attack surface and resists assuming the code is safe.

The same sequence extends beyond email. A vishing simulation should ask an employee to challenge an urgent caller who claims to be an executive or IT administrator. A smishing simulation should test whether the employee avoids opening a text link and verifies the request through a trusted channel. The differences between vishing and smishing shape how each scenario is built.

Deepfake-enabled impersonation should test whether a familiar face or voice overrides established approval procedures, and a deepfake awareness training checklist can guide that scenario design. Sensitive requests involving payroll changes, wire transfers, credential resets, or confidential data should require independent verification, even when the request appears to come from a senior leader.

Supportive feedback should follow every exercise. It should explain which signal mattered, which action protected the organization, and how to report the event. Language that labels an employee careless or gullible undermines the program.

Simulations build a practiced response before pressure, authority, urgency, or familiarity compresses judgment. A multi-channel phishing simulation program allows security teams to rehearse these decisions across the channels employees use every day.

2. Measure Employee Decisions at Each Checkpoint

Completion percentages show exposure to training. They do not show whether employees can interrupt a cyberattack. A useful measurement framework records behavior at each decision point and connects it to the risk associated with the employee’s role.

Reporting rate shows whether employees use the approved reporting path. Median report time shows how quickly a suspicious message reaches security. Unsafe-click rate identifies who followed a risky link or opened an attachment.

Credential-submission rate matters because entering a password creates far greater exposure than clicking a harmless simulation link. False-positive rate ensures employees receive credit for reporting legitimate messages when uncertainty is reasonable. Adaptive Security’s guide on how to measure a phishing simulation program covers how to track these metrics over time.

Repeat behavior should be measured by role, department, and attack type. A finance employee who repeatedly approves simulated invoice changes needs different coaching from a mobile employee who struggles with smishing. Remediation completion should confirm that assigned coaching was finished and followed by a safer decision in a later scenario.

Results should be segmented before anyone draws conclusions. Useful comparisons include departments, executive exposure, finance workflows, remote and mobile usage, and language or accessibility needs. Executives and assistants often face high-authority impersonation risk, while finance teams need practice with sensitive-request verification and business email compromise scenarios.

Remote employees may rely more heavily on chat, text, and voice calls. Employees who work primarily on mobile devices need scenarios designed for smaller screens and limited sender context. Language and accessibility analysis keeps confusing instructions or inaccessible formats from being misclassified as judgment failures.

3. Improve the Flow Over Time

Managers should respond to a simulated failure with a private, specific coaching conversation. That conversation reviews the exact decision point, asks what the employee noticed, explains the missing verification step, and assigns a short remediation exercise.

Failure leaderboards and public embarrassment do not belong in the program. Employees who understand the correction become stronger reporting partners, while employees who expect blame are less likely to report the next suspicious message.

Security teams should vary scenarios while keeping the core sequence fixed. Sender identities, business contexts, channels, timing, languages, and request types can all rotate. Difficulty should increase only after employees demonstrate the required behavior, with immediate feedback when a scenario reveals a gap.

Monthly reviews can surface recurring patterns, such as high reporting but slow escalation, low click rates but frequent credential submission, or strong email performance alongside weak vishing performance. Each pattern points to a specific adjustment in coaching, verification procedures, or manager guidance.

Annual completion percentages can document participation, while decision-level measures show whether the organization is reducing human risk. That combination keeps the decision tree operational. Employees know what to do, managers reinforce it, and security leaders can see where judgment still needs practice.

Why Phishing Email Decision Trees Belong in Modern Cybersecurity Awareness Training

A phishing email decision tree turns cybersecurity awareness training into a repeatable action under pressure. Employees who pause, verify, and report when a message pushes urgency become an active security control.

NIST SP 800-50 Revision 1 (2024), which covers cybersecurity and privacy learning programs, identifies behavior change as a core program outcome. A record of course completion alone does not meet that bar. The broader shift toward human risk management follows the same logic.

From Annual Awareness to Behavioral Change

Annual awareness training creates a completion event, and behavioral change creates a security habit. A decision tree gives employees a short sequence for messages requesting credentials, payment, confidential data, or an unusual action. The sequence is to pause before responding, inspect the request, verify it through a trusted channel, and report it when doubt remains.

That sequence matters because social engineering attacks compress decision time. An email that appears to come from a manager can quickly become a phone call from a cloned voice, a text message from a spoofed supplier, or a video meeting featuring a deepfake executive. Rehearsing the same response pattern across realistic scenarios helps employees recognize manipulation, which memorizing isolated warning signs cannot do.

Role-specific practice makes the framework more useful. Finance employees should rehearse their response to invoice changes and urgent wire requests. Human resources teams should practice handling payroll and employee-record lures.

Executives and their assistants need scenarios involving confidential transactions, travel, acquisitions, and impersonation. Developers and administrators require practice with access requests, security alerts, and fake support messages.

Punishing an incorrect decision accomplishes little. Realistic practice helps each employee make a safer decision faster the next time pressure rises. A modern security awareness training program should reinforce the decision tree through short, recurring exercises and move past reliance on one annual reminder.

From Email-Only Rules to Multi-Channel Judgment

Email remains a common delivery channel, and the judgment employees need extends to voice, SMS, collaboration tools, social media, and video calls. A suspicious request does not become trustworthy because it arrives through a familiar application or uses a recognizable voice.

Cross-channel practice should teach employees to identify the requested outcome before evaluating the message. The core question is whether someone wants money, credentials, sensitive information, a new payment destination, or an exception to normal procedure.

Employees can verify the request independently through a known phone number, established ticketing process, or previously trusted contact. Contact details supplied in the suspicious message should play no part in that check.

This approach also addresses AI-generated spear phishing and attacks informed by open-source intelligence (OSINT). Public profiles, conference appearances, reporting structures, business relationships, and travel schedules can give cyberattackers enough context to make a request feel credible.

Training should explain what a suspicious message looks like and also why a precise request can still be manufactured from public information. An OSINT risk assessment shows how much of that context is already exposed.

From Completion Records to Measurable Risk Signals

Completion records show that an employee opened or finished training. They do not show whether the employee recognized a deceptive request, verified an unusual instruction, or reported a cyberattack quickly. Stronger governance tracks behavioral signals such as simulation reporting rates, repeat failures by attack type, verification behavior, time to report, and improvement after targeted reinforcement.

Those signals should be interpreted by role and exposure, and they should stay out of any public ranking system. A finance team facing frequent payment fraud scenarios has a different risk profile from a software team targeted with access-token lures.

OSINT exposure, public executive impersonation risk, and recurring contact with external partners can guide training priorities without turning employees into fixed risk labels. A structured approach to human risk scoring helps keep those signals consistent.

Board-ready reporting should connect those signals to decisions. A useful report can show which departments face the highest exposure, which attack channels produce repeated errors, whether reporting speed is improving, and where governance controls require reinforcement.

The same NIST learning-program guidance places measurement and continual improvement within the program life cycle, supporting a shift from compliance evidence toward observable risk reduction.

A decision tree is a behavior framework, and it cannot guarantee that every cyberattack will be identified. Skilled cyberattackers will produce convincing messages, synthetic voices, deepfake video, and trusted-looking collaboration requests. Organizations reduce exposure by giving employees a consistent response pattern, practicing it across channels, reinforcing it continuously, and measuring whether behavior improves under pressure.

Phishing Email Decision Tree FAQs

What Is a Phishing Email Decision Tree, and Why Is It More Effective Than General Anti-Phishing Rules?

A phishing email decision tree is a repeatable sequence of questions that turns vague suspicion into a safe action: pause, inspect, verify independently, report, and remove the message only after evidence is preserved.

It outperforms general anti-phishing rules because it guides judgment across changing tactics, including lookalike domains, compromised accounts, QR codes, and urgent payment requests. A single warning sign should stop the interaction, and passing every check still does not prove safety.

CISA guidance on recognizing and reporting phishing recommends avoiding links and verifying questionable messages through trusted channels. Practicing the sequence gives employees a consistent way to protect themselves and the organization.

What Should Employees Do if a Phishing Email Has Already Been Deleted or Moved to Spam?

If a phishing email was deleted or moved to spam, the employee should report it through the organization’s report button or help desk and explain where it went. Restoring, opening, replying to, or forwarding the message normally just to investigate it adds risk.

If the mail system allows safe recovery, the original message, headers, sender address, timestamp, URLs, and attachments should be preserved through the approved evidence process. The employee should also tell security whether they clicked, replied, downloaded anything, or entered information. CISA’s guidance favors reporting suspicious messages over interacting with them, because a report can help protect other users.

Can a Phishing Email Still Be Dangerous if It Comes From a Familiar or Compromised Account?

Yes. A phishing email remains dangerous when it comes from a familiar or compromised account. The cyberattacker can use a trusted identity, real conversation history, or expected business context to slip past instinctive checks.

Unusual payment requests, password prompts, shared files, MFA approvals, and requests to bypass normal procedures deserve suspicion even when the display name and address look correct. The employee should not reply to verify the request. The safer step is to contact the person through a previously saved phone number, directory entry, or separate chat channel, then report the message.

How Can Employees Tell Whether a Legitimate Automated Email Is Safe Using SPF, DKIM, and DMARC?

SPF, DKIM, and DMARC can support a legitimate automated email’s authenticity, but they cannot prove that the message or request is safe. SPF checks whether the sending server is authorized for the envelope domain. DKIM verifies a cryptographic signature, and DMARC checks alignment between authenticated domains and the visible From domain while applying the sender’s policy.

Employees and analysts should review the authentication results and domain alignment, then confirm the expected timing, request, destination, and account activity through a trusted portal. A compromised approved account or abused service can pass authentication while delivering phishing content.

Canadian Centre for Cyber Security guidance explains how DMARC builds on SPF and DKIM, and none of the three replaces message judgment.

What Should Employees Do After Entering a Password or Financial Information in Response to a Phishing Email?

An employee who entered a password or financial information in response to a phishing email should stop interacting with the message, report the incident immediately, and protect the exposed account or funds. The password should be changed from a known-clean device, along with every account where it was reused. Active sessions should be revoked where available, and MFA should be enabled.

The employee should then contact the bank or payment provider through its official number, explain the exposure, and follow its fraud instructions. The message and transaction details should be preserved without forwarding the phish normally.

The security team needs to know exactly what was entered and when, without waiting for proof of misuse. CISA’s MFA guidance explains that multifactor authentication adds protection when a password is compromised. Fast reporting gives responders time to contain the damage.

Reinforce Phishing Decisions With Measurable Security Awareness

Inconsistent responses to convincing phishing messages leave accounts, money, and sensitive data exposed. A live workflow turns the pause, verify, and report behaviors of a phishing email decision tree into practice that teams can measure and reinforce. Take a self-guided tour of phishing simulations and behavioral reporting.