Respond to security incidents
Every response works in one of three places, and each fix lives with the workload that owns the asset
A user clicks a phishing link, the attacker signs in with the stolen password, and a script then runs on the user's laptop. Microsoft Defender XDR (extended detection and response) correlates the related alerts into one incident that tells this attack story, and provides a framework for investigation and response: the mail, the account, and the laptop are each remediated through their owning workload, the product that holds that asset's evidence and runs its response actions (Defender for Office 365 for mail, Microsoft Entra ID Protection for cloud identity risk, and Defender for Endpoint for devices, among others). This domain's work therefore happens in three places: the incident, where you read the whole attack and manage the response through the owning workloads; the device, the owning workload with its own subtopic because Defender for Endpoint offers a device timeline, a remote shell (live response), and containment actions of its own, though the device timeline, live response, and most response actions need Plan 2; and Microsoft 365 records, the audit records, mailbox and file content, and Microsoft Graph activity logs (Graph: the API that apps use to read and change Microsoft 365 data) you search directly when the incident does not hold the evidence you need. Dismissing a user's risk in Entra ID Protection is the recorded-status trap of the third principle: it only records that the account is not at risk, while a secure password change is what remediates it. Separately, the right to manage an incident does not include each workload's own role, such as the Search and Purge role that approving an email purge needs.
The domain unfolds in three subtopics, one per place
Respond to alerts and incidents in Microsoft Defender XDR covers the incident: reading its attack story, classifying its alerts, responding inside each owning workload other than Defender for Endpoint, automatic attack disruption, embedded Security Copilot, and case management. Those owning workloads are Defender for Office 365, Entra ID Protection, Defender for Identity, Defender for Cloud Apps, Defender for Cloud, Microsoft Sentinel, and Microsoft Purview for data loss prevention and insider risk alerts (Purview Audit searches and eDiscovery searches and holds belong to the third subtopic). Automatic attack disruption contains the assets an attacker is using mid-attack (third principle). Respond to alerts and incidents in Microsoft Defender for Endpoint covers the device: the device timeline for what already happened, the investigation package for the device's current state, live response, a remote shell to read that state or act on it, entity pages for where else a file or IP address has appeared, and containment actions such as Isolate device, including the device containment that automatic attack disruption applies. Investigate Microsoft 365 activities to identify threats covers Microsoft 365 records: Microsoft Purview Audit for who did what to which item, Content search in Microsoft Purview eDiscovery for what the messages and files actually say, and Microsoft Graph activity logs for which requests an app or account sent to Microsoft Graph. The decision tree on this page asks the routing questions in order: does the task read or act on a device, does it search Microsoft 365 records directly, and is there an alert or incident to work on; a task with none of these belongs to another domain.
Before you call an asset contained, read the evidence that reports the outcome
Across all three places, one habit separates a finished response from one that only looks finished: before you call an asset contained or clean, read the evidence that reports what actually happened, not the status or verdict someone recorded. An email remediation marked Completed can include failures, a quiet stretch in a device timeline can be a gap in what the device logged, and an empty audit search can mean the records are not yet searchable or sit outside your access. Automatic attack disruption shows the same gap between recorded status and real outcome from the containment side: a contained asset is not yet a clean one. It contains the assets an attacker is using while the attack is still running, but it leaves investigating, remediating, and bringing assets back online to the security operations center (SOC), so release a contained asset only after you have investigated it.
The three places a response works and the subtopic that covers each
| Place | Question it answers | Evidence you read | Actions you take | Drill into |
|---|---|---|---|---|
| Incident | What is the whole attack, and which owning workload fixes each part? | Correlated alerts, the attack story, Security Copilot summaries | Remediation in each owning workload other than Defender for Endpoint (device actions: Device row), alert classification, case management tasks | Respond to alerts and incidents in Microsoft Defender XDR |
| Device | What happened on this device, what is its state now, and how do I contain it? | Device timeline, investigation package, live response output, entity pages | Live response, Isolate device and the other containment actions, Stop and quarantine | Respond to alerts and incidents in Microsoft Defender for Endpoint |
| Microsoft 365 records | What did an account do, what do the items say, and which Graph requests were sent? | Audit records, items found by Content search, Graph activity log rows | Searches retrieve evidence; an eDiscovery hold preserves content against deletion | Investigate Microsoft 365 activities to identify threats |