Ownership should be shared across IAM, security operations, finance, and procurement because the attack crosses all four domains. Identity teams control assurance, SOC teams control detection, and finance teams control the transaction decision. If those groups work separately, attackers can exploit the gaps between verification and action.
Why This Matters for Security Teams
Phishing and BEC against retail payment workflows are not just email problems. They become identity, transaction, and control failures the moment a message influences who can approve, reroute, or release funds. That makes ownership broader than a single control tower. Security operations may detect the lure, IAM may validate the user, and finance may still be the team that can stop the payment. The practical risk is that each group sees only one slice of the attack path. Guidance from the NIST Cybersecurity Framework 2.0 supports shared accountability, but retail payment workflows need clearer handoffs than generic incident response models usually provide.
This is where NHI governance matters too, because attackers increasingly abuse compromised credentials, tokens, and workflow approvals rather than only stealing passwords. NHIMG research on the State of Secrets in AppSec shows how fragmented secrets management and slow remediation widen the window for abuse. In practice, many security teams discover ownership gaps only after a fraudulent payment has already moved through a legitimate approval path, rather than through intentional control testing.
How It Works in Practice
The right operating model is a shared response chain with explicit decision rights. IAM owns the assurance question: was the account, session, device, and approval context legitimate? SOC owns detection: did the message, login, or payment request match known BEC patterns? Finance owns the transaction decision: should the payment be held, called back, or escalated? Procurement may need to verify vendor-change legitimacy when bank details or remittance instructions are altered.
A workable playbook usually includes:
- Step-up verification for payment changes, vendor master edits, and first-time beneficiaries.
- Out-of-band approval for high-risk transfers, with a separate channel from the original message thread.
- Short-lived access or JIT approval rights for finance users who only need elevated permission during a payment window.
- Central logging that joins identity events, mailbox signals, and ERP or treasury actions into one timeline.
- Pre-agreed callback lists and fraud hold procedures that finance can execute without waiting for a full incident declaration.
For environment design, the control problem is not just phishing resistance but transaction integrity. NIST Cybersecurity Framework 2.0 helps structure detect-and-respond activities, while NHIMG’s LLMjacking research highlights how quickly exposed credentials can be abused once an attacker is inside the workflow. These controls tend to break down when payment approvals are embedded in email threads and no system of record exists for callback validation.
Common Variations and Edge Cases
Tighter approval controls often increase operational friction, so organisations have to balance fraud resistance against payment speed, supplier trust, and end-of-day settlement deadlines. Best practice is evolving, especially where retail teams use shared service desks, outsourced AP functions, or ERP-integrated automation.
The main edge cases are:
- Urgent supplier payments, where business pressure can override callback discipline.
- Shared inboxes or delegated approvals, where identity evidence is weaker than the business process assumes.
- Cross-border payments, where time zones and banking cutoffs slow manual verification.
- AI-assisted phishing, where message quality is high enough to bypass human suspicion and force reliance on process controls.
In these scenarios, current guidance suggests treating payment workflow compromise as a multi-team incident with finance as the final control owner for the transaction, not merely a downstream consumer of security alerts. Where organisations rely on ad hoc verbal approval or one-person exception handling, the ownership model collapses because there is no reliable boundary between verification, authorisation, and release.
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 | RS.RP-1 | Incident response ownership and playbooks fit phishing-driven payment fraud. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Compromised secrets and tokens often enable payment workflow abuse. |
| NIST AI RMF | AI-assisted phishing changes the threat context for payment approvals. |
Define who pauses, verifies, and resumes payment workflows during BEC events.
