Who is accountable when fraudulent email causes a payment or data breach?

Why This Matters for Security Teams

Fraudulent email is not just a phishing problem. When it results in a payment or data breach, the failure usually spans message authentication, identity assurance, workflow controls, and human approval paths. That makes accountability a governance issue as much as a technical one. Security teams are often asked to explain why protections did not stop the message, while business owners are asked why the process allowed action without stronger verification.

Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates preventive, detective, and procedural controls instead of treating email security as a single boundary. That matters when a fraudulent message passes SPF, DKIM, or even user scrutiny, yet still succeeds because approvals were not independently verified. In practice, accountability also depends on whether the organisation had enforced least privilege, strong authentication, and clear escalation paths for payment exceptions.

Security leaders should treat the incident as a control failure review, not a blame exercise. The question is whether the organisation had layered defences, trained staff, and a documented approval chain that could resist impersonation. In practice, many security teams encounter accountability disputes only after funds have moved or records have been exposed, rather than through intentional control testing.

How It Works in Practice

Accountability for fraudulent email is usually shared, but the owner of each control domain should be explicit before an incident happens. Messaging security teams typically own domain authentication, mailbox filtering, and anti-impersonation controls. IAM or identity security teams own account lifecycle, privileged access, and verification for high-risk actions. Finance, operations, or business process owners own the approval workflow that turns a message into a payment, credential reset, or data release.

The practical model is to map each stage of the attack path to a control owner:

• Message origin and sender authenticity: domain protections, DMARC, and impersonation defenses.
• User and service account abuse: credential hygiene, MFA, privileged access review, and session monitoring.
• Approval and exception handling: dual control, callback verification, and payment release thresholds.
• Detection and response: logging, alerting, and escalation for unusual requests or account activity.

That structure aligns with broader threat intelligence from the ENISA Threat Landscape, which consistently shows that email remains a primary delivery path for impersonation, fraud, and credential theft. It also fits the emerging reality of AI-assisted impersonation: the Anthropic — first AI-orchestrated cyber espionage campaign report is a reminder that social engineering is becoming faster, more tailored, and harder to spot.

For breach response, a good practice is to document who owned the control gap, who approved the transaction, and who was responsible for monitoring and escalation. That helps separate root cause from operational blame and supports audit, legal, and insurance review. These controls tend to break down when payment or data-release workflows rely on inbox-based approval in fast-moving environments because urgency overrides verification.

Common Variations and Edge Cases

Tighter approval controls often increase friction and delay, requiring organisations to balance fraud resistance against business speed. That tradeoff is especially visible in accounts payable, executive requests, customer support, and incident response, where staff may feel pressure to act quickly on a message that appears urgent.

There is no universal standard for assigning accountability in every fraudulent email case. In some organisations, security is accountable for failed preventive controls but not for the business decision to trust the message. In others, the process owner carries the operational accountability because the transaction would not have happened without an approval step they controlled. Where regulated data is involved, privacy or compliance teams may also be implicated if the organisation lacked adequate safeguards or retention controls.

The strongest approach is to define responsibility in advance through policy, RACI, and control testing. That should include who can approve exceptions, who verifies changes to bank details or sensitive records, and who investigates impersonation attempts. For identity-adjacent workflows, such as password resets, certificate issuance, or privileged access requests, the accountability model should also cover identity verification strength and escalation triggers. NHI governance becomes relevant when automated mailers, service accounts, or agents generate messages that can influence payments or data access, because those identities must be treated as accountable actors in the workflow.

Practitioners should also distinguish between technical causality and managerial accountability. A compromised mailbox may be the technical cause, but a weak approval process may be the business cause. That distinction matters when mapping obligations to NIST control families and when reviewing whether the organisation had a defensible response plan for fraud and breach scenarios.

Related resources from NHI Mgmt Group

• Who is accountable when a sanctioned AI tool causes a data breach?
• Who is accountable when an authorised AI agent causes a breach?
• Who is accountable when a vendor breach exposes downstream client data?
• Who is accountable when a service account breach exposes customer data?