Who should own BEC controls in an organisation?

BEC controls should be owned jointly by security, finance, IAM, and business process leaders. The attack crosses technical and operational boundaries, so accountability has to cover both message security and the approval workflow itself. If only one team owns it, attackers will keep using the gap between teams.

Why This Matters for Security Teams

Business Email Compromise is not just a mailbox problem. It is a control ownership problem that spans email security, finance approval paths, identity governance, and fraud detection. If one team owns only the technical mail controls while another owns payment approvals, attackers can still exploit the handoff. NHI Management Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that control failures often start outside the inbox and then surface in business operations. See the Ultimate Guide to NHIs — Standards and the NIST Cybersecurity Framework 2.0 for the governance angle.

Ownership matters because BEC blends social engineering, identity abuse, and process manipulation. Security teams can filter messages and detect anomalies, but finance teams own payment validation, and IAM teams govern account trust and privileged access. Without clear accountability, control gaps persist between detection and action. In practice, many security teams encounter BEC only after a fraudulent payment has already been approved, rather than through intentional cross-functional control design.

How It Works in Practice

Effective BEC ownership is usually structured as a shared control model with one accountable executive and several operational owners. Security typically owns email security, domain protection, sender authentication, monitoring, and response playbooks. Finance owns payment verification steps, vendor banking change validation, and exception handling. IAM owns privileged account controls, step-up authentication, and account takeover prevention. Business process leaders own the approval workflow itself, including who can request, review, and release payments.

The practical question is not who “handles BEC” in general, but who owns each control point. A useful operating model is to map the attack path to the team best positioned to break it:

• Security blocks spoofing, phishing, and mailbox compromise.
• Finance verifies high-risk payment changes out of band.
• IAM reduces account takeover and privilege abuse.
• Process owners remove weak exceptions and informal approvals.

This is consistent with the control-first thinking in the Ultimate Guide to NHIs — Standards, because BEC frequently succeeds where identity trust and operational process trust are treated as separate problems. The NIST Cybersecurity Framework 2.0 is also useful here because it reinforces clear governance, protection, detection, response, and recovery responsibilities across functions. These controls tend to break down when payment approvals are handled through ad hoc email exceptions because there is no enforced secondary verification path.

Common Variations and Edge Cases

Tighter BEC control often increases transaction friction, requiring organisations to balance fraud reduction against speed in normal business operations. That tradeoff is real, especially in procurement, payroll, and executive support workflows where urgency is common.

There is no universal standard for BEC ownership yet, but current guidance suggests the best model is joint accountability with one named process owner per control. In smaller organisations, one team may temporarily cover multiple functions, but the control design should still separate message security from payment approval. In highly regulated environments, finance may need stronger sign-off authority, while security retains monitoring and incident response responsibility. This division matters because attackers exploit exceptions, after-hours approvals, and rushed vendor changes more than they exploit formal policies.

One practical edge case is executive impersonation: the technical control may be caught by email security, but the business control fails when staff bypass policy to satisfy a senior request. Another is invoice fraud through compromised suppliers, where IAM and vendor onboarding controls become as important as mailbox filtering. The lesson is to define ownership by the failure point, not by which team first sees the alert.

Related resources from NHI Mgmt Group

• Who should own response when credential theft crosses endpoint and identity controls?
• What is the difference between human IAM controls and NHI governance?
• When should organizations review access controls?
• Who should own fake ID controls inside an organisation?