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 Office 365 / Microsoft 365 incident response process (the platform is still commonly referred to as "Office 365" even after its rebrand to Microsoft 365), informed by Microsoft's own incident response guidance and NIST SP 800-61.
Organizations evaluating outside help for this process — whether to build the plan from scratch or to have it reviewed and executed under a formal engagement — can see how IT KORR structures security assessment services and ongoing Microsoft 365 management engagements that include incident response readiness.
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 — Microsoft's guidance on device isolation and containment actions in Defender for Endpoint documents exactly what containment options exist; 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.
Where to look in Microsoft 365
Analysis is largely a question of knowing which surface answers which question.
| What you need to establish | Where to look |
|---|---|
| What did this account actually do, and when | Unified audit log search in Microsoft Purview — mailbox, SharePoint, OneDrive, Entra ID and admin activity in one record |
| How the account was accessed | Entra ID sign-in logs — source IP, location, client app, and which authentication method satisfied the sign-in |
| Whether persistence was established in the mailbox | Inbox rules and mailbox forwarding, including forwarding set on the mailbox itself rather than by a rule — a frequently used business email compromise foothold |
| Whether mail flow was altered tenant-wide | Exchange transport rules, which are tenant-level rather than mailbox-scoped and are inspected in the Exchange admin center |
| Who else received a malicious message | Message trace in the Exchange admin center, available to any Exchange Online tenant — plus Threat Explorer where Defender for Office 365 Plan 2 is licensed |
| Whether an application was granted access | Enterprise applications in Entra ID — OAuth consent grants and service principal sign-ins granting permissions no one approved |
| What data was reached | SharePoint and OneDrive file and sharing activity in the unified audit log, including anonymous link creation |
Preserve evidence before you contain
Containment changes live configuration, and live configuration is evidence. Deleting a malicious inbox rule or revoking an OAuth grant removes the object itself — the audit record that it was created survives, but the configuration you would need to show an investigator, an insurer, or a regulator does not. Export the rule, the consent grant, and the relevant sign-in and audit records before acting on them. Audit log retention is finite and varies by licensing, so the window in which the underlying records exist is not indefinite either; confirm your tenant's retention before an incident, not during one.
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 via Defender for Office 365, and block the sender domain |
| Suspicious application/OAuth grant | Revoke the application's granted permissions and consent |
Licensing determines which of these actions you can actually take
Two of the actions above depend on a license the tenant may not hold. Device isolation requires Defender for Endpoint. Purging a message across mailboxes is available through Defender for Office 365, and also through content search and purge in Microsoft Purview eDiscovery for tenants without it — worth confirming which path exists in your own tenant, because they are administered separately. Disabling an account and revoking tokens or OAuth grants need no add-on license. Establish which of these you have during preparation; discovering a containment action is unavailable mid-incident costs time you do not have. Licensing changes over time, so confirm current capability against Microsoft's incident response documentation rather than against this page.
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.
Do we need "Office 365 incident response services," or can this be handled internally? Organizations with an internal IT or security team can run this process internally once roles, containment authority, and the break-glass access path are defined — this article covers exactly that. Organizations without dedicated internal security capacity, or that want the process validated and executed under a formal engagement, typically use a managed provider's incident response and Microsoft 365 management services instead.
Related reading
- Microsoft Defender XDR
- Microsoft Defender for Office 365 — the email/collaboration detection source behind the email-campaign containment scenario above
- 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