Every detection capability covered in this cluster — Defender XDR incidents, Entra ID Protection risk alerts, Sentinel correlation — exists to feed a response process. Detection without a defined response process delivers only partial value: the alert fires, and then what happens depends entirely on whoever happens to see it first. This article covers a practical incident response process specifically shaped around a Microsoft 365 environment.
The incident response lifecycle
| Phase | Objective |
|---|---|
| Preparation | Detection tooling configured and monitored, response roles defined, before an incident occurs |
| Detection & Analysis | Confirm whether an alert represents a genuine incident and assess scope |
| Containment | Limit further damage — isolate a device, disable an account, revoke a session token |
| Eradication & Recovery | Remove the threat's foothold and restore normal operation |
| Post-Incident Review | Document what happened, what worked, and what governance gap allowed it |
Preparation: before an incident happens
Incident response quality is determined mostly by preparation, not improvisation during the incident itself.
- Confirm Defender XDR, Entra ID Protection, and any other detection capability is actually configured and monitored — see Microsoft Defender XDR — an incident response process has nothing to respond to if detection itself is silent.
- Define roles in advance: who has authority to isolate a device or disable an account, who communicates with affected users or leadership, who documents the timeline.
- Maintain the break-glass account access path described in Privileged Identity Management and Privileged Access — an incident is exactly the scenario that access path exists for.
- Pre-authorize common containment actions (disabling a compromised account, isolating a device) so the response doesn't stall waiting for approval during an active incident.
Detection and analysis
Not every alert is an incident requiring full response — the analysis phase confirms genuine compromise and assesses scope before committing to containment actions that carry their own operational cost (a false-positive device isolation disrupts a legitimate user).
Correlated incidents from Defender XDR change the analysis starting point
A Defender XDR incident (see Microsoft Defender XDR) already represents correlated signal across multiple sources — analysis should start from that correlated view rather than re-investigating each underlying alert independently, which duplicates work the platform has already done.
Containment: common Microsoft 365-specific actions
| Scenario | Containment Action |
|---|---|
| Compromised user account | Disable sign-in, revoke all active session tokens, require password reset with identity verification |
| Compromised device | Isolate the device via Defender for Endpoint, preventing network communication while preserving forensic state |
| Malicious email campaign in progress | Purge the message across all mailboxes it reached, block the sender domain |
| Suspicious application/OAuth grant | Revoke the application's granted permissions and consent |
Post-incident review
Every incident — successfully contained or not — should produce a documented review identifying root cause and specific follow-up actions, following the same postmortem discipline described in Identity Lifecycle and Joiner-Mover-Leaver Governance's treatment of incident review for operational governance generally. A review that identifies "MFA was not enforced for this account" as root cause should result in that specific gap closing, not just a documented finding.
Common mistakes
- No defined response roles, causing delay and confusion during an active incident about who has authority to take containment action.
- Treating every alert as requiring full incident response, exhausting response capacity on false positives instead of triaging based on correlated severity.
- Containing an incident without a structured post-incident review, missing the governance gap that allowed it and risking recurrence.
- Not testing the response process before a real incident, discovering gaps (an undefined escalation path, an inaccessible break-glass account) for the first time during genuine pressure.
FAQ
How is this different from the general operational incident review process? The principle (document, find root cause, close the gap) is the same one covered generally in this Knowledge Center's operational governance content — this article applies it specifically to security incidents in a Microsoft 365 environment, with the specific detection tools and containment actions available there.
Should containment actions require approval during an active incident? For pre-defined, well-understood scenarios (isolating a clearly compromised device), pre-authorization avoids response delay. For more consequential or ambiguous actions, a defined but fast approval path is more appropriate than either no oversight or a slow one.
Does Microsoft Sentinel replace the need for a defined incident response process? No — Sentinel (and Defender XDR) are detection and investigation tooling; the incident response process is the organizational discipline for what happens once something is detected, which the tooling supports but doesn't replace.
Related reading
- Microsoft Defender XDR
- Microsoft Sentinel Overview
- Privileged Identity Management and Privileged Access
- Ransomware Recovery Planning — the recovery process once containment and eradication are complete
- Download: Microsoft Security Operations Playbook