Microsoft SC-200: Investigating with Defender XDR

Microsoft SC-200 investigation work is about turning scattered security signals into a defensible incident story. Alerts are only starting points. The analyst has to decide what happened, which entities are affected, what evidence is reliable, what uncertainty remains, and which action is proportionate to the current risk.

SC-200 remains active as of October 23, 2026, with its October 21 English skills update now in effect. Use that current official guide to decide which investigation tasks your practice must demonstrate. The investigative workflow below is intentionally based on durable Defender XDR, Sentinel, KQL, and response reasoning rather than on one interface layout.

Begin with incident scope, not alert severity

A high-severity alert may belong to a small contained event, while several lower-severity signals can form a larger attack chain. Start by identifying the affected identity, device, cloud resource, application, and time window. Separate confirmed observations from assumptions so the investigation does not become anchored to the first alert description.

Build a timeline early. Sign-ins, process activity, email events, network connections, and administrative changes make more sense when placed in sequence. The timeline also reveals gaps that later hunting or queries must resolve.

Triage should also account for asset value and business context. The same suspicious command on a disposable test device and on a domain controller does not create the same response priority. Attach criticality and ownership early so later containment decisions reflect business risk as well as technical confidence.

Use entity context to build the attack story

Entities connect alerts that otherwise look unrelated. A user may appear in a risky sign-in, an endpoint alert, a mailbox event, and a cloud-resource change. Following those relationships helps the analyst decide whether the signals represent one compromise, several independent events, or legitimate behavior that only looks suspicious in isolation.

The Defender XDR investigation workflows model is useful because it keeps incidents, alerts, entities, evidence, and response in one narrative. The goal is not to click every entity page; it is to use each pivot to answer a specific unresolved question.

Entity context should include normal behavior as well as suspicious behavior. A sign-in from a new location may be benign if the user is traveling, while an ordinary-looking process can be significant if it appears immediately after credential theft. Compare the event with recent baseline behavior before assigning meaning. That prevents the investigation from treating every anomaly as compromise or every familiar event as harmless.

Read endpoint evidence in sequence

Endpoint evidence becomes meaningful when process creation, parent-child relationships, persistence, credential access, network activity, and remediation are connected chronologically. A single process hash or command line may be interesting, but the surrounding sequence determines whether it is malicious, administrative, or simply unusual.

When investigating a device, ask what launched the process, what changed afterward, what external systems were contacted, and whether the same behavior appears elsewhere. Preserve decisive evidence before containment where possible so the response does not remove the context needed to understand the attack.

Investigate identity signals with the same discipline

Compromised accounts can create sign-in anomalies, privilege changes, consent events, token abuse, mailbox activity, and downstream endpoint or cloud actions. Treat identity events as part of the same incident timeline rather than as a separate product problem.

Compare expected user behavior with the observed sign-in and administrative sequence. A password reset may be necessary, but it does not automatically revoke every session, remove persistence, or explain what the attacker already accessed. Response should follow the scope established by evidence.

Identity evidence should also be tied to session continuity. A password change may stop future authentication without terminating existing tokens or sessions, and a disabled account may leave application-specific persistence to investigate. Check what access remains after each response so identity remediation is verified rather than assumed.

Use automated investigation as evidence, not a substitute for judgment

Automated investigation can collect artifacts, evaluate evidence, and take defined actions, but the analyst still needs to understand what the automation proved and what it did not. A completed action is not the same as confirmed containment, and an automated conclusion should be checked against the wider incident context.

Review one automated result and list the remaining human questions. Did the action affect every compromised entity? Were credentials or tokens still valid? Did the attacker touch systems outside the automated scope? That review keeps automation useful without turning it into a black box.

Automation can also fail partially. A device action may succeed while an identity action fails, or the automated scope may not include a third-party system involved in the incident. Review automation results as a set of completed and incomplete steps, then decide whether the remaining risk requires manual action or another team.

Escalate into hunting when the incident leaves gaps

Hunting should begin with a hypothesis, not with a large query. KQL threat hunting and detection is strongest when the analyst can state what behavior is being tested, which data sources contain the evidence, and how the result changes the incident scope.

Write the smallest query that can answer the question, validate it against known evidence, and then broaden carefully. Time range, entity identifiers, joins, summarization, and exclusions should all have an investigative purpose. A query that returns many rows but does not change confidence or scope has not moved the case forward.

Hunting is also useful after containment. Once the immediate risk is reduced, search historical data for the same technique, infrastructure, account pattern, or artifact to determine whether the incident began earlier or affected additional entities. That retrospective scope check can change remediation and detection improvements even after the active threat appears contained.

Choose containment actions by blast radius

Disable account, revoke session, isolate device, block indicator, or automate a response only when the evidence and business impact support the action. Broad containment can reduce risk quickly, but it can also interrupt legitimate work or destroy useful evidence. The most aggressive action is not automatically the best answer.

Define what you expect each action to change and how you will verify it. If a device is isolated, confirm that the suspicious communication stops. If an account is disabled, check whether active sessions or application identities create additional paths. Response is complete only when the new risk state is observable.

Containment should also consider dependency chains. Isolating a server can stop attacker movement but may interrupt a business service; revoking a privileged account can block incident responders if emergency access is not ready. State the expected security benefit, business consequence, and recovery step before taking a high-impact action. This makes the response defensible even when time pressure is high.

Connect Defender XDR with Sentinel operations

Defender XDR and Sentinel can appear in the same investigation without owning the same task. Microsoft Sentinel analytics and automation adds broader SIEM/SOAR data, analytics, hunting, and workflow capabilities; Defender XDR provides deep correlated Microsoft security evidence. Move between them because a question requires another data source or capability, not because both portals are available.

Detection quality also feeds the investigation workflow. Sentinel detection-rule engineering should produce alerts with enough entity context and logic for an analyst to understand why they fired. Tuning future detections and containing the current incident are separate activities and should not be confused.

Measure readiness by investigation quality

Good investigation notes make the next action obvious. Summarize affected scope, decisive evidence, confidence, actions already taken, unresolved questions, and follow-up owners. Another analyst should be able to continue the case without replaying every portal step.

Practice with incomplete evidence as well as clean examples. Sometimes the right conclusion is a confidence statement and a monitoring plan rather than certainty. That ability to preserve uncertainty while still making a proportionate operational decision is a better SC-200 readiness signal than memorizing which page contains a particular button.

A final quality check is whether your conclusion survives challenge. Ask another analyst to review the evidence and identify the weakest assumption in the incident story. If a different interpretation is plausible, state what additional evidence would distinguish the two. That habit keeps investigation notes honest and makes escalation decisions easier to defend.

Review one case after a delay and see whether the notes still make sense without the original portal context. If the narrative depends on screenshots, unstated assumptions, or your memory of why a query was run, the documentation is not strong enough. Durable case notes should preserve the investigative logic so another analyst can audit or resume the work later.

Investigation quality also depends on stopping at the right time. Once the incident scope is stable, the immediate threat is contained, and remaining uncertainty has a documented owner, continuing to collect evidence can create delay without changing the decision. Analysts should know when additional data is likely to alter response and when the case is ready to move into remediation, lessons learned, or detection improvement.

A strong case also distinguishes containment from eradication. Stopping attacker activity can stabilize the incident, but the team may still need to remove persistence, rotate credentials, patch the entry point, and verify that monitoring covers the path used in the attack.