Who is accountable when a phishing-led EDR incident spreads through multiple inboxes?

Accountability usually sits across endpoint operations, email security, and identity or SOC teams, because no single control layer sees the full chain. Governance should define who blocks the sender, who traces recipients, and who validates containment across platforms. That ownership needs to be explicit before the next incident arrives.

Why This Matters for Security Teams

When a phishing-led incident spreads beyond one mailbox and starts touching endpoints, shared accounts, and cloud inboxes, accountability stops being a simple ticket assignment problem. The practical question is not who spotted the first alert, but who owns containment across email security, endpoint detection and response, identity controls, and incident coordination. That matters because mailbox compromise often becomes a lateral movement path, especially when tokens, session cookies, or synced credentials are exposed.

Security teams also underestimate how quickly a single phishing event becomes a multi-system problem. Email filters may quarantine the payload, while EDR flags suspicious child processes or script execution, and identity teams see impossible travel, MFA fatigue, or sign-in anomalies. Those signals rarely arrive in one console with one owner. Guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls supports shared control responsibility, but operational ownership still has to be defined in advance.

In practice, many security teams encounter the real owner of the incident only after the inboxes, endpoints, and identity logs have already diverged into separate investigations.

How It Works in Practice

Accountability for a phishing-led EDR incident usually follows the control plane, not just the alert source. Email security is often responsible for initial suppression: blocking the sender, removing the message, detonation outcomes, and hunting for additional recipients. Endpoint operations or the EDR team usually owns host isolation, process review, malware triage, and containment validation on affected devices. Identity or IAM teams are accountable when the attack involves credential theft, token abuse, malicious consent, or suspicious sign-in patterns. SOC or incident response normally coordinates the timeline, evidence handling, escalation, and executive reporting.

A workable model is to define decision rights before an incident. That usually includes:

• who can disable a mailbox rule, block a domain, or purge messages tenant-wide;
• who can isolate an endpoint without waiting for approval;
• who checks whether authentication sessions, refresh tokens, or OAuth grants were abused;
• who confirms that the same lure did not land in additional business units or subsidiaries;
• who declares containment complete and closes the incident.

This becomes more important when the phishing campaign is multi-stage, because the initial message may only be the entry point. Public reporting on AI-enabled intrusion tradecraft, such as the Anthropic report on first AI-orchestrated cyber espionage campaign, reinforces a broader point: human and machine-assisted campaigns can scale quickly across messaging, identity, and endpoint layers. That makes cross-functional playbooks more important than any single product alert.

Best practice is evolving toward joint incident ownership, where each team owns its control layer but one coordinator owns the end-to-end case. These controls tend to break down when email, EDR, and identity tooling are administered by different vendors in separate tenants because evidence collection and containment authority become fragmented.

Common Variations and Edge Cases

Tighter containment often increases operational overhead, requiring organisations to balance rapid action against the risk of disrupting legitimate users and workflows. That tradeoff is especially visible in executive mailboxes, service accounts, and merged environments where one phishing message can touch many recipients but only one device is actually compromised.

There is no universal standard for this yet, but mature organisations usually treat accountability differently depending on the blast radius. If the issue is limited to a malicious email with no endpoint execution, email security may lead while SOC tracks scope. If the message caused macro execution, payload download, or remote access tool installation, endpoint operations and SOC take stronger ownership. If the attacker harvested credentials or approved a malicious OAuth consent, identity teams become central to containment and reset actions.

Edge cases often appear in environments with forwarded mail, shared mailboxes, delegated access, or third-party helpdesk tooling. In those cases, one alert can affect multiple inboxes without any single user being the true source of exposure. The operational answer is to map accountability to the system that can actually stop recurrence, not the system that first generated noise. That usually means a RACI, an incident commander, and a pre-agreed containment sequence rather than ad hoc escalations.

Related resources from NHI Mgmt Group

• Who is accountable when a NIS2-relevant incident spreads through legacy systems?
• Who is accountable when a small business breach spreads through weak access controls?
• Who is accountable when a supply chain compromise spreads through trusted credentials?
• Who is accountable when an MSP incident affects multiple clients?