Lesson 5 — Understanding Microsoft Sentinel Incidents
Microsoft Sentinel is designed to help analysts investigate security events efficiently.
Rather than forcing analysts to investigate hundreds of individual alerts, Sentinel groups related alerts into incidents,
providing a single investigation case that contains the evidence needed to understand what happened.
Incidents bring together alerts, entities, timelines, severity, ownership, status and investigation context from Microsoft Defender XDR,
Azure services and connected third-party data sources.
In this lesson, you will learn how Microsoft Sentinel incidents work and how analysts use them during real Security Operations Centre investigations.
What you will learn
This lesson explains how Microsoft Sentinel creates incidents and how analysts investigate them inside a modern SOC.
Learning objectives
After completing this lesson, you should understand how Microsoft Sentinel incidents support SOC investigations.
- Explain what a Microsoft Sentinel incident is.
- Understand the difference between alerts and incidents.
- Recognise how entities help analysts pivot during investigations.
- Understand incident severity, status and ownership.
- Describe how incidents support triage, investigation and response workflows.
The problem this solves
Security tools can generate many alerts. If every alert is investigated separately, analysts quickly become overwhelmed.
Sentinel incidents help group related alerts and evidence into a single case so analysts can focus on the story, not just the noise.
What is a Microsoft Sentinel incident?
A Microsoft Sentinel incident is an investigation case created from one or more alerts. It gives the analyst a structured place to review evidence, identify affected entities, assign ownership, track status and record investigation activity.
Think of an incident as the case file. Alerts are clues. Entities are the people, devices and objects involved. The analyst's job is to turn those clues into a clear investigation story.
How incidents fit into the Sentinel workflow
Incidents sit at the centre of the SOC workflow. They connect detection logic with analyst investigation and response activity.
Incident vs alert
An alert is a detection that something suspicious happened. An incident is the investigation case that groups related alerts and context together.
A single incident may contain one alert, or it may contain multiple alerts that describe different parts of the same attack.
Why grouping matters
Grouping helps analysts avoid investigating disconnected evidence one piece at a time. When related alerts are grouped together, the analyst can see a broader attack pattern.
For example, suspicious email delivery, risky sign-in activity and endpoint execution may all be part of one compromise.
Severity
Severity helps analysts understand how urgent an incident may be. Sentinel incidents may be labelled as informational, low, medium or high depending on the detection logic and source alert.
Severity should guide triage, but analysts should still validate the evidence before making decisions.
Status
Status shows where the incident sits in the investigation lifecycle. Common states include new, active and closed.
Accurate status helps the SOC understand which incidents still need attention and which have been resolved.
Owner
Assigning an owner gives accountability. In a busy SOC, ownership helps prevent two analysts duplicating work or assuming someone else is handling the case.
Ownership is especially important during high-pressure investigations where clear responsibility matters.
Entities
Entities are the users, devices, IP addresses, domains, mailboxes, applications and other objects involved in an incident. They are often the best starting point for investigation pivots.
- Which user was affected?
- Which device was involved?
- Which IP address connected?
- Which mailbox received the email?
- Which application or service principal was involved?
Real-world incident example
A user receives a phishing email and clicks a malicious link. Later, the same user signs in from an unusual location, and endpoint telemetry shows suspicious process activity.
| Signal | How it supports the incident |
|---|---|
| Suspicious email alert | Shows the likely initial access path. |
| Risky sign-in alert | Shows possible credential compromise or account misuse. |
| Endpoint process evidence | Shows what happened after user interaction. |
| Firewall or VPN logs | Adds enterprise context outside Microsoft-native telemetry. |
Comments and documentation
Good incident handling is not just about clicking through evidence. Analysts should document key findings, decisions and response actions.
Comments help future analysts understand what was checked, what was confirmed and why the incident was closed.
Common mistake
A common mistake is closing an incident too quickly because the first alert looks minor.
Always check the related entities, timeline and supporting evidence before deciding the incident is benign.
Agent Foskett investigation tip
A good analyst does not just ask, "What alert fired?" A good analyst asks, "What happened before, during and after this alert, and what does the evidence say?"
What analysts should check first
When opening a Sentinel incident, start with the investigation basics before jumping too deep.
- What is the incident title?
- What severity has been assigned?
- Which entities are involved?
- How many alerts are grouped?
- What changed over time?
- Has anyone already commented or assigned ownership?
Agent Foskett takeaway
Alerts tell you something happened.
Incidents help you investigate what it means.
A good incident is not just a notification. It is the start of a structured investigation.
Related Agent Foskett learning
Microsoft Sentinel Academy progress
Understanding Microsoft Sentinel Incidents
Microsoft Sentinel incidents group alerts, entities, severity, status, ownership and investigation evidence so SOC analysts can triage, investigate and respond to security cases efficiently.
Microsoft Sentinel Lesson 5
This Agent Foskett Microsoft Sentinel Academy lesson explains incidents, alerts, entities, severity, status, ownership, comments, evidence, timelines and SOC investigation workflows.
