Microsoft Sentinel SOAR — Incidents, Automation Rules & Playbooks

① The incident lifecycle — how alerts become a case you can work

Analytics rules raise alerts — single pieces of evidence. On their own they are noise. Sentinel (and the Defender correlation engine) group related alerts into an incident: one case file holding the alerts, the entities (users, hosts, IPs), comments and tags. Unlike an alert, an incident is modifiable and tracks the evolving attack story.

Every incident carries three triage fields you must name: a status (New, Active, Closed), an owner (the analyst assigned), and a severity (Informational, Low, Medium, High). When an incident is closed it also gets a classification — True Positive, Benign Positive, False Positive or Undetermined. Analysts triage from the incident queue; this is the focal point of the SOC.

The interview line: you automate around incidents, not raw alerts, because the incident is the thing with status, owner and the full evidence trail.

② Automation rules — the no-code traffic cop

An automation rule manages incident handling from one central place, no code required. It has a trigger — fire when an incident is Created or Updated (or on alert creation) — a set of conditions (e.g. severity is High, title contains a keyword, a specific analytics rule), and an ordered list of actions.

What the actions can do

Without any playbook, a rule can add tags, assign an owner, change severity or status, close an incident with a classification, and add analyst tasks (a checklist on the incident). It can also run a playbook for heavier work, and apply to many analytics rules at once.

Two details interviewers love: order — rules run sequentially by an order number, and a later rule sees the incident as left by earlier rules; and an expiration date — a time-limited rule, perfect for auto-closing the 'noise' from a planned penetration test or maintenance window.

③ Playbooks — Azure Logic Apps doing the real work

A playbook is a collection of response actions built as a workflow in Azure Logic Apps. That gives you a visual designer plus a huge gallery of connectors (Teams, ServiceNow, Jira, Entra ID, Defender for Endpoint, and more).

The Microsoft Sentinel connector offers three triggers: the incident trigger (recommended — receives the whole incident with its alerts and entities), the alert trigger, and the entity trigger (run on a single user/IP/host during hunting). After the trigger come the actions: typical patterns are enrich (look up an IP or user), notify (post to a Teams channel), block/disable (disable an Entra user, block an IP) and isolate (isolate a device via Defender for Endpoint).

Key rule: only incident-triggered playbooks can be called by an automation rule. Alert- and entity-triggered playbooks are run manually.

④ Designing a response — manual vs auto, and the 2026 portal

You can run a playbook manually — open an incident, choose Run playbook, pick a human-in-the-loop action — or automatically, by attaching it to an automation rule so it fires the moment an incident is created. The pro move: start manual, watch the runs in the Logic Apps run history, then promote the trusted ones to fully automatic.

Where this lives in 2026

Everything now runs in the unified Microsoft Defender portal, where Sentinel and Defender XDR share one incident queue with bi-directional sync of status, owner and closing reason. (Microsoft Sentinel in the standalone Azure portal retires on 31 March 2027, so the Defender portal is the place to learn.)

Good auto-response design is about SOC efficiency: automate the boring, repeatable, low-false-positive steps (enrich, tag, ticket, notify), keep a human gate before high-impact actions (isolate, disable), and use automation rules to cut alert fatigue so analysts spend time on the real attack story.