The Cyber Academy take
BEC is the targeted social-engineering attack that impersonates an executive or supplier to redirect a payment or trick an employee into approving one. No malware required; pure pretexting. Average loss per incident dwarfs ransomware. Process controls (segregation of duties, callback verification) catch it; technology alone does not.
What makes BEC different from ordinary phishing
Business Email Compromise is fraud carried by pretexting rather than payloads. The attacker does not need a malicious link or an attachment that drops malware. They need a plausible story, a sense of urgency and a victim with the authority to move money or data. A spoofed or look-alike domain, a compromised mailbox, or a freshly registered address that resembles a known supplier is enough to set the scene. Because nothing technically malicious crosses the wire, secure email gateways, antivirus and link sandboxes frequently let the message through. The attack lives entirely in the conversation.
That is why BEC sits next to phishing in the same family yet behaves differently in practice. Generic phishing is a wide net cast for credentials or clicks. BEC is patient and targeted: the attacker researches the org chart, learns who approves invoices, studies the tone of internal email, and waits for a believable moment such as an acquisition, a property deal or a CFO travelling abroad. The payoff is a single fraudulent wire transfer or a redirected payroll deposit, often for a large amount, rather than a harvested password.
The common variants practitioners see
BEC is a category, not a single trick. The same pretexting logic is reused against whichever process moves value inside the organisation.
- CEO fraud: an attacker impersonates a senior executive and pressures a finance employee to push through an urgent, confidential transfer, leaning on hierarchy and discretion to discourage questions.
- Supplier or vendor fraud, also called invoice redirection: a trusted supplier appears to email new bank details, so the next legitimate invoice gets paid into the attacker account.
- Payroll diversion: an employee seems to request a change of salary destination account, quietly rerouting their own pay to the fraudster.
- Account takeover: a real internal mailbox is compromised, so the fraudulent request arrives from a genuine address with genuine history, which removes most of the usual warning signs.
- Attorney or legal impersonation: the pretext leans on a confidential, time-sensitive deal where secrecy is expected and verification feels rude.
Why process beats technology here
Email authentication helps. SPF, DKIM and DMARC raise the cost of outright domain spoofing and should be deployed. But they do nothing against a look-alike domain, a free webmail address or a genuinely compromised internal mailbox, which are the channels real BEC uses most. The decisive controls are procedural, owned by finance and operations rather than by the security tooling.
- Segregation of duties so that no single person can both request and release a payment.
- Out-of-band callback verification: confirm any new or changed bank details, and any unusual transfer, using a phone number already on file, never a number or contact supplied inside the request itself.
- A hard rule that urgency and confidentiality never bypass the standard approval path; those two emotions are the attacker tools.
- Dual authorisation thresholds for wire transfers and supplier banking changes.
Where BEC fits in the regulatory picture
BEC is a primary cause of financial loss tied to email, which puts it squarely inside the scope an information security management system is meant to address. Under an ISO 27001 ISMS the relevant treatment is a mix of awareness training, supplier relationship controls and the operational procedures that govern payments. When BEC succeeds and personal data is exposed, for example through a compromised mailbox full of correspondence, it can also trigger personal data breach obligations under the GDPR, which is why the response plan must involve legal and the data protection function, not only finance and IT.
For practitioners, the takeaway is that BEC defence is a shared responsibility. Security owns email authentication, monitoring and awareness. Finance owns the payment controls that actually stop the fraud. Treating it as a purely technical problem to be solved by a better gateway is the mistake that keeps the losses flowing.
Frequently asked questions
01How is BEC different from phishing?
BEC is a targeted subtype of phishing focused on pretexting rather than payloads. Generic phishing casts a wide net for credentials or clicks, while BEC researches a specific organisation and impersonates a known executive or supplier to redirect a payment. BEC usually carries no malicious link or attachment, so technical filters often miss it.
02Why do email security gateways miss BEC?
Because there is frequently nothing technically malicious to detect. A look-alike domain, a free webmail account or a genuinely compromised internal mailbox can send a clean message with no link or attachment. Authentication like DMARC stops spoofing but not these channels, so the decisive controls are procedural.
03What single control stops most BEC fraud?
Out-of-band callback verification. Before paying a new or changed bank account, or actioning any unusual transfer, confirm the instruction by phone using a number already on file, never a contact detail supplied inside the request itself.
04Is BEC a notifiable data breach?
It can be. If a compromised mailbox exposes personal data, BEC can trigger personal data breach obligations under the GDPR. The response plan should involve legal and the data protection function alongside finance and IT.
05Does MFA prevent BEC?
MFA, ideally phishing-resistant MFA, helps prevent the account takeover variant where a real mailbox is hijacked. It does nothing against look-alike domains or external impersonation, so it must be paired with payment process controls.