Lesson 36 — Understanding Microsoft Sentinel Incidents
The detection fired.
Now the real work begins.
An alert tells you something matched. An incident gives you the investigation context around what happened.
What you will learn
Understand the incident before beginning the investigation.
Learning objectives
- Explain the difference between an alert and an incident.
- Understand how incidents organize investigation evidence.
- Recognise alerts, entities, timelines, insights and incident properties.
- Understand how incident context changes as new evidence appears.
- Know what to inspect before making an investigation decision.
The investigation
A new High-severity incident appears in the queue.
It contains three alerts, two user accounts, an IP address and a device. The title sounds serious.
Do you immediately disable the account?
No. First understand what the incident is telling you.
Alert versus incident
| Alert | Incident |
|---|---|
| A detection or security product identified activity that matched its logic. | An investigation container that brings related security evidence and context together. |
| Describes a particular detected behaviour. | Can contain one or many alerts. |
| Contains entities and detection details. | Aggregates alerts, entities, chronology, insights and investigation activity. |
| Answers: “What detection fired?” | Helps answer: “What happened, who or what was involved, and what should we investigate?” |
Think of the incident as the case file
Incidents are living records
An incident is not a static alert report. As alerts are correlated, evidence is reviewed, entities are explored, bookmarks are added and analysts update the case, the investigation context develops.
Your job is to understand that evolving story rather than react to one field in isolation.
Why incidents matter
Without incident context, analysts can end up investigating the same attack as several disconnected alerts.
Incidents help organize the evidence so related activity can be examined as one investigation instead of a collection of unrelated notifications.
Start with the incident properties
| Property | What it tells you |
|---|---|
| Title | Why the incident was created or how correlated activity is described. |
| Severity | The current severity assigned to the incident. Important context — not the final verdict. |
| Status | Where the incident sits in the investigation workflow. |
| Owner | Who currently has responsibility for handling the incident. |
| Alerts | The detections contributing evidence to the incident. |
| Entities / assets | The users, hosts, IPs and other objects connected to the activity. |
| MITRE ATT&CK | Tactics and techniques associated with the contributing alert evidence. |
Severity is a clue, not a conclusion
A High-severity incident deserves attention, but severity alone does not prove compromise.
A Medium incident involving a privileged identity may ultimately matter more than a High incident generated by expected testing. Investigation determines the real significance.
Status tells you workflow, not truth
New, active and closed states help the SOC manage work. They do not tell you whether the activity is malicious.
An incident can be new and benign, or active and genuinely serious. Keep workflow state separate from evidence-based determination.
The incident timeline
The timeline organizes alerts and hunting bookmarks chronologically, helping the analyst reconstruct the attack story.
Selecting individual timeline items lets you drill into their details and underlying evidence.
The alerts are evidence, not the whole story
Read each alert. Identify which analytics rule or security product generated it, which entities it contains, when it happened and which ATT&CK mappings are associated with it.
Three alerts in one incident do not automatically mean three separate attacks.
Bookmarks preserve findings
Hunting bookmarks can appear alongside alerts in the incident timeline.
This lets analyst-discovered evidence become part of the incident chronology instead of remaining an isolated query result that disappears when the browser tab closes.
Entities are the people and objects in the story
| Entity | Investigation question |
|---|---|
| User account | What has this identity done before and during the incident? |
| Host / device | What activity occurred on the system and what else is connected to it? |
| IP address | Where else has this source appeared and what activity is associated with it? |
| URL / domain | Which users or devices interacted with it? |
| File / hash | Where was it observed and what activity surrounded it? |
| Azure resource | What cloud activity and alerts are associated with the resource? |
Entity context goes beyond the incident
Entity information can show identifying details, timelines and behavioural insights. This helps answer whether the entity has appeared in other alerts or incidents and whether its behaviour is unusual.
The incident tells you where to start. Entity investigation helps you widen the evidence.
Entity mapping suddenly matters
Remember Module 3? Entity mapping was not just configuration work.
The entities mapped by detections become investigation pivots. Weak or missing entity mapping can reduce the context available when an analyst reaches the incident.
Top insights and similar incidents
In the Sentinel incident investigation experience, contextual insights can help analysts understand unusual entity behaviour, and similar incidents can provide broader environmental context.
An insight tells you where evidence may be interesting. A similar incident tells you where useful context may exist. Neither replaces validation against the underlying logs.
Defender portal investigation
Microsoft Sentinel in the Defender portal brings Sentinel and Defender XDR investigation data into a unified incident experience, correlating alerts, assets, investigations and evidence.
The interface differs from the Azure portal, but the analyst's job remains the same: understand the evidence, entities and chronology before deciding what happened.
Portal labels can change
Microsoft is moving Sentinel experiences toward the Defender portal, so exact tabs and controls will continue to evolve.
Learn the investigation concepts — alerts, entities, timelines, evidence and relationships — rather than memorising only where a button sits.
Your first incident read
Notice what is missing: remediation. You have not disabled anyone, isolated anything or blocked an IP yet. First you establish what you actually know.
Common mistake — trusting the title
An incident title is a starting description, not a forensic conclusion.
Read the alerts and underlying evidence before repeating the title as though it has already been proven.
Common mistake — starting with remediation
Immediate containment can be necessary when the evidence clearly justifies it, but blindly taking action because an incident exists can disrupt legitimate users and destroy investigation context.
Know what you are responding to.
Common mistake — investigating only one alert
The first alert may not explain the incident. Another alert, entity or earlier timeline event may provide the missing context.
Read the incident as a connected case.
Common mistake — ignoring the entities
The alert tells you what detection fired. The entities tell you who and what are involved.
Those entities are often where the investigation really begins.
Agent Foskett investigation exercise
Severity: High. Alerts: 3. Entities: one user, one IP address and one device. The incident spans 22 minutes.
- Do not decide whether the incident is malicious yet.
- Identify which alert occurred first.
- Record which security product or analytics rule generated each alert.
- List the entities shared between alerts.
- Review the account and IP entity context.
- Identify the ATT&CK tactics and techniques attached to the evidence.
- Look for bookmarks, insights or similar incidents that add context.
- Write three questions that must be answered before you would contain the user or device.
Best practices
- Treat the incident as a case file, not a verdict.
- Read the chronology before jumping to conclusions.
- Understand every contributing alert.
- Use entities as investigation pivots.
- Separate severity from determination.
- Use insights and similar incidents to find leads.
- Validate important conclusions against the underlying evidence.
Agent Foskett takeaway
The incident tells you where the evidence has gathered.
It does not tell you what conclusion to reach.
Read the case. Follow the entities. Build the timeline. Then decide what happened.
Related Agent Foskett learning
Continue learning
Understanding Microsoft Sentinel Incidents
Microsoft Sentinel incidents organize related security evidence into an investigation record containing alerts, entities, timelines, insights and case-management context. Analysts use this information to understand the scope and chronology of suspicious activity before making response decisions.
Microsoft Sentinel Lesson 36
This Agent Foskett Microsoft Sentinel Academy lesson begins Module 4 — Incidents and Investigation — by explaining the difference between alerts and incidents and showing how incident properties, timelines and entities form the starting point for evidence-based investigation.
