Accountability sits with the organisation that owns the workflow, not with the attacker who triggered it. Finance, procurement, and security teams should define verification steps, approval thresholds, and exception handling before incidents occur. Governance should treat external requests with the same scrutiny as internal access changes, especially when shared inboxes or executive approvals are involved.
Why This Matters for Security Teams
Fraudulent payment instructions and vendor change requests often succeed because email workflows inherit trust from business relationships, not from technical verification. That creates an accountability gap: once a request is acted on, the organisation must answer for its own control design, even if the request was malicious. Security, finance, and procurement leaders should treat these workflows as high-risk approval paths and align them to formal control expectations such as NIST SP 800-53 Rev 5 Security and Privacy Controls.
The practical issue is not whether email is “secure enough” in the abstract. It is whether the process can resist impersonation, mailbox compromise, thread hijacking, and rushed approval behaviour. Shared inboxes, delegated authority, and executive pressure often weaken validation steps that exist on paper but fail in real use. Organisations that rely on informal recognition of a sender, a familiar signature, or an ongoing email thread are effectively treating identity claims as proof. In practice, many security teams encounter the control failure only after a payment has left the bank or a vendor record has already been altered, rather than through intentional control testing.
How It Works in Practice
Accountability should be assigned to the business owner of the workflow, with supporting responsibility shared across finance, procurement, and security for the controls that govern it. That means the process owner is accountable for the decision path, while technical teams are responsible for the safeguards that make the path trustworthy. For vendor changes and payment approvals, current guidance suggests combining identity verification, approval thresholds, and out-of-band confirmation for high-risk requests, especially when the request changes bank details, payment destination, or beneficiary information.
Operationally, strong workflows usually include:
- Verification of the requester through a separate channel for any change involving money movement or supplier master data.
- Dual approval for material changes, with segregation between request, review, and execution.
- Logged exceptions for urgent requests, with post-event review and sign-off.
- Mailbox and account protections for executives, AP staff, and procurement personnel who can initiate or approve changes.
- Detection rules that flag abnormal wording, timing, reply-chain manipulation, or first-time bank detail changes.
From a control perspective, this is about proving that the organisation can distinguish legitimate authority from a forged instruction. That is where CISA guidance on avoiding social engineering and phishing attacks becomes operationally useful: it reinforces the need for independent verification rather than relying on message context alone. Teams should also map the workflow to monitoring and incident handling so that suspected fraud triggers containment, bank recall steps, and preservation of evidence. These controls tend to break down when approval paths are compressed for month-end pressure because segregation of duties collapses and exceptions become the norm.
Common Variations and Edge Cases
Tighter approval controls often increase transaction friction and can slow legitimate business, requiring organisations to balance fraud prevention against operational speed. The right answer varies by payment value, vendor criticality, and how often the workflow is used, so there is no universal standard for this yet.
In some environments, especially smaller firms, one person may legitimately initiate and approve low-value changes, but that should be a documented risk decision rather than an assumption. In others, shared service centres, outsourced accounting, or multi-entity treasury functions create additional accountability questions because the workflow spans multiple teams and systems. Email-based requests also become riskier when they are tied to identity lifecycle events, such as bank detail changes after a personnel departure or a vendor contact swap that coincides with mailbox compromise. Where the workflow touches privileged access, the intersection with identity governance becomes important: the same discipline used for access changes should apply to payment changes, even if the subject is not an account login. For deeper control mapping, teams can align with NIST Cybersecurity Framework 2.0 and OWASP guidance for application and workflow abuse patterns when automation or AI-assisted routing is involved. A process is only as accountable as the evidence trail it leaves, which is why escalation logs, callback records, and approval metadata matter as much as the final payment decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Governance and oversight apply to ownership of payment and vendor workflows. |
| NIST SP 800-53 Rev 5 | AC-5 | Separation of duties is central to preventing single-person approval abuse. |
Assign clear workflow ownership and review whether controls actually prevent fraud before incidents occur.
Related resources from NHI Mgmt Group
- Who is accountable when a payment is redirected through a fraudulent email request?
- Who is accountable when fraudulent email causes a payment or data breach?
- Who is accountable when vendor access reaches OT systems through convergence?
- Who is accountable when a customer is tricked into authorising a fraudulent payment?
