Who is accountable when a BEC request is sent through a trusted business workflow?

Why This Matters for Security Teams

A business email compromise request is most dangerous when it arrives inside a process that already looks normal. If a supplier bank account update, invoice reroute, or contract change can move forward because the message came through an approved channel, the control failure is usually not technical. It is a governance failure across approval design, identity assurance, and segregation of duties. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that organisations must design controls around authorisation, review, and accountability, not only perimeter filtering.

The practical question is who can stop the action when the request appears legitimate. That responsibility sits with the owner of the business process, the approver, and the control function that defined the workflow, not with the email system alone. If the workflow allows a single thread to trigger value movement, then an attacker only needs to imitate the internal process, not break it.

In practice, many security teams encounter this failure only after money has moved or supplier details have already been changed, rather than through intentional control testing.

How It Works in Practice

Accountability for BEC through a trusted workflow should be mapped to the business control owner who has authority over the transaction, the risk acceptance owner who approved the process design, and the operational teams that execute validation. That usually means finance owns payment release, procurement owns supplier master changes, and legal or contract owners own agreement changes. Security supports the design, but should not be the only line of defence.

The workflow needs controls that verify the request outside the channel used to submit it. Best practice is to require an independent callback, a second approver using a known-good identity, or a separate system of record check before any sensitive action is completed. Where the environment supports it, organisations should also apply step-up verification for unusual changes, logging for non-repudiation, and exception handling for urgent requests. NIST’s guidance on access control and auditability is useful here, especially where CISA’s business email compromise guidance highlights the need for out-of-band validation and transaction-level review.

• Define a named owner for each payment, vendor, and contract approval path.
• Separate request submission, validation, and execution across different roles.
• Validate changed bank details or payment destinations through an independent channel.
• Record approval evidence in a system that cannot be altered by the requester.
• Treat urgent exceptions as higher risk, not as automatic approvals.

This is where identity matters beyond email. If the workflow relies on shared inboxes, delegated access, or weak approver identity proofing, then the organisation cannot reliably prove who accepted the change. That is why strong identity governance, privileged access review, and transaction controls must work together. These controls tend to break down when approvals are embedded in chat, ticketing, or ERP shortcut paths because the validation step becomes informal and no single owner is forced to challenge the request.

Common Variations and Edge Cases

Tighter approval controls often increase friction and slow down legitimate business activity, requiring organisations to balance fraud resistance against operational speed. That tradeoff becomes sharper for high-volume procurement, shared service centres, and multinational finance operations where local practices differ. Current guidance suggests the answer should be risk-based rather than universal, because not every workflow needs the same level of step-up validation.

One edge case is when a trusted workflow is executed by an automation agent or an integrated business application rather than a person. In that situation, accountability still sits with the process owner and the organisation that authorised the automation, but the control design must also account for non-human identity governance, secret handling, and permissions scope. Another edge case is when the request is technically authentic but socially manipulated, such as a real executive using a compromised mailbox or a legitimate supplier whose account has been taken over. The same validation rule should apply: trust the identity layer only as far as it has been independently assured.

There is no universal standard for this yet across every workflow platform, but the common principle is consistent: the party that defined the approval path must be able to show it required independent validation before value changed hands. NIST business email compromise resources and NIST’s BEC guidance both point to the same operational lesson: process trust should never replace transaction trust.

Related resources from NHI Mgmt Group

• Who is accountable when a fraudulent request is approved through a trusted channel?
• Who is accountable when a BEC attack succeeds through a trusted mailbox?
• Who is accountable when a digitally signed transaction is automated through workflow tooling?
• Who is accountable when a small business breach spreads through weak access controls?