Phishing and business email compromise are easy to describe poorly. A message arrives, something feels wrong, and the room begins arguing about whether it is fake. Good defensive triage slows that moment down. The first question is not whether the message is malicious. The first question is what the message is asking a person or system to do, what evidence supports the request, and what business process would normally confirm it.
Cybersecurity Encyclopedia is written for technical founders, IT managers, junior analysts, students, security-curious engineers, small-business operators, and AI builders. It assumes curiosity, not a security operations center. The goal is to make defensive thinking clearer without making the reader overconfident.
Quick facts
This guide belongs in the attack-path portion of the encyclopedia because phishing and business email compromise are often entry points into larger stories. The level is beginner, but the habit is useful at every level: separate the visible request, the claimed identity, the communication channel, the business action, and the evidence that would make the action safe. When those pieces are written separately, a suspicious message becomes easier to discuss without panic.
Defensive mental model
A phishing message is not only an email with a suspicious link. It is an attempt to move a person from ordinary caution into an unsafe action. That action might be entering credentials, approving a payment, changing bank details, opening an attachment, granting app access, or simply replying with sensitive information. Business email compromise is especially difficult because the message may be plain, polite, and free of obvious technical tricks. It often borrows a real relationship, a real invoice rhythm, or a real executive name.
The defensive model starts with the requested action. A message asking an employee to review a public document is different from a message asking for a payroll change. A message asking a vendor to resend an invoice is different from one asking finance to bypass a known approval path. The risk is not only inside the message body. It sits at the intersection of identity, timing, authority, and consequence.
This is where Security Alerts Without Panic helps. A warning sign is a reason to gather evidence, not a reason to improvise a verdict. The right answer might be to block a message, warn a user, preserve headers, call a known contact, or escalate to incident response. The wrong answer is to let urgency choose the next step.
Toy scenario
Imagine a small company receives an email that appears to come from a long-time supplier. The message says the supplier has changed banks and asks for the next payment to use a new account. The writing style is close enough to normal. The invoice number matches a real project. The sender name looks familiar. No malware alert fires. The message is risky anyway because it asks for a change to a money-moving process.
A calm review writes down the claim before judging it. The claim is that a trusted supplier has changed payment instructions. The evidence visible in the message includes the sender display name, the sending address, the reply-to path, the date, the invoice reference, and the requested change. The evidence outside the message includes the known supplier contact, the usual contract process, recent account activity, prior messages in the thread, and the organization’s policy for payment changes.
The key move is to verify through a channel that the message did not provide. Calling a known phone number from the vendor file is stronger than replying to the message. Asking an internal owner who manages the supplier relationship is stronger than relying on an executive display name. Checking whether similar messages arrived for other teams may reveal a broader campaign, but it should not replace the business verification needed before money moves.
Evidence that changes the story
Email triage often goes wrong when defenders treat one clue as decisive. A newly registered lookalike domain is meaningful, but a compromised real account can send from a legitimate domain. A passed authentication check is useful, but it does not prove the message is safe. A familiar writing style is helpful, but copied thread history can make a message feel ordinary. A bad grammar clue can matter, but polished language does not clear the request.
The better question is what each clue changes. Sender authentication may change confidence that the domain authorized the message. It does not prove the sender’s account was not compromised. Thread history may change confidence that the sender knows the business context. It does not prove the request follows the real process. A link destination may change confidence about credential-harvesting risk. It does not address a request to wire funds by phone or reply with tax data.
Defenders should also preserve enough evidence for later review. The visible message alone may omit routing details, authentication results, and reply-to behavior. If the situation could become an incident, capture headers, timestamps, user reports, mail gateway events, and any business actions already taken. Evidence Notes and Chain of Custody explains how to keep observations, decisions, and handoffs separate so the record remains useful.
Business process matters
Many phishing discussions focus on user mistakes. That framing is too narrow. People make safer decisions when the business process gives them a stable path. Payment changes should have a known verification route. Password resets should not depend on a manager’s hurried message. Sensitive document sharing should have a place to ask for review. A suspicious message should not leave the recipient choosing between ignoring work and becoming a private investigator.
Business email compromise takes advantage of ambiguity. If the normal approval path is informal, a fake urgent path can look normal. If executives often ask for exceptions, an impersonated exception blends in. If finance, HR, and procurement each use different verification habits, an attacker only needs to find the weakest route. A defensive improvement may be as simple as making one high-risk process explicit and rehearsed.
Identity controls still matter. MFA, Passkeys, and Recovery Paths reduces the chance that a stolen password becomes a usable account. Valid Accounts explains why legitimate credentials are hard to reason about after compromise. But controls are strongest when paired with process. If a real mailbox sends a payment-change request, a second channel still matters because the account itself may be the thing under suspicion.
Practice in a safe setting
A safe practice exercise can use toy messages written for training. Give one group a benign invoice reminder, another a fake payment-change request, and another a suspicious document-sharing request. Ask reviewers to write the requested action, the claimed identity, the business consequence, the evidence visible in the message, and the next verification step. The goal is not to shame anyone for missing a clue. The goal is to make the review language consistent before a real incident.
The same exercise works for small teams without a formal security program. A founder can ask how bank-detail changes are verified. A school administrator can ask how parent data requests are confirmed. A nonprofit can ask who can approve new payment destinations. A software team can ask how OAuth app requests are reviewed. The defensive habit is portable: high-consequence requests deserve evidence outside the message that carries the request.
What to read next
After this guide, read Email Authentication Signals to understand what sender checks can and cannot prove. Then read Incident Timeline Building if a suspicious message may have led to an action. Timelines are especially useful when a message, a user report, a mailbox login, and a business decision happened close together but not in the order people first remember.
Official references
The broad control language in the NIST Cybersecurity Framework and CIS Critical Security Controls is useful here because phishing defense touches awareness, identity, logging, access control, and incident response at once. MITRE ATT&CK is useful as a shared vocabulary for understanding how initial access and valid accounts can appear in defensive stories, but a real investigation should still follow local policy and qualified incident-response guidance.
