5.1 Sentinel Incident Management

Why Incident Management Matters for SC-200

The Respond to security incidents domain is 35-40% of the SC-200 exam, and Microsoft Sentinel incident management is its operational core. The exam tests whether you can take a noisy stream of alerts, group it into meaningful incidents, triage by risk, drive an investigation to a defensible conclusion, and close the case with the correct classification. You will see scenario questions that hand you an incident state and ask for the next correct action.

Microsoft Sentinel is Microsoft's cloud-native security information and event management (SIEM) and security orchestration, automation, and response (SOAR) platform. An incident in Sentinel is a case container that aggregates one or more related alerts. Analysts work incidents, not raw alerts, because a single attack usually fires many alerts.

The Incident Lifecycle

Every Sentinel incident moves through a defined lifecycle. Knowing the order — and which field changes at each stage — is heavily tested.

flowchart LR
  A[Alerts fired] --> B[Analytics rule groups alerts]
  B --> C[Incident created: New]
  C --> D[Triage: assign severity + owner]
  D --> E[Active: investigate]
  E --> F{Real threat?}
  F -->|Yes| G[Remediate via playbook]
  F -->|No| H[Close: Benign/False Positive]
  G --> I[Close: True Positive]

Triage: Severity, Owner, and Status

Three fields drive triage and each can be set manually or by automation.

• Severity — Informational, Low, Medium, or High. Severity is inherited from the analytics rule but can be overridden on the incident, and automation rules can change it dynamically based on entity properties.
• Owner — the analyst or group responsible. Assigning an owner is the formal start of ownership; an unassigned high-severity incident is a triage failure scenario the exam likes to test.
• Status — New, Active, or Closed. Moving to Active signals work in progress. Closing an incident requires a classification.

Closing Classifications

Closing as Benign Positive or False Positive lets you record a reason that feeds tuning and automation rule suppression so the same noise does not reopen later.

Entity Mapping and the Investigation Graph

Entity mapping is configured on the analytics rule, not on the incident. It tells Sentinel which columns in the query results represent strongly typed entities such as Account, Host, IP, URL, File, or Process. This mapping is what makes investigation possible.

• Mapped entities appear in the Entities tab of the incident.
• They populate the investigation graph, an interactive map that lets you expand an entity to see related alerts, other incidents, and the timeline of activity around it.
• Entities also enable entity pages and let automation rules and playbooks act on real objects (for example, disable a specific account).

Exam trap: if the investigation graph is empty or an entity is missing, the fix is almost always to edit the analytics rule's entity mapping, not the incident. Entity mapping cannot be retrofitted onto already-created incidents.

The investigation graph supports up to a configurable number of mapped entities per rule (Microsoft has historically capped this; map the highest-value entities like Account, Host, and IP first when you must choose).

Bookmarks: Turning Hunting Into Evidence

When you run a hunting query in Sentinel and find something suspicious, a raw query result is not yet part of any case. A bookmark preserves a specific query result — the query, the time range, and the selected rows — so it becomes durable evidence.

• Bookmarks can have mapped entities and tags.
• A bookmark can be added to a new incident or attached to an existing incident.
• Bookmarked entities appear in the investigation graph, linking hunting findings to the formal case.

flowchart LR
  A[Hunting query] --> B[Suspicious rows found]
  B --> C[Create bookmark + map entities]
  C --> D{Existing incident?}
  D -->|Yes| E[Attach bookmark to incident]
  D -->|No| F[Create new incident from bookmark]

Incident Tasks

Incident tasks are a checklist embedded in the incident. They standardize how every analyst handles a case so triage quality does not depend on who picked it up.

• Tasks can be added manually by an analyst or automatically by an automation rule or playbook when the incident is created.
• Each task has a title, optional description, and a completion state.
• Tasks travel with the incident, so a SOC lead can audit whether required steps (verify entity, check threat intelligence, contact owner, document outcome) were completed before closure.

A common SC-200 scenario: a SOC wants every phishing incident to follow the same verification steps regardless of analyst. The correct answer is an automation rule that adds incident tasks on incident creation — not training, not a runbook outside the platform.