This chapter covers the SOC incident triage and escalation process, a critical skill for the SC-200 exam. You will learn how to classify alerts, prioritise incidents, and follow standard escalation paths using Microsoft Defender XDR. Approximately 15-20% of exam questions touch on triage, alert classification, and escalation procedures. Mastering this topic ensures you can efficiently manage security incidents and pass the SC-200 exam.
Jump to a section
SOC incident triage works like a hospital emergency department (ED) triage system. When patients arrive, a triage nurse (the Tier 1 analyst) quickly assesses each patient's vital signs and symptoms against a standard protocol (the alert priority matrix). The nurse assigns a severity level: red (immediate life threat), yellow (serious but stable), or green (minor). This is exactly how a SOC triages alerts: a high-priority alert (e.g., ransomware detection) is escalated immediately to a specialist (Tier 2/3), while a low-priority alert (e.g., a single failed login) is either auto-closed or queued for batch review. The triage nurse does not diagnose or treat—they only decide who needs immediate attention. Similarly, Tier 1 analysts do not perform deep forensics; they validate the alert, check the initial context, and escalate if the alert is confirmed and critical. The ED's escalation path mirrors SOC escalation: if a patient's condition deteriorates, the nurse calls a code team (Tier 3). In the SOC, if an analyst discovers lateral movement, they escalate to the incident response team. Both systems rely on standardised criteria to avoid overwhelming specialists and to ensure the most critical cases get immediate resources. Without triage, both ED and SOC would collapse under the volume of cases, missing the truly dangerous ones.
What is SOC Incident Triage and Escalation?
SOC incident triage is the process of quickly evaluating incoming security alerts to determine their severity, validity, and required response. Escalation is the formal handoff of an incident to a higher-tier team or specialist when it exceeds the current analyst's authority or skill level. In Microsoft Defender XDR, triage is supported by automated alert classification, incident correlation, and a built-in queue management system. The goal is to reduce mean time to respond (MTTR) by ensuring that high-severity incidents get immediate attention while low-severity alerts are handled efficiently or dismissed.
Why Triage and Escalation Exist
A typical SOC receives thousands of alerts daily. Without triage, analysts would waste time on false positives and low-risk events, delaying response to genuine threats. Triage provides a structured, repeatable method to prioritise alerts based on risk. Escalation ensures that incidents requiring specialised skills (e.g., forensic analysis, threat hunting) are handled by the appropriate team. Microsoft Defender XDR integrates with Microsoft Sentinel to provide a unified incident queue where alerts from multiple sources (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps) are correlated into incidents. This reduces alert fatigue and helps analysts focus on what matters.
How Triage Works Internally in Microsoft Defender XDR
When a security alert is generated in Defender XDR, it is automatically assigned a classification and severity. The classification is based on the MITRE ATT&CK technique detected (e.g., Initial Access, Execution). Severity is determined by a combination of factors: the alert's confidence level, the asset's criticality, and the presence of active threats. For example, an alert for a successful ransomware execution on a domain controller is automatically classified as high severity, while a single failed logon from an unknown IP might be low severity.
Microsoft Defender XDR uses a machine learning model called the "Alert Triage Engine" to assign an initial priority score (0-100). Alerts with a score above 75 are automatically marked as high priority. The engine considers the following factors: - Alert confidence: How likely the alert represents a real threat (based on detection logic and telemetry). - Asset value: The criticality of the affected device or user (defined by the administrator via device tags or user risk). - Threat intelligence: Context from global threat feeds (e.g., known bad IPs, hashes). - Correlation: Whether the alert is part of a larger incident (multiple alerts linked by common entities).
Once an incident is created (a group of related alerts), it is assigned to the appropriate queue based on its severity and classification. The incident queue in the Microsoft 365 Defender portal (security.microsoft.com) allows analysts to filter by severity, status, assigned to, and source. The default views include: - High severity: Requires immediate action. - Medium severity: Should be investigated within 4 hours. - Low severity: Can be reviewed within 24 hours. - Informational: No action required, but may be used for reporting.
Key Components, Values, Defaults, and Timers
Incident Severity Levels: - High: Active threat with confirmed impact (e.g., ransomware execution, data exfiltration). SLA: 1 hour for initial response. - Medium: Suspicious activity with potential impact (e.g., lateral movement attempts, unusual PowerShell). SLA: 4 hours. - Low: Minor anomaly (e.g., single failed logon, policy violation). SLA: 24 hours. - Informational: No threat (e.g., successful logon from expected location). No SLA.
Alert Classification (MITRE ATT&CK): Each alert is tagged with a MITRE technique ID (e.g., T1078 - Valid Accounts). This classification helps analysts quickly understand the attack stage. The exam tests that you know how to use the MITRE mapping to prioritise incidents. For example, a T1486 (Data Encrypted for Impact) alert is always high priority.
Default Timers: - Auto-close timer: Low-severity alerts that are not touched within 72 hours are automatically closed (configurable in the alert rule settings). - Escalation timer: If a high-severity incident remains unassigned for 30 minutes, an escalation notification is sent to the SOC manager. - SLA breach timer: If a high-severity incident is not resolved within 1 hour, the incident is automatically escalated to Tier 3.
Configuration in Microsoft Defender XDR: - Alert suppression rules: Create rules to automatically close known false positives (e.g., admin activity from known IPs). - Automated investigation and response (AIR): For high-confidence alerts, Defender XDR can automatically run playbooks (e.g., isolate a device, block an IP). - Custom detection rules: Use KQL to create custom alerts that trigger on specific behaviours, overriding default severity.
Verification Commands: To check the current incident queue via PowerShell, you can use the Microsoft Graph API or the Defender XDR PowerShell module. Example:
# Connect to Defender XDR
Connect-MgGraph -Scopes "Incident.Read.All"
# Get all incidents with high severity
Get-MgSecurityIncident -Filter "severity eq 'high'"How Triage Interacts with Related Technologies
Microsoft Sentinel: Incidents from Defender XDR are automatically forwarded to Sentinel if the SIEM is configured. Sentinel provides additional triage capabilities like custom analytics rules and workbook dashboards. The exam tests that you understand the difference: Defender XDR handles triage for Microsoft 365 workloads, while Sentinel extends triage to on-premises and third-party sources.
Microsoft Defender for Cloud: Alerts from VMs and cloud workloads are ingested into Defender XDR via the connector. Triage for cloud alerts follows the same severity rules, but the asset value is determined by the resource's criticality tag.
Microsoft Purview: Alerts related to data loss prevention (DLP) are triaged in the Purview compliance portal, but they can also be correlated with Defender XDR incidents if the integration is enabled. The exam may ask about the difference: DLP alerts are typically informational, while Defender XDR alerts are security-focused.
Triage Workflow Steps
The typical triage workflow in a SOC using Microsoft Defender XDR includes: 1. Alert reception: Alerts appear in the incident queue. 2. Triage assessment: Analyst reviews the alert details (description, affected entities, timeline). 3. Classification: Determine if the alert is a true positive, false positive, or benign true positive (e.g., authorised penetration test). 4. Priority assignment: If the alert is a true positive and high severity, escalate immediately. If low severity, queue for later review. 5. Escalation: Hand off to Tier 2/3 with a summary and evidence. 6. Resolution: Close the incident after remediation.
Microsoft Defender XDR automates steps 1 and 4 via the alert triage engine. The analyst's main job is steps 2 and 3.
Common Triage Mistakes
Ignoring low-severity alerts: Attackers often use low-and-slow techniques that start as low-severity alerts. Always investigate if there is a pattern.
Over-reliance on automation: Automated triage can miss context (e.g., a known admin performing unusual actions). Always validate.
Failure to escalate: If an alert involves a critical asset (e.g., domain controller), escalate even if severity seems low.
Receive and Queue Alerts
Alerts from Microsoft Defender XDR sensors (endpoint, email, identity, cloud apps) are ingested into the unified incident queue. Each alert is automatically assigned a severity (high, medium, low, informational) and a classification based on MITRE ATT&CK. The queue is displayed in the Microsoft 365 Defender portal under Incidents & alerts > Incidents. Analysts can filter by severity, status, and assigned user. The default view shows unresolved incidents sorted by severity descending. At this stage, no human action has occurred; the system has already performed initial correlation and grouping of related alerts into incidents.
Triage Assessment by Tier 1
The Tier 1 analyst opens the incident and reviews the alert details: description, affected devices/users, timeline, and evidence (e.g., file hashes, IPs, processes). They use the MITRE technique ID to understand the attack stage. The analyst checks the alert's confidence score (displayed in the alert page) and any automated investigation results (e.g., suspicious file verdict). They determine if the alert is a true positive (real threat), false positive (benign activity), or benign true positive (authorised test). The analyst also checks the asset criticality (e.g., device tagged as 'domain controller' or 'executive'). This step typically takes 5-10 minutes per incident.
Classification and Priority Assignment
Based on the assessment, the analyst assigns a classification: True Positive, False Positive, or Benign Positive. For true positives, they set the incident severity (which may override the automatic severity if the context warrants it). For example, a medium-severity alert involving a domain controller may be manually upgraded to high. The analyst also adds a comment explaining the rationale. If the alert is a false positive, they close it with the 'False Positive' classification and optionally create a suppression rule to prevent future duplicates. This step is crucial for maintaining an accurate incident queue and improving automation.
Escalation to Tier 2/3
If the incident is a confirmed true positive and requires deeper investigation (e.g., lateral movement, data exfiltration, or a novel technique), the Tier 1 analyst escalates to Tier 2 or Tier 3. Escalation is done by reassigning the incident to the appropriate team (e.g., 'SOC Tier 2' group) and adding a detailed note with the initial findings, affected entities, and suggested next steps. The escalation triggers a notification to the next-tier analysts. In Microsoft Defender XDR, escalation can also be automated via playbooks: if an incident meets certain criteria (e.g., severity high and asset critical), a playbook can reassign and notify. Timers: high-severity incidents must be escalated within 30 minutes per typical SLA.
Investigation and Remediation by Tier 2/3
Tier 2 analysts perform deep forensics using advanced tools like Microsoft 365 Defender advanced hunting (KQL), Microsoft Sentinel, and third-party EDR tools. They contain the threat by isolating devices, blocking IPs, or disabling accounts. Tier 3 analysts (often threat hunters) perform root cause analysis and develop signatures for future detection. After remediation, the incident is resolved and closed with a detailed report. The SOC manager reviews the incident closure to ensure proper documentation and lessons learned. This step may take hours to days depending on complexity.
Scenario 1: Ransomware Attack on a Hospital Network
A hospital SOC uses Microsoft Defender XDR to protect endpoints, email, and identities. One morning, multiple high-severity alerts fire for a device running a suspicious PowerShell script that attempts to encrypt files. The alerts are automatically correlated into a single incident. The Tier 1 analyst triages the incident: they see the device is a critical server (tagged 'Domain Controller') and the alert classification is T1486 (Data Encrypted for Impact). The analyst confirms it is a true positive and immediately escalates to Tier 3. Tier 3 isolates the server, blocks the ransomware's command-and-control IP, and initiates a password reset for all domain accounts. The incident is resolved within 2 hours. Without proper triage, the analyst might have ignored the alert as a false positive, leading to widespread encryption.
Scenario 2: Phishing Campaign Targeting Executives
A financial firm receives multiple medium-severity alerts for suspicious email attachments sent to the CEO and CFO. The alerts are classified as T1566.001 (Spearphishing Attachment). The Tier 1 analyst triages the incident: they check the email headers, find the attachment is a macro-enabled Word document, and see that the users have not opened the attachment. The analyst classifies this as a true positive but low risk (no execution). They escalate to Tier 2 to perform a deeper email investigation and block the sender. Tier 2 uses Microsoft Defender for Office 365 to delete the emails from all mailboxes and add the sender to the blocklist. The incident is closed within 4 hours. Common misconfiguration: If the SOC had not tagged the executives' mailboxes as high-value, the alert might have been automatically downgraded to low severity, delaying response.
Scenario 3: Insider Threat via Data Exfiltration
A technology company detects an alert for an unusual amount of data being uploaded to a personal cloud storage account from a finance employee's device. The alert is medium severity (T1048 - Exfiltration Over Alternative Protocol). Tier 1 triages: the employee is a senior accountant with access to sensitive financial data. The analyst checks the user's recent activity and finds multiple failed logins from the employee's account from a foreign IP. The analyst escalates to Tier 2 as a potential account compromise. Tier 2 investigates and confirms the account was compromised via a keylogger. They disable the account, revoke sessions, and reset credentials. The incident is resolved in 6 hours. A common mistake: Tier 1 might have dismissed the alert as a false positive because the employee regularly uses cloud storage for work, but the escalation criteria (foreign IP + data volume) should trigger a deeper look.
What SC-200 Tests on This Topic
The SC-200 exam objective 1.1 focuses on "Manage security alerts and incidents" within Microsoft Defender XDR. Specifically, you must understand:
How to triage incidents using the Microsoft 365 Defender portal.
How to classify alerts (true positive, false positive, benign positive).
How to escalate incidents to appropriate teams.
How to use automated investigation and response (AIR) to handle triage.
The role of MITRE ATT&CK classifications in prioritisation.
Common Wrong Answers and Why Candidates Choose Them
1. Wrong answer: "All high-severity alerts should be escalated immediately without triage." Why chosen: Candidates think high severity always means critical. But a high-severity alert could be a known false positive (e.g., a scheduled vulnerability scan). Triage is still required.
2. Wrong answer: "Low-severity alerts can be ignored." Why chosen: Candidates assume low severity means no threat. However, low-severity alerts can be indicators of a larger attack (e.g., a single failed logon is part of a brute force). Always investigate patterns.
3. Wrong answer: "Automated investigation replaces the need for human triage." Why chosen: The exam emphasises automation, but automation only handles high-confidence alerts. Human triage is needed for ambiguous cases.
4. Wrong answer: "Escalation is only for high-severity incidents." Why chosen: Candidates think medium/low severity never requires escalation. But if a medium-severity alert involves a critical asset (e.g., CEO's device), it should be escalated.
Specific Numbers and Terms That Appear Verbatim
SLA timers: High severity – 1 hour initial response; Medium – 4 hours; Low – 24 hours.
Auto-close timer: 72 hours for untouched low-severity alerts.
MITRE ATT&CK technique IDs: T1078 (Valid Accounts), T1486 (Data Encrypted for Impact), T1566 (Phishing).
Alert classification options: True positive, False positive, Benign positive.
Severity levels: High, Medium, Low, Informational.
Edge Cases and Exceptions
Benign positive: An alert that is a true positive but authorised (e.g., penetration test). Must be classified as benign positive, not false positive.
Multiple incidents for the same attack: Defender XDR may create separate incidents for different phases. The analyst must manually merge them if they are related.
Suppression rules: If you create a suppression rule for a false positive, it does not delete existing alerts; it only prevents future ones.
How to Eliminate Wrong Answers
If an answer says "always escalate high severity," it is wrong because triage must first validate.
If an answer says "automated investigation can close all low-severity alerts," it is wrong because some low-severity alerts need human review.
If an answer mentions "MITRE ATT&CK" without specific technique ID, it is likely a distractor.
If an answer says "informational alerts require immediate action," it is wrong by definition.
Triage is the process of evaluating alerts to determine severity, validity, and required response.
Escalation is the formal handoff to a higher-tier team when the incident exceeds Tier 1 authority or skill.
Microsoft Defender XDR automatically classifies alerts using MITRE ATT&CK and assigns severity based on confidence, asset value, and threat intelligence.
Default SLA timers: High severity = 1 hour, Medium = 4 hours, Low = 24 hours.
Auto-close timer for untouched low-severity alerts is 72 hours.
Alert classification options: True positive, False positive, Benign positive.
Always triage before escalating, even for high-severity alerts.
Low-severity alerts should not be ignored; they may indicate a larger attack pattern.
Automated investigation (AIR) does not replace human triage for ambiguous cases.
Escalation criteria include severity, asset criticality, and legal/sensitive implications.
These come up on the exam all the time. Here's how to tell them apart.
Manual Triage
Analyst reviews each alert individually.
Takes longer but provides human context.
Suitable for ambiguous or low-confidence alerts.
Requires more staffing.
Can handle novel attack patterns.
Automated Triage (AIR)
System automatically classifies and prioritises alerts.
Fast and consistent for known patterns.
Suitable for high-confidence alerts with playbooks.
Reduces analyst workload.
May miss context or false positives not in the model.
Mistake
All high-severity alerts require immediate escalation to Tier 3.
Correct
High-severity alerts still require triage to confirm they are true positives. A known false positive (e.g., admin running a scan) should be closed as false positive, not escalated.
Mistake
Low-severity alerts can be automatically closed without review.
Correct
Low-severity alerts may be part of a larger attack pattern. Microsoft Defender XDR does auto-close after 72 hours, but analysts should periodically review low-severity alerts for correlation.
Mistake
Automated investigation and response (AIR) completely replaces human triage.
Correct
AIR only handles high-confidence alerts with predefined playbooks. Human triage is required for ambiguous alerts, novel attacks, and context-dependent decisions.
Mistake
Escalation is only for incidents that require technical expertise beyond Tier 1.
Correct
Escalation also occurs when an incident involves sensitive data, legal implications, or requires management approval (e.g., isolating a CEO's device).
Mistake
The incident severity set by the system cannot be changed by analysts.
Correct
Analysts can manually override severity based on additional context (e.g., a medium-severity alert on a domain controller can be upgraded to high).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An alert is a single detection event (e.g., a suspicious process). An incident is a collection of related alerts that together indicate an attack. Incidents provide a unified view of the attack chain. In the exam, remember that incidents are the primary triage unit; you investigate incidents, not individual alerts.
To escalate, open the incident, click 'Assign to', and select the appropriate group (e.g., 'SOC Tier 2'). Add a note with your findings and suggested next steps. You can also use automated playbooks to escalate based on criteria.
A benign positive is a true positive alert that is authorised (e.g., a penetration test or approved admin activity). It should be classified as 'Benign positive' to distinguish it from malicious true positives. This classification prevents unnecessary escalation.
Yes, analysts can manually override the severity by editing the incident properties. For example, if a medium-severity alert involves a domain controller, you can upgrade it to high. This is a common exam scenario.
If a high-severity incident is not resolved within 1 hour, it may be automatically escalated to Tier 3 or the SOC manager. The exact behaviour depends on your organisation's configuration. The exam tests that you know the default SLA timers.
MITRE ATT&CK classification (e.g., T1486 for ransomware) immediately tells the analyst what stage of the attack the alert represents. This helps prioritise: alerts in later stages (e.g., impact) are usually higher priority than initial access alerts.
By default, low-severity alerts that are not reviewed within 72 hours are automatically closed. This timer is configurable in the alert rule settings. The exam may ask you to identify this default value.
You've just covered SOC Incident Triage and Escalation — now see how well it sticks with free SC-200 practice questions. Full explanations included, no account needed.
Done with this chapter?