3.1.1. Incident Triage and Case Management
💡 First Principle: Triage is a sorting problem under time pressure: work the incidents most likely to cause damage first, make ownership unambiguous, and make the state of every incident visible. The incident queue handles the sorting; cases handle the coordination when work spans several incidents or isn't tied to an incident at all.
The incident queue in the Defender portal lists incidents from Defender XDR and Sentinel together. Triage starts with filters (severity, status, service or detection source, tags, assigned to, data sensitivity, device group) and sorting by severity and last activity. Opening an incident shows its attack story, alerts, assets (devices, users, mailboxes, apps, cloud resources), investigations, and evidence and response. Triage actions then establish control: assign an owner, set status (Active, In progress, Resolved), adjust severity, add tags and comments, and finally resolve with a classification and determination (1.2.2). When correlation missed a connection, you can link alerts to another incident or merge related incidents so the investigation has one home.
Case management adds a coordination layer above incidents, available in the Defender portal when a Sentinel workspace is connected. A case can group multiple incidents (for example, a campaign hitting several business units), or track work that isn't an incident at all, such as a threat hunt, a set of indicators being monitored, or detection logic that needs tuning.
| Incident | Case | |
|---|---|---|
| Created by | Correlation engine (or manually) | An analyst, from scratch or from an incident |
| Contains | Alerts, entities, evidence | Linked incidents, linked indicators, tasks, comments, attachments |
| Ownership | Assigned user or group | One assignee, a priority (Very low to Critical), a due date |
| Workflow | Active, In progress, Resolved | New, Open, Closed by default; admins can add custom statuses |
| Best for | Responding to one attack | Escalations spanning incidents, hunts, IoC tracking, long-running work |
Each case carries tasks (with owners, due dates, and statuses such as In progress, Failed, Skipped, Completed), rich-text comments with attachments that are scanned for malware, and an automatic activity log. Permissions map to existing roles: viewing cases needs Sentinel Reader (or the unified RBAC security data basics read permission), creating and managing cases needs Sentinel Responder (or alerts manage), and customizing case statuses needs Sentinel Contributor.
⚠️ Exam Trap: "Coordinate a response across five related incidents, with assigned tasks and due dates, without a third-party ticketing tool" is case management, not merging all five incidents (which loses their separate context and ownership) and not incident tags alone (which don't track tasks).
Reflection Question: When should you merge two incidents, and when should you leave them separate and link them to one case instead? Give one example of each.
