BEC risk should be owned jointly by IAM, security operations, and finance because the attack chain crosses all three. IAM controls trust, security detects anomalies, and finance controls the final transfer or exception. Shared ownership is the only realistic way to close the handoff gaps.
Why This Matters for Security Teams
BEC is not just an email problem or a finance fraud problem. It is an identity abuse problem that starts with trust in a mailbox, identity provider, or workflow and ends with a payment, vendor detail change, or exception that finance is expected to approve. That is why ownership cannot sit in a single team. IAM sees account and access anomalies, security operations sees the suspicious behavior chain, and finance sees the transfer logic and approval path. The failure mode is usually a handoff gap, not a missing control. The NIST Cybersecurity Framework 2.0 reinforces that governance and response must be coordinated, not siloed. NHIMG research on Top 10 NHI Issues also shows how identity sprawl and weak access discipline create conditions attackers exploit across business workflows. In practice, many security teams encounter BEC only after a payment has already been approved and the fraud trail is being reconstructed.
How It Works in Practice
Effective BEC ownership starts by mapping the full kill chain, not just the inbox. IAM should own identity hardening, conditional access, MFA enforcement, privileged session protections, and review of risky mailbox or supplier account changes. Security operations should own detection engineering, alert triage, and response playbooks for unusual forwarding rules, impossible travel, consent grants, and suspicious login-to-payment sequences. Finance should own payment verification, exception handling, vendor master data controls, and call-back procedures for any high-risk change request.
A workable operating model usually includes:
- joint approval for bank account changes, invoice exceptions, and urgent payment requests
- step-up verification for account takeover indicators before any finance action proceeds
- shared incident playbooks that define who freezes transfers, who resets identities, and who contacts vendors
- regular control testing that links IAM events to finance workflow outcomes
This is especially important where attackers abuse cloud email, collaboration tools, or delegated access to impersonate executives and vendors. The NIST CSF supports this kind of cross-functional control mapping, while NHIMG guidance in Ultimate Guide to NHIs — Why NHI Security Matters Now shows why identity-centric attacks increasingly cross operational boundaries. These controls tend to break down when finance systems allow manual overrides without identity telemetry because the final approval becomes detached from the original compromise signal.
Common Variations and Edge Cases
Tighter payment controls often increase friction, requiring organisations to balance fraud resistance against business speed. That tradeoff becomes more visible in shared services, high-volume AP teams, and multinational environments where approvals vary by region, currency, or subsidiary. Current guidance suggests the owner of BEC risk should be a joint governance group, but there is no universal standard for who chairs it. In smaller organisations, security may lead policy and finance may lead execution; in larger ones, risk management or internal audit may coordinate oversight.
Edge cases matter. If the attack begins with vendor email compromise, finance may spot the anomaly first. If it begins with identity takeover, IAM may be first to detect it. If it is a payroll redirection scam, HR and finance may need to be included as well. The practical answer is to define a single accountable owner for the program, then assign control owners by stage of the attack chain. NHIMG’s 2024 Non-Human Identity Security Report reports that 88.5% of organisations say non-human IAM lags human IAM, which is a reminder that weak identity governance often extends into workflow automation and approval paths. That gap becomes most dangerous when payment authority, mailbox trust, and exception handling are all controlled separately.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | BEC ownership requires clear organisational context and cross-functional governance. |
| NIST CSF 2.0 | PR.AA-01 | Identity assurance and access control are central to stopping account takeover and spoofing. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Weak secret and access handling often enables the initial compromise path behind BEC. |
Reduce credential exposure and review service account access that could be used to trigger fraud workflows.
Related resources from NHI Mgmt Group
- Who should own identity risk when governance spans IAM, PAM, and security operations?
- Who should own impersonation risk when it affects finance, help desk, and identity teams?
- How should IAM teams reduce identity sprawl across disconnected tools?
- How should IAM teams operationalise identity governance across multiple business units?
