Lesson 66 — The Incident Crossed Multiple Teams
The endpoint team had isolated two devices.
The identity team was revoking sessions.
The messaging team had found a suspicious inbox rule.
The cloud team was reviewing file access.
The network team was checking external connections.
Everyone was busy.
There was just one problem.
Everyone was working from a slightly different version of the incident.
Agent Foskett looked at the growing collection of Teams messages, tickets and screenshots.
“We don't need five investigations. We need one incident.”
One incident. Multiple teams.
Coordinate endpoint, identity, messaging, cloud, network and business responders without allowing the investigation to fragment.
Case briefing
Investigation objective
Coordinate a security incident that crosses technical and business boundaries while preserving shared scope, evidence, decision ownership and response sequencing.
Investigator's rule
Specialists can own actions. Someone must own the incident.
Stage 1 — establish one incident owner
The incident lead does not do every task
The incident lead coordinates the response, maintains the operational picture, tracks decisions and ensures that workstreams support the same incident objectives.
Ownership must be explicit
Avoid vague assumptions such as “the SOC is handling it.” Record who is leading the incident, who owns each workstream and who has authority for high-impact containment decisions.
Stage 2 — create one shared incident picture
One timeline prevents five truths
If each team keeps a separate timeline, important relationships can disappear. A mailbox change at 14:12 may explain an identity event at 14:13 and an endpoint action at 14:15.
Use source systems for evidence
The shared incident record should reference the original alerts, events, case records and artefacts. Chat messages are useful for coordination but should not become the only record of what happened.
Stage 3 — give each team a defined question
| Workstream | Question to answer |
|---|---|
| Endpoint | Which devices are compromised, and is malicious execution continuing? |
| Identity | Which identities, sessions, authentication methods or privileges are affected? |
| Messaging | Was email used for initial access, persistence, forwarding or impersonation? |
| Cloud / SaaS | Which resources, files, applications or permissions were accessed or changed? |
| Network | Which relevant connections or infrastructure indicators require action? |
| Business | Which processes, data and operational dependencies are affected? |
| Incident lead | What is the current scope, priority and next coordinated action? |
Questions are better than vague assignments
“Check Entra” is not a useful workstream objective. “Determine whether mia@contoso.com has any remaining active access paths” gives the identity team a decision-focused outcome.
Every workstream should feed the same incident
New evidence should update shared scope and priorities rather than remaining trapped inside a specialist team's notes.
Stage 4 — correlate endpoint and cloud activity
DeviceProcessEvents
| where Timestamp > ago(4h)
| where DeviceName in~ ("FIN-WS-044", "FIN-WS-061")
| project Timestamp, DeviceName, AccountName,
FileName, ProcessCommandLine,
InitiatingProcessFileName
| order by Timestamp ascEndpoint evidence answers only part of the case
The endpoint team may prove malicious execution stopped while cloud activity continues. That is not a contradiction; it means the incident crosses control planes.
Share pivots quickly
If the endpoint team identifies another account, device, IP or file relevant to scope, pass it to the appropriate workstream immediately rather than waiting for the endpoint investigation to finish.
Stage 5 — correlate cloud activity
CloudAppEvents
| where Timestamp > ago(4h)
| where AccountId =~ "mia@contoso.com"
| project Timestamp, AccountId, Application,
ActionType, IPAddress, UserAgent
| order by Timestamp ascDifferent teams may see different stopping points
Endpoint activity may stop at 14:31 while cloud activity continues until 14:46. The incident timeline must represent both before anyone claims containment.
Ask what changed after each action
Containment verification is stronger when teams compare activity before and after isolation, session revocation, rule removal, permission changes or other approved response actions.
Stage 6 — coordinate actions before they collide
Sequence can matter
Some actions alter account state, sessions, files, rules or endpoint artefacts. Coordinate preservation and containment so teams do not unintentionally remove evidence another workstream still requires.
But do not let coordination become delay
If active harm requires immediate containment, use the organisation's emergency authority and procedures. Coordination should accelerate safe action, not create a meeting while the attacker keeps moving.
Stage 7 — track dependencies
Dependencies expose hidden risk
A technically correct containment action can still create unnecessary business disruption if dependencies are unknown. Equally, business inconvenience should not silently override urgent security risk.
Record blockers and owners
If an action cannot proceed, record what is blocking it, who owns the blocker and what interim risk remains. “Waiting” is not a sufficient incident status.
Stage 8 — separate technical facts from business decisions
Business stakeholders belong in the incident
They provide asset criticality, process dependencies, data sensitivity and operational impact. They should not be expected to interpret raw security telemetry.
Translate evidence into decisions
Instead of saying “DeviceProcessEvents shows PowerShell,” explain the decision relevance: “The endpoint is still executing suspicious commands, so continued connectivity creates an immediate containment risk.”
Stage 9 — run short incident updates
Updates should answer “what changed?”
Do not reread the entire incident every time. Focus on new evidence, new scope, completed actions, blockers, risks and the next decisions required.
Cadence should match incident urgency
A fast-moving incident may need frequent coordination; a stable recovery phase may not. Follow organisational incident-management procedures rather than creating unnecessary communication overhead.
Stage 10 — define what each team must prove before containment
No team can declare the whole incident contained alone
The endpoint team can declare an endpoint contained. The identity team can confirm an identity control was applied. The incident-level conclusion requires evidence across the relevant workstreams.
Shared language matters
Use precise status terms such as “device isolated,” “sessions revoked,” “no new suspicious activity observed” and “scope review incomplete” instead of vague phrases such as “sorted” or “looks good.”
Example coordinated incident record
Lesson 66 key takeaways
- A multi-team incident still needs one incident owner.
- Specialists own workstreams; the incident lead owns the shared operational picture.
- Maintain one timeline across endpoint, identity, messaging, cloud, network and business actions.
- Give teams decision-focused questions rather than vague assignments.
- New evidence from one workstream should update every relevant workstream quickly.
- Coordinate actions because one team's remediation can change another team's evidence.
- Track dependencies, blockers, owners and remaining risk.
- Business stakeholders provide impact and operational context, not raw technical analysis.
- Incident updates should focus on what changed and what needs a decision next.
- Use precise status language rather than “fixed” or “sorted.”
- No single technical team can declare a cross-domain incident fully contained.
- One incident needs one shared version of the truth.
Module 7 — Incident Response: Containment, Evidence & Escalation
Lesson 66 coordinated the incident across multiple teams. Lesson 67 introduces the next response challenge: every new pivot reveals another user, device, application or resource, and the scope keeps growing.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 7: Incident Response: Containment, Evidence & Escalation
How do SOC teams coordinate a multi-team security incident?
Lesson 66 of the Agent Foskett SOC Analyst Academy teaches analysts how to coordinate endpoint, identity, messaging, cloud, network and business stakeholders while maintaining one shared incident timeline and operational picture.
Cross-team incident response and containment
Learn how to establish incident ownership, assign workstreams, track dependencies, coordinate containment actions, communicate business impact and reach evidence-based incident status decisions.
