L6. Incident Management: Correlation, Triage and Response
Visual workflow edition
Worked example, diagrams and a question with time to think. Synthetic American-English narration; examples are fictional. Reviewed October 2026.
Read the video transcript
A high-severity incident appears while your team is handling several other alerts. What deserves attention first? Severity is a starting signal. You still need to understand the affected assets, evidence of ongoing activity, and business impact. We'll build a concise triage record that another analyst can actually continue.
Start with the incident summary and related alerts. Identify the affected users, devices, and other entities. Separate observed facts from the platform's suggested interpretation. Check whether the activity is current and whether a sensitive asset is involved. An incident with fewer alerts may be more urgent if it threatens a critical service.
Our fictional incident begins with a suspicious sign-in, followed by a device alert. Record the relevant times and identifiers, then inspect whether the evidence supports a connection. Look for contradictions too. A maintenance window or shared device may change the interpretation. Do not hide uncertainty behind an incident title that sounds definitive.
Some actions collect information; others disrupt access or services. Confirm your permissions and follow the response process before acting. Record the intended target and reason. When urgent containment is necessary, document the decision and coordinate with the responsible owner. A tool's available button does not replace organizational authorization.
A useful handoff includes what you observed, what remains unknown, what actions were taken, and whether those actions completed. Assign an owner and a next verification step. If an automated investigation or response contributed evidence, review its scope and result. Do not assume that automation covered every affected identity or device.
An isolation request was submitted and the incident was marked resolved. No one checked the action result. Is the investigation record complete? Pause and identify the missing evidence.
No. A submitted action and a changed incident status do not establish that containment worked. Verify the action result and reassess the relevant exposure. For practice, write a short handoff with four fields: facts, uncertainty, actions, and next owner. Clear reasoning is more useful than copying every alert into a long report.
Course outlineLesson 6 of 18
Effective incident management in Defender XDR requires understanding how alerts become incidents, how to triage and classify them, and which response actions to take. This lesson covers the incident queue, investigation graph, and automated response capabilities for the SC-200 exam.
How Alerts Become Incidents
Defender XDR groups related alerts into incidents using its correlation engine. The engine considers:
- Entity mapping: Alerts sharing the same user, device, mailbox, or IP address
- Temporal correlation: Alerts occurring within a related timeframe
- Attack pattern matching: Known attack sequences mapped to MITRE ATT&CK
A single incident can contain alerts from multiple Defender products. For example, an incident might include a phishing alert (Office 365), a suspicious sign-in (Identity), malware execution (Endpoint), and data exfiltration to a cloud app (Cloud Apps).
The Incident Queue
The incident queue at security.microsoft.com > Incidents is the SOC analyst's primary workspace. Each incident shows:
- Severity: High, Medium, Low, Informational
- Status: New, In progress, Resolved
- Classification: True positive, Informational (expected), False positive
- Determination: Multi-select values like Malware, Phishing, Compromised account
- Assignment: Assigned analyst or team
- Category: MITRE ATT&CK tactic (Initial Access, Execution, etc.)
Filters let analysts focus on specific severities, statuses, categories, data sources, or assigned owners. Exam tip: The exam tests your ability to choose the correct classification and determination for a given scenario. Authorized penetration testing is classified as "Informational, expected activity" with a security-testing determination, rather than a malicious true positive.
Investigation Graph
The investigation graph visualizes the relationships between entities in an incident:
- Users, devices, mailboxes, and IP addresses involved
- Files and processes executed
- Alerts triggered and their timeline
- Related evidence and artifacts
Clicking any entity opens its detailed page with full context: activity timeline, alerts, group memberships (for users), installed software (for devices), and related incidents.
Response Actions
Incident response actions in Defender XDR span all workloads:
| Action | Scope | Effect |
|---|---|---|
| Isolate device | Endpoint | Cuts network, keeps Defender connection |
| Disable user account | Identity | Blocks sign-in across all services |
| Reset password | Identity | Forces password change |
| Confirm user compromised | Identity | Raises user risk level in Entra ID |
| Soft delete email | Office 365 | Moves email to Deleted Items |
| Hard delete email | Office 365 | Permanently removes from mailbox |
| Block URL/file | XDR-wide | Adds to custom indicator blocklist |
| Run antivirus scan | Endpoint | On-demand endpoint scan; separate from Office 365 AIR |
Automated Investigation and Response
For supported automated investigations, such as Defender for Office 365 AIR: Endpoint update: As of September 1, 2026, Microsoft documents endpoint AIR as part of the default antivirus protection stack, without a separate investigation experience or manual trigger. Use a full antivirus scan for an on-demand endpoint investigation; do not treat every incident as an XDR-wide AIR trigger.
- AIR examines all alerts and entities in the incident
- It expands the investigation to check for related suspicious activity
- It produces a list of recommended remediation actions
- Depending on the automation level, actions are applied automatically or queued for approval
The Action center at security.microsoft.com shows all pending and completed actions across the organization.
Incident Classification Workflow
A practical triage workflow for the exam:
- Review the incident summary and alert evidence
- Check the investigation graph for entity relationships
- Open entity pages to review activity timelines
- Determine if the activity is malicious, expected, or a false positive
- Set the classification, determination, and add comments
- Take supported response actions; use a full antivirus scan for on-demand endpoint investigation
- Resolve the incident when all alerts are addressed
Linking and Merging Incidents
If two incidents are related but were not automatically correlated, analysts can link them manually. The linked incidents share context, and resolving one does not automatically resolve the other.
References
- ✓Defender XDR correlates alerts into incidents based on shared entities, temporal proximity, and attack patterns.
- ✓Incident classifications: True positive, Informational (expected activity), False positive.
- ✓A hired, authorized penetration test is informational, expected activity, with a security-testing determination.
- ✓"Confirm user compromised" raises the user risk level in Entra ID Protection, triggering risk-based Conditional Access policies.
- ✓The Action center shows all pending and completed remediation actions across the organization.
- ✓AIR expands investigations beyond the initial alert to check for related suspicious activity.
1. Your organization hired a penetration testing firm. Their activity triggers multiple high-severity alerts. How should you classify the incident?
2. A SOC analyst clicks "Confirm user compromised" on a user entity in Defender XDR. What is the immediate effect?
3. Where can a SOC analyst review all pending and completed remediation actions across Defender XDR?
Keep learning
Use the knowledge check above to test your understanding. You can browse every lesson without signing in; opening another lesson does not mark this one complete.
Next lesson: Sentinel Architecture: Workspaces, Connectors and Costs →