Ownership should sit across identity, security operations, and the business functions that approve money, access, or sensitive requests. Finance and IT are especially important because attackers mirror their workflows. If those teams do not define and test escalation paths, the organisation leaves fraud decisions to the inbox.
Why This Matters for Security Teams
Internal impersonation BEC is not just a phishing problem. It is an authority problem, because the attacker is trying to look like someone already trusted inside the organisation and then push a payment, access change, or urgent exception through normal business channels. That makes ownership critical: identity and security teams can harden controls, but finance, IT, and operations own the approvals that attackers are trying to hijack. NIST’s NIST Cybersecurity Framework 2.0 reinforces that governance and response responsibilities must be explicit, not implied. NHIMG’s Ultimate Guide to NHIs — Standards makes the same operational point for identity-driven risk: controls fail when ownership is fragmented and lifecycle decisions are left to inboxes and ticket queues. For BEC, the business function that can release money or approve access must be part of the control design, testing, and escalation path, not just a downstream recipient of alerts. In practice, many security teams encounter internal impersonation only after a payment has been routed, a vendor bank detail has changed, or an emergency access request has already been acted on.
NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which matters here because internal impersonation often uses the same trust paths and delegated authority patterns.
How It Works in Practice
Ownership should be mapped to the control the attacker wants to abuse, then backed by a clear decision chain. Identity security should own the authentication and verification layer, security operations should own detection and triage, and finance or IT should own the final approval steps for payments, access changes, or high-risk exceptions. That split aligns with the way internal impersonation BEC actually unfolds: the attacker often crafts a message that fits an existing workflow, then relies on speed, ambiguity, or hierarchy to bypass scrutiny. Ultimate Guide to NHIs — Standards is useful here because it frames identity as a lifecycle problem, not a one-time authentication event. NIST’s NIST Cybersecurity Framework 2.0 supports the same model through governance, protection, detection, response, and recovery.
Practical ownership usually includes:
- Identity team: controls for MFA, mailbox protections, privileged account safeguards, and identity proofing.
- Security operations: suspicious senders, anomalous request patterns, and fast escalation of suspected internal spoofing.
- Finance leadership: dual approval, callback verification, and payee-change controls.
- IT leadership: access request verification, out-of-band confirmation, and approvals for sensitive admin changes.
- Business process owners: defining what counts as normal, urgent, or exempt so that exceptions are reviewable.
The key is that no single team owns the whole threat. Instead, each team owns the part of the process it can actually enforce, and those handoffs must be tested before an incident. These controls tend to break down when approval authority is embedded in ad hoc email threads because the attacker only needs one person to treat urgency as legitimacy.
Common Variations and Edge Cases
Tighter approval controls often increase friction, so organisations have to balance fraud resistance against operational speed, especially in finance and IT where urgent requests are common. There is no universal standard for exactly which team should be the final owner in every company, but current guidance suggests the business function that can approve the action should own the control objective, while security owns the assurance and monitoring around it. That matters for edge cases such as mergers, distributed finance teams, outsourced help desks, or shared service centres, where the same workflow may cross multiple managers and systems. In those environments, internal impersonation BEC often exploits unclear escalation rights rather than technical failure. A strong control design therefore uses named approvers, out-of-band verification for high-risk requests, and periodic tabletop testing across the exact teams that can release funds or grant access. When organisations rely on a single inbox, a generic shared mailbox, or informal “just this once” exceptions, ownership becomes diffuse and the control stops being enforceable. Current practice also suggests that finance and IT should jointly define exception thresholds, because attackers commonly blend payment fraud with account takeover to make one request look like routine administration. The hard lesson is that the right owner is the team that can stop the action, not just the team that can see the alert.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Ownership of BEC controls depends on clear governance and business objectives. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Internal impersonation often exploits identity misuse and weak verification paths. |
| NIST AI RMF | Risk governance for autonomous or assisted decision paths requires accountable ownership. |
Map who can approve sensitive actions and add stronger verification where identity trust is business-critical.
