Who should own response when an email thread appears to be a fabricated business relationship?

Why This Matters for Security Teams

A fabricated business relationship is not just a phishing problem. It is a control failure across identity, finance, and operational approval paths, because the attacker is trying to create a false sense of legitimacy around a request that can move money, expose data, or redirect work. Security teams often focus on sender spoofing alone, but the real issue is whether the relationship can be independently verified and whether the transaction should be paused until that happens. Guidance in the NIST Cybersecurity Framework 2.0 still applies here: detect, respond, and contain before trust is extended. NHIMG research on the DeepSeek breach also shows how quickly exposed identity material can be turned into operational abuse, which matters when attackers build convincing but false business narratives. In practice, many security teams encounter the fabricated relationship only after a payment instruction or vendor onboarding request has already been treated as routine.

How It Works in Practice

The right response model is coordinated ownership. Finance owns the transaction, operations owns the business context, and security owns provenance checks on the message, domain, and identity signals. No single team can close the loop alone, because the attacker is exploiting both trust in communication and trust in authority. Current guidance suggests treating the thread as unverified until an independent channel confirms the counterpart and the request itself. A practical workflow usually includes:

• Freeze the request before approval, payment, or data sharing.
• Validate the purported business relationship through a known phone number, supplier portal, or previously established contact path.
• Check domain provenance, reply-chain anomalies, and lookalike infrastructure.
• Review whether the sender account, mailbox, or vendor record was recently changed.
• Require dual approval for any exception to the verification step.

The goal is to stop social engineering from becoming business process fraud. NHIMG’s State of Secrets in AppSec research is relevant here because it shows how often security assumptions diverge from actual hygiene, and that gap is exactly what attackers exploit when they impersonate a trusted partner. On the defensive side, NIST Cybersecurity Framework 2.0 supports this kind of cross-functional response by tying identification, protection, detection, and response into one operating model. These controls tend to break down when vendor onboarding is fragmented across email, ERP, and shared inboxes because no single owner can verify the relationship end to end.

Common Variations and Edge Cases

Tighter verification often increases approval time, so organisations have to balance fraud resistance against operational speed. That tradeoff is real, especially where procurement teams, executive assistants, and finance functions routinely approve time-sensitive requests. Best practice is evolving, but there is no universal standard for this yet on exactly when a thread is “sufficiently verified”; the safe default is to require an independent callback or portal confirmation whenever money, credentials, or contract changes are involved. Edge cases matter. A genuine partner can still appear suspicious if a mailbox is newly migrated, a domain has changed, or a legal entity has restructured. Conversely, a polished thread can still be malicious if the attacker compromised a real mailbox or inserted themselves into an existing vendor conversation. That is why ownership should stay shared: operations validates business legitimacy, finance validates payment authority, and security validates communication integrity. Where teams fail most often is not in detection but in escalation. If the request is routed to a single inbox, an individual may feel pressure to “just confirm” and move forward. In those environments, the control should be a mandatory stop point, not an advisory step. When the channel, the counterpart, and the authority cannot all be independently proven, the thread should be treated as untrusted until the business owner and security both clear it.

Related resources from NHI Mgmt Group

• Who should own response when identity abuse is accelerated by AI?
• Who should own response when a non-human identity starts behaving unusually?
• Who should own controls for vendor email compromise?
• Who should own coverage for email, identity, and collaboration abuse?