Business email compromise (BEC) is a scam in which a criminal impersonates a trusted sender, a partner, a vendor, or a client, to trick staff into wiring money, changing bank details, or sending sensitive tax data. Business email compromise prevention for tax firms means combining email authentication standards, mandatory phone verification for any money or data request, and staff training that treats urgency as a warning sign rather than a reason to move fast.
Filing season raises the stakes for this scam. High email volume, tight deadlines, and routine requests involving Social Security numbers, W-2s, and client refunds give attackers exactly the cover they look for.
Quick Answer
Business email compromise prevention for tax firms combines three layers: email authentication (SPF, DKIM, and DMARC) to block spoofed senders, multi-factor authentication on every email account, and a mandatory phone-verification step before anyone changes bank details, wires funds, or sends W-2s or client tax data. Add regular staff training on impersonation tactics and a written incident response plan so your team knows what to do if a request looks off. No single control stops every attempt, but layering these reduces both the odds of a successful scam and the damage if one gets through.
Attackers research a firm before they strike. They review public staff directories, LinkedIn profiles, and past data leaks to learn who handles wires, who signs off on client refunds, and when filing season gets busiest. Three scenarios show up repeatedly in BEC attempts against tax firms:
- Spoofed partner or client emails that ask a bookkeeper to change a vendor's bank routing number right before a payment run.
- Fake requests for W-2s or Social Security numbers, often timed to the first weeks of filing season when staff are moving fast.
- Compromised vendor accounts, where a real vendor's email is taken over and the attacker sends an "updated invoice" with new payment details from an account staff already trust.
These scams succeed by exploiting trust and urgency, not just technical weaknesses. A firm without a verification habit will act on a convincing email even when the underlying account was never actually hacked, only spoofed or altered to look familiar.
BEC Prevention Checklist for Tax Firms
- Enable SPF, DKIM, and DMARC on your firm's email domain to block spoofed sender addresses
- Require multi-factor authentication on every email account, including shared and admin mailboxes
- Set a hard rule: no bank detail changes or wire transfers without a verbal callback to a known phone number
- Train staff to check the actual sender address, not just the display name, before acting on financial or data requests
- Document your BEC response steps in your written information security program (WISP)
- Run periodic phishing simulations focused on invoice fraud and impersonation scenarios
Steps to Harden Your Firm's Email Against BEC
Lock down email authentication
Configure SPF, DKIM, and DMARC, three standards that let a receiving mail server verify your domain actually sent a message and reject forged ones, so spoofed emails claiming to be from your firm get blocked before they reach a client's inbox.
Turn on MFA everywhere
Require multi-factor authentication on every account tied to your email platform, including mobile access, shared mailboxes, and connected apps, so a stolen password alone can't grant an attacker access.
Build a verification habit
Require a phone call to a known, previously verified number before honoring any request to change payment details, wire funds, or release tax documents. Never call a number provided in the suspicious email itself.
Train and test staff regularly
Run scheduled phishing simulations and short refreshers so staff recognize urgency, authority, and secrecy as red flags rather than normal business pressure.
Prepare an incident response plan
Document who to notify, how to attempt to freeze a pending transfer, and when to involve your bank and law enforcement if a BEC attempt succeeds.
BEC prevention overlaps directly with compliance obligations many tax firms already carry. The FTC Safeguards Rule, which applies to tax preparers as "financial institutions" under the Gramm-Leach-Bliley Act, requires a written information security program (WISP) covering access controls and staff training, both core BEC defenses. Our FTC Safeguards Rule checklist walks through what that program needs to cover.
IRS Publication 4557 identifies email-based social engineering as a risk tax professionals should document and mitigate. If your firm hasn't documented its email security controls yet, our WISP guidance covers what the IRS and FTC expect to see, our two-factor authentication guide for tax firms covers MFA setup, and our incident response plan guide covers what to do if a BEC attempt gets through. This is a compliance documentation question, not a legal one. Confirm specific obligations for your firm with your compliance advisor or counsel.
Verify Before You Wire or Change Bank Details
If an email asks you to change a vendor's bank details, redirect a client refund, or wire funds on a tight deadline, treat it as a possible BEC attempt until you verify it by phone using a number you already had on file, not one provided in the email. According to the FBI's Internet Crime Complaint Center (IC3) 2023 annual report, business email compromise scams caused $2.9 billion in reported losses that year, making it one of the costliest categories of cybercrime the agency tracks.
Book a Free Tax Cybersecurity Assessment
Get a plain-language review of your firm's email authentication, MFA setup, and WISP documentation before the next filing season.
Frequently Asked Questions
Business email compromise is a scam where criminals spoof or take over an email account to impersonate someone a firm trusts, a partner, client, or vendor, in order to redirect payments or extract sensitive data. It typically relies on social engineering rather than malware, which is why email authentication alone doesn't fully stop it.
Call the requester at a phone number you already have on file, not one listed in the email, and confirm the change verbally before acting. Legitimate vendors and clients generally won't object to a quick verification call, especially for a bank detail change.
The FTC Safeguards Rule requires a written information security program covering access controls, staff training, and incident response, which overlaps with core BEC defenses like MFA and verification procedures. The rule doesn't name "BEC" specifically, so confirm how your documented controls map to the rule's requirements with your compliance advisor.
Contact your bank immediately to attempt to recall or freeze the transfer, report the incident to the FBI's IC3, and follow your firm's written incident response plan to notify affected clients if their data was involved. Banks generally have a narrow window to reverse fraudulent wires, so speed matters.
From requirement to defensible practice
Turn IRS and FTC expectations into a WISP your office can follow
A useful compliance path makes the obligation clear, identifies the evidence to retain, and connects written policy to the safeguards used every day.
People also look for
Keep exploring Tax security & WISP
Understand what tax professionals need to document, protect, and prepare before an IRS or FTC review.
- Common question: free WISP templateStart with a written information security planUse a practical WISP framework built around the safeguards tax practices need.
- Common question: IRS Publication 4557 requirementsRead the Publication 4557 guideSee how the IRS expects tax professionals to safeguard taxpayer data.
- Common question: IRS WISP requirementsReview the WISP requirementsWork through the required sections and the evidence your practice should retain.
- Common question: FTC Safeguards Rule checklistUse the FTC Safeguards checklistTranslate the rule into a clear list of security and documentation tasks.
- Common question: tax practice incident response planPrepare a tax-office incident planKnow who to contact, what to preserve, and how to respond to a client-data incident.
