Security teams should own detection, message controls, and identity assurance, while finance teams should own payment verification, vendor callback checks, and approval discipline. BEC is a cross-functional control problem, so unclear ownership creates gaps that attackers can exploit during busy periods.
How Security and Finance Should Split BEC Prevention Duties
BEC prevention works best when the two teams own different failure modes. Security should harden the email and identity attack surface, then finance should slow down the payment path and verify that a request is real before money moves. The goal is not shared responsibility in the abstract, but a clean division of controls that leaves no single weak approval step for attackers to exploit.
The practical rule is that security prevents spoofing, takeover, and abnormal access, while finance prevents fraudulent disbursement even if the message looks legitimate. That split matters because BEC is usually won through process confusion, not a single technical control failure. If either team assumes the other is “covering it,” gaps appear during urgent requests, vendor changes, or end-of-month payment pressure.
A good division of labour also needs explicit handoff points. Security can detect suspicious sender infrastructure, enforce mailbox protections, and protect accounts and payment-request channels, while finance can require callback validation, out-of-band approval, and vendor master-data checks before release. Shared ownership should exist only for escalation paths and exception handling, not for vague joint accountability.
Where Security Ownership Starts and Stops
Security should own the controls that keep malicious messages from looking trustworthy and keep accounts from being used as a fraud platform. That includes email authentication, sender-reputation controls, mailbox compromise detection, MFA coverage, and alerting on risky forwarding rules or unusual login patterns. A useful reference point is Email Identity and BEC Guide, which ties email impersonation defenses to payment verification and mailbox takeover risk.
Security should also own monitoring and response thresholds. If a mailbox is compromised, if a vendor-domain lookalike appears, or if a user receives a request that bypasses normal channels, security needs to flag it quickly and preserve evidence. That is not finance’s job. Finance can reject a payment, but it usually cannot determine whether the message came from a spoofed domain, a hijacked mailbox, or a valid sender using a stolen session.
Security’s responsibility ends where business approval logic begins. Security should not be the final approver of every invoice, change in beneficiary, or urgent wire. It should define the technical and procedural guardrails that make fraudulent requests easier to spot, then provide finance with the signals needed to stop them.
Where Finance Ownership Starts and Stops
Finance should own the last-mile verification of payment legitimacy. That means callback checks to a known-good contact, dual approval for sensitive payments, vendor bank-account change validation, and a rule that urgent instructions still follow the same verification standard as routine ones. A payment request that reaches finance should be treated as untrusted until it has been independently confirmed.
Finance also owns approval discipline. The strongest technical controls will still fail if staff bypass documented checks because a request is marked “confidential,” “CEO urgent,” or “end of quarter.” Finance teams need clear authority to delay payments when verification is incomplete, even when that creates business friction. That authority must be explicit, or employees will treat exceptions as harmless shortcuts.
Finance’s line should stop short of email hardening or identity telemetry tuning. Teams do not need to diagnose authentication headers or mailbox rules to do effective payment verification. They do need a verified process for when to escalate to security, what evidence to request, and when to halt processing pending review.
How to Prevent Ownership Gaps in BEC Workflows
The biggest failure is assuming one team can compensate for the other after the fact. A payment can still be fraudulent even if the email passed through a clean channel, and a convincing email can still be benign if finance verifies it out of band. The control design needs two independent checks, one before trust is granted to the message and one before trust is granted to the payment.
Operationally, this works best when responsibility is written into specific steps. Security owns suspicious-message escalation, account compromise triage, and domain or mailbox controls. Finance owns payment release, vendor-change validation, and exception approval. If a request touches both domains, the escalation path should be predefined, with clear stop conditions and a named decision owner for each step.
For organisations with high payment volume, callback controls and dual approval need extra discipline. Busy periods increase the chance that staff will accept a familiar-looking request without rechecking the vendor channel. FIRST incident response standards are useful here because they reinforce clear coordination, evidence handling, and escalation discipline when a suspected fraud request needs security and business response together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | BEC often follows account compromise and mailbox abuse. |
| Recommendation — Enforce strong account lifecycle controls and alert on anomalous access before fraud requests are trusted. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Finance and security rely on trusted user authentication before approvals are accepted. |
| AU-6 — Audit Record Review, Analysis, and Reporting | BEC prevention depends on reviewing suspicious mail and payment activity. | |
| Recommendation — Require strong user authentication for systems that approve or release payments. Review authentication and payment audit records for signs of impersonation or compromise. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions and Authorizations Managed | Clear ownership of approval rights and payment authority is central to BEC prevention. |
| DE.CM-09 — Network and Communication Monitoring | Detecting suspicious email and account behaviour supports BEC detection. | |
| Recommendation — Define and enforce who can approve, change, and release payments. Monitor communication channels for spoofing, takeover, and anomalous sender behavior. | ||
Practitioner Guidance
What to prioritise: Define one owner for message trust controls and one owner for payment trust controls, then document the exact handoff between them. If the workflow does not say who can stop a payment, the control is not complete.
What to verify: Finance should be able to prove every high-risk payment had an independent callback or equivalent out-of-band check, and security should be able to prove that alerting exists for takeover patterns that precede BEC. Those two evidentiary trails should meet at the same incident record.
Common mistake: Treating BEC as either an email-security problem or a finance-process problem. It is neither alone. The safest model is layered accountability, with each team controlling the part of the workflow it can actually validate.
Practitioner takeaway: If a control depends on “someone else would have noticed,” it is probably not a control. BEC prevention is strongest when technical trust is owned by security and business trust is owned by finance, with no ambiguous middle ground.