Triaging your first incident in Microsoft Defender XDR

Your first shift in a SOC will probably start with a queue of incidents in the Microsoft Defender portal. Defender XDR groups related alerts from endpoints, identities, email and cloud apps into incidents, so one incident can hold a phishing email, the sign-in that followed it and the device where something ran.

Triage is not the full investigation. It is the first pass that answers three questions quickly: is this real, how serious is it, and what happens next? This tutorial gives you a repeatable way to answer them, so that every incident you touch ends up either escalated with evidence or closed with a reason.

Before you start

You need access to the Microsoft Defender portal with a role that lets you view and manage incidents. The steps follow Microsoft's documentation on prioritizing, investigating and managing incidents.

The triage, step by step

1. Pick an incident and claim it

   Open Investigation & response → Incidents & alerts → Incidents. By default the queue shows incidents from the last week with status New or In progress and severity High, Medium or Low. Each incident has a priority score from 0 to 100, calculated from signals such as severity, MITRE techniques, asset criticality and known threats; scores above 85 are shown in red as top priority.

   Start with the highest priority incident that nobody owns. Before you read anything else, open Manage incident, assign it to yourself and set the status to In progress, so that two analysts do not work the same incident without knowing it.

2. Read the story

   Select the incident row (not its name) to see a summary pane, then open the incident page. Start with the Attack story: the alerts in time order and a graph of the entities involved. Answer two questions in your notes: what was the first thing that happened, and what was the last?

   The alert names and their MITRE ATT&CK categories tell you how far the attack got. An incident that stops at Initial access (a phishing email that was delivered) is very different from one that reaches Credential access or Lateral movement.

3. Measure the scope

   Open the Assets tab. It lists the devices, users, mailboxes, apps and cloud resources involved, with a count for each. Note:

   • How many users and devices are involved: one, a few or many.
   • Whether any of them is a privileged account, a server or an asset tagged as critical.
   • Whether the same user or device appears in other recent incidents. Searching the incident queue for an asset's name shows every incident that includes it.

4. Check the evidence and what Defender already did

   The Evidence and Response tab lists the files, processes, emails, IP addresses and URLs found in the alerts. Each one has a verdict (Malicious, Suspicious or Clean) and a remediation status. Look for actions marked Pending approval: Defender's automated investigation may be waiting for someone to approve quarantining a file or removing an email.

   The Investigations tab lists automated investigations triggered by the alerts. Alerts from Defender for Office 365 are an exception: their investigations do not show there, so open the email alert itself and follow its investigation link.

5. Confirm with a query

   Do not decide only from the alert titles. Go hunt, available from entities in the attack story, runs ready-made advanced hunting queries for a user, device, IP address or file. You can also write your own. This KQL query lists every alert involving a user in the last seven days, across all Defender products:

   let user = "j.silva@contoso.com"; // the user from the incident
   let alertIds = AlertEvidence
       | where Timestamp > ago(7d)
       | where AccountUpn =~ user
       | distinct AlertId;
   AlertInfo
   | where Timestamp > ago(7d)
   | where AlertId in (alertIds)
   | project Timestamp, Title, Severity, ServiceSource, AttackTechniques
   | order by Timestamp asc

   AlertEvidence holds the entities of each alert and AlertInfo its details, joined by AlertId. Replace AccountUpn with DeviceName to run the same check for a device. Alerts in other incidents, or from a different product, often change the picture.

6. Decide what it is

   Now classify the incident. Defender offers three classifications:

   • True positive: a real threat, with a threat type such as phishing or malware. A true positive is escalated or contained according to your team's runbook, for example by isolating the device or disabling the account.
   • Informational, expected activity: the activity was real but allowed, such as a penetration test or an administrator's authorized tool.
   • False positive: the detection was wrong. A false positive is closed, and the reason goes to whoever tunes the detections.

   If you cannot decide with the evidence you have, do not guess. Escalate with your notes, or keep the incident In progress and say what is missing.

7. Document and close

   Add a comment to the incident's activity log with what you checked, what you found and why you decided as you did. Write it for the analyst who opens the incident in six months. Then set the classification and, if your work is done, change the status to Resolved and add a resolution note.

   In the classic experience, resolving an incident also resolves all of its alerts. In the new incident cases, alerts keep their own status, so check them separately.

A worked example

An incident named Initial access incident involving one user reported by multiple sources appears with a priority score of 78:

• Story: Defender for Office 365 flagged an email with a link to a credential-phishing page; minutes later, Entra ID Protection flagged a sign-in from an anonymous IP address for the recipient.
• Scope: one user, one mailbox, no devices, no privileged roles.
• Evidence: the email was removed after delivery by zero-hour auto purge (ZAP), but the user had already clicked the link.
• Query: the alerts query shows a new inbox rule alert for the same user an hour later.
• Decision: true positive, phishing. The user clicked, the account was used and the attacker started hiding mail. Escalate for containment: revoke sessions, reset credentials and remove the rule, following the same steps as in a business email compromise.

The note on the incident lists the sign-in IP address, the rule, the time of the click and the actions requested.

Common mistakes

• Closing on the title alone. Two incidents with the same name can be a blocked email and a compromised account.
• Ignoring pending actions. Automated remediation that waits for approval does nothing until someone approves it.
• Leaving no notes. An incident closed without a reason cannot be audited, and the next analyst has to start from zero.
• Treating "expected activity" as false positive. Classifying correctly is how detection engineers know whether a rule is wrong or simply noisy.

Why it matters for a SOC analyst

Triage is the job you will do most often, and the one people judge you on first. A consistent routine of claiming, reading the story, measuring scope, checking evidence, confirming with a query, deciding and documenting makes you fast without making you careless. It also produces something valuable for the whole team: incidents that tell a clear story long after they were closed. That is the first step of good incident response.