If an email changes where money, payroll, or sensitive information should go, pause the process and verify it through a known-good channel. That single rule gives a small organization a practical defense against many business email compromise (BEC) attempts.

The FBI's BEC guidance describes a fraud in which an attacker uses a compromised account or impersonates a trusted person to induce a transfer, payment, or disclosure. This is not only a technical problem. It is a business-process problem involving email, identity, finance, HR, and judgment under pressure.

BEC can overlap with credential phishing, but the terms are not interchangeable. Broad phishing often casts a wide net to steal credentials or deliver malware. BEC is the fraud objective: a targeted request that tries to make a real person take a high-impact action. It may use a lookalike domain, a compromised legitimate mailbox, a hijacked reply chain, or no malicious link at all.

This guide is for organizations without a dedicated security team. It focuses on what to do before a payment request arrives, what to do when one feels wrong, and what to do in the first hour after a suspected or completed fraud.

Test Your Team Against Real BEC Templates

Download 5 phishing test email templates, an answer key, and a 15-minute debrief script — free.

No spam. Unsubscribe anytime.

Recognize the request, not just the email

A BEC attempt often looks like routine work. The request may arrive by email, text, chat, or a reply to a real conversation. Treat these patterns as a reason to verify, not as proof that a message is fraudulent:

Illustrative scenario: an attacker replies inside a genuine supplier thread and says the next invoice must go to a new account. The email contains no attachment and the sender address is legitimate. The red flag is the changed payment destination, so the existing vendor record — not the email thread — must determine how to verify it.

Practice scenario

Practice: a vendor payment-change request

A vendor emails asking you to change where future payments go. What should you do first?

Choose the safest first step:

Anonymous exercise: it does not ask for or store personal or financial data.

The pause-and-verify workflow

Put this workflow in your AP, HR, payroll, and executive-assistant procedures. It should apply even when the request appears to come from the most senior person in the organization.

  1. Pause the payment or reply. Do not click a link, send money, disclose data, or confirm that a requested change is complete.
  2. Inspect the actual sender and Reply-To. Expand the address and compare the domain character by character. Do not rely on the display name, signature, or a familiar thread.
  3. Reject urgency and secrecy overrides. A deadline, executive pressure, or instruction to avoid a colleague does not cancel your verification policy.
  4. Call a known-good number. Use the vendor record, signed contract, internal directory, or bank statement. Never use a number in the suspicious message. Ask the known contact whether the request and destination are genuine.
  5. Use a second approver. The second person should independently check the record and callback, not simply approve the first person's summary.
  6. Document the verification. Record who confirmed it, which trusted source supplied the number, when the callback occurred, and what was confirmed before releasing funds.

Employee-facing script: “I pause all payment and data-change requests so we can verify them through our standard process. I will call the number in our directory or vendor record, then have a second approver review it. If this is legitimate, that process protects both of us.”

For a printable set of scenarios and controls, use the free BEC Defense Playbook. The Wire Fraud Defense Playbook adds a payment-focused callback protocol.

Facilitated tabletop exercise

Tabletop: verify an urgent supplier payment change

Facilitator setup: Set aside 10 minutes. Name the AP/finance owner, a backup, and the escalation contact. Identify where the trusted vendor record or signed contract is kept, without sharing payment details. Keep this discussion hypothetical: no real vendor is contacted.

Prompt

A familiar supplier emails an urgent request to change its payment details before the next invoice is due. The message looks like a reply in a normal thread. What does the team do before any change or payment can proceed?

Discuss

  1. Who puts the change and any related payment on hold, and how does the backup take over if the AP/finance owner is unavailable?
  2. How would the owner independently verify the request by calling a number from the existing trusted vendor record or signed contract, while a second person checks that source and the result independently?
  3. What should be documented without recording sensitive payment details, and who should receive an escalation if the trusted contact details are missing or the request cannot be verified?

Debrief

Debrief: Keep the payment change on hold. In a real process, use a number already on file in the trusted vendor record or signed contract, and require a second person to verify independently. Record the trusted source, time, outcome, and approvers without copying sensitive payment details. If the contact information or request cannot be verified, keep the hold in place and escalate to the named contact.

Safety boundary: This is a discussion only. Do not contact a real vendor, change a vendor record, prepare or release a payment, or use details from the suspicious message.

Printable worksheet

Payment-change verification record

Complete this record before acting on a requested payment, payroll, or beneficiary change.

Safety note: Do not record account numbers, routing details, credentials, Social Security numbers, or other sensitive financial details here.

Independent review

Evidence saved:

Final decision

Guidance: Pause the change, verify through a known-good channel, use two-person approval for significant transactions, and document the verification.

Defenses by owner and timing

Accounts Payable and vendor owners: before the request

Use the SecurEveryone domain scanner to review your public SPF, DMARC, DKIM, DNSSEC, and MX posture, but do not mistake a good domain score for proof that an individual payment request is safe.

IT and domain owners: reduce spoofing before enforcement

  1. Inventory every sender. List your email platform, marketing and CRM tools, ticketing, payroll, invoicing, applications, and relays that send as your domains.
  2. Publish SPF and DKIM. SPF identifies authorized sending services; DKIM lets receivers verify a cryptographic signature. Follow the standards in RFC 7208 and RFC 6376.
  3. Start DMARC reporting. Publish DMARC with p=none and an aggregate-report destination so you can identify legitimate senders and failures. The DMARC standard defines reporting and policy behavior.
  4. Stage enforcement. After reviewing reports and fixing authorized senders, move deliberately toward quarantine or reject. DMARC reduces spoofing of your domain; it does not prevent every lookalike-domain, vendor-impersonation, or account-takeover attempt.

Identity and mailbox owners: protect real accounts

People leaders: practice by role

Run recurring, role-specific practice for Finance and AP (invoice and beneficiary changes), HR and payroll (direct-deposit and tax-data requests), executives (how to respond when impersonated), and operations or IT (mailbox-rule and session review). Everyone needs one reporting route and explicit permission to pause an urgent request without blame.

The Phishing Test Kit can help you rehearse realistic messages. The free cybersecurity scorecard is a useful baseline for assigning owners and tracking gaps.

Could your team catch a BEC email?

Run a real phishing test with 5 ready-to-send templates, a click-tracking sheet, and a debrief guide.

No spam. Unsubscribe anytime.

First-hour checklist for suspected or completed fraud

Speed matters, but do not destroy evidence or let pressure create a second mistake. Assign one person to keep a written timeline while others make calls.

  1. Stop further transfers and replies. Tell the bank, AP, payroll, and the affected employee to hold related activity.
  2. Contact the bank's fraud team immediately. Use the number on the bank card or official statement. Request recall or freeze assistance and ask about the bank's Financial Fraud Kill Chain process. The FBI and IC3 Financial Fraud Kill Chain guidance emphasizes rapid action; recovery is never guaranteed.
  3. Preserve the evidence. Save the original messages and full headers, payment instructions, invoices, phone numbers, attachments, screenshots, timestamps, and a record of what was sent or disclosed.
  4. Notify the incident owner. Involve the designated security or IT contact, Finance, leadership, legal, and the cyber-insurance owner according to your response plan.
  5. Contain compromised accounts from a known-clean device. Reset passwords, revoke active sessions and unfamiliar app access, review MFA methods, inspect forwarding rules and inbox rules, and remove unauthorized persistence with IT guidance.
  6. Contact applicable law enforcement, insurer, and legal owners. Preserve their instructions and claim or incident numbers in the timeline.
  7. Report internet-enabled crime. File through the FBI IC3 complaint form and retain the confirmation. Reporting does not promise recovery, but it creates a record for investigators and partners.

Do not wait for certainty about whether the message came from a spoofed domain or a compromised mailbox. Treat both as an incident until the relevant accounts, payment records, and communications have been reviewed.

A practical 30-day implementation sequence

  1. Days 1–5 — set the stop rule. Name the incident owner. Publish the pause-and-verify script. Define payment, payroll, data-release, and second-approval thresholds. Put trusted callback numbers in the vendor and employee records.
  2. Days 6–12 — close process gaps. Review vendor and beneficiary permissions, enable dual approval, document the change-of-bank SOP, and test that AP and HR know how to escalate a request.
  3. Days 13–19 — review email and identity. Inventory senders, check SPF and DKIM, begin DMARC aggregate reporting, enforce MFA on high-risk accounts, and review mailbox rules, sessions, delegated access, and connected applications.
  4. Days 20–25 — practice the roles. Run a short executive impersonation scenario with Finance, a payroll diversion scenario with HR, and a compromised reply-chain scenario with operations. Measure whether people pause, use a known-good number, involve a second approver, and document the result.
  5. Days 26–30 — make it repeatable. Fix the failed steps, publish the first-hour checklist, schedule quarterly role-specific practice, and set a monthly owner for vendor records, mailbox rules, and DMARC reports.

For live coaching on the verification workflow and scenarios, book a SecurEveryone training session or explore the broader team training program.

Sources & Further Reading

Free Assessment

Could your team spot a BEC attack before money leaves the account?

The FBI reports $137,000 average loss per BEC incident. Our free cybersecurity scorecard shows your team's current exposure in 5 minutes.

Take the Free Scorecard →