# Microsoft Sentinel SOAR — Incidents, Automation Rules & Playbooks Source: https://ai.techclick.in/blog_microsoft_sentinel_soar_automation Markdown: https://ai.techclick.in/blog_microsoft_sentinel_soar_automation.md Publisher: Techclick Infosec Pvt Ltd A clear, interactive guide to Microsoft Sentinel SOAR (2026): how alerts group into incidents with status, owner and severity; automation rules (triggers, conditions, ordering, assign/tag/close); playbooks built on Azure Logic Apps (incident/alert/entity triggers, connectors, enrich/notify/disable/isolate); running playbooks manually vs automatically; and how it all fits the unified Microsoft Defender portal. Microsoft Sentinel SOAR — Incidents, Automation Rules & Playbooks student learning map A visual study map for Microsoft Sentinel SOAR — Incidents, Automation Rules & Playbooks showing learning path, evidence, traps, and practice sequence. TECHCLICK STUDY MAP Microsoft Sentinel SOAR — Incidents, Automation... Microsoft · learn the flow, prove with evidence, avoid unsafe shortcuts 1. Start 🎯 By the end you will be able to 2. Understand Pick where you want to start 3. Prove ① The incident lifecycle — how... 4. Practice ② Automation rules — the no-code... How to use this page First build the mental model, then connect the concept to a realistic production decision. Finish by testing yourself. Techclick Infosec Pvt Ltd | ai.techclick.in | Training Contact: WhatsApp +91 92772 29456 Content-specific feature visual for this lesson: use it as the 60-second map before reading the full detail. Most engineers think… Most people lump 'automation rules' and 'playbooks' together as one fuzzy thing called 'Sentinel automation', and freeze in an interview when asked the difference. They are two distinct layers. An automation rule is a no-code orchestrator that lives inside Microsoft Sentinel: it fires on an incident being created or updated , checks conditions, and runs simple actions in order — tag, assign an owner, change severity, close, add tasks — and it can call a playbook . A playbook is a workflow built on Azure Logic Apps that does the real work across other systems: enrich an IP, message Teams, open a ServiceNow ticket, disable an Entra user, isolate a device. Knowing that split — rule = traffic cop, playbook = the actions — is what lets you design a clean auto-response instead of a tangle. ## ① 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. Figure 1 — From log to action — the SOAR pipeline Analytics rules raise alerts, alerts group into an incident, then automation rules and playbooks respond. - From log to action — the SOAR pipeline Alert analytics rule fires Incident alerts grouped Triage status/owner/severity Auto rule tag/assign/route Playbook enrich/notify/act Analytics rules raise alerts, alerts group into an incident, then automation rules and playbooks respond. Quick check · Q1 of 10 · Understand What is the difference between an alert and an incident in Sentinel? a) They are the same thing b) An alert is a single piece of evidence; an incident groups related alerts into one modifiable case with status, owner and severity c) An incident is smaller than an alert d) An incident is only the KQL query Correct: b. Alerts are single signals. An incident aggregates related alerts (plus entities, comments, tags) into one case file that carries status, owner and severity — which is why you automate around incidents, not raw alerts. 👉 So far: Alerts are single signals; an incident groups related alerts into one modifiable case with a status, owner and severity. You automate around incidents, not raw alerts. ## ② 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. Figure 2 — Automation rules vs playbooks The single most-asked interview question — keep these two layers separate. Automation rules vs playbooks Automation rule Lives inside Sentinel, no code Trigger: incident created/updated Actions: tag, assign, severity, Runs in order; can have an expiry Can call a playbook Playbook (Logic Apps) Built on Azure Logic Apps Trigger: incident, alert or entity Actions via connectors to other Enrich, notify, disable user, Runs auto (via rule) or manually The single most-asked interview question — keep these two layers separate. 🗂️ Incident tap to flip A case file grouping related alerts, entities and comments. Carries a status, an owner and a severity — the unit you automate around. 🚦 Automation rule tap to flip No-code orchestrator inside Sentinel. Fires on incident created/updated, checks conditions, runs ordered actions: tag, assign, close, add tasks, call a playbook. 🤖 Playbook tap to flip An Azure Logic Apps workflow of response actions. Triggered by an incident, alert or entity; chains connectors to enrich, notify, disable or isolate. 🔌 Connector tap to flip A pre-built Logic Apps integration to another system — Teams, ServiceNow, Entra ID, Defender for Endpoint — so the playbook can act without custom code. Say 'rule = traffic cop, playbook = the actions' In an interview, anchor the answer on the split: an automation rule is the no-code orchestrator inside Sentinel (triggers, conditions, order, tag/assign/close) and it can call a playbook; the playbook is the Logic Apps workflow that does cross-system work (enrich, notify, disable, isolate). State that one line and you've nailed the most common Sentinel SOAR question. Quick check · Q2 of 10 · Remember Which of these can an automation rule do WITHOUT any playbook? a) Isolate a device in Defender for Endpoint b) Disable a user in Entra ID c) Tag, assign an owner, change severity and close the incident d) Post a Microsoft Teams message Correct: c. Automation rules do the lightweight, in-Sentinel actions natively: tag, assign, change severity/status, close, add tasks. Cross-system actions like isolate, disable user or post to Teams require a playbook (Logic Apps connectors). 👉 So far: Automation rules = no-code orchestrator in Sentinel: trigger on incident created/updated, check conditions, run ordered actions (tag, assign, severity, close, tasks) and can call a playbook. Supports order and an expiry date. ## ③ 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. Figure 3 — One playbook, many connectors A Logic Apps playbook chains connector actions to act across your whole estate. One playbook, many connectors Playbook Logic Apps flow Teams notify ServiceNow ticket Entra disable user Defender isolate Block IP / firewall Enrich (TI lookup) A Logic Apps playbook chains connector actions to act across your whole estate. Figure 4 — The three playbook triggers Only the incident trigger can be called automatically by an automation rule. The three playbook triggers Incident trigger Whole incident + alerts + entities — auto-runs from a rule Alert trigger A single alert — run manually or on no-incident rules Entity trigger One user/IP/host — run manually during hunting Only the incident trigger can be called automatically by an automation rule. 'Automation rules can isolate a device' — no A common slip is thinking automation rules do everything. They only do in-Sentinel actions (tag, assign, severity, status, close, tasks). Anything that touches another system — isolate via Defender for Endpoint, disable an Entra user, open a ServiceNow ticket, post to Teams — needs a playbook with the right Logic Apps connector. Map each action to the right layer. ### ▶ Watch a compromised account get contained end-to-end How one incident drives an automatic response. Press Play for the healthy path, then Break it to see the classic failure. ① Incident A 'impossible travel' alert and a malware alert on the same user group into one High-severity incident. ▼ ② Auto rule An automation rule fires on incident-created, matches severity = High, assigns the owner and calls the response playbook. ▼ ③ Playbook acts The Logic Apps playbook enriches the IP, posts to the SOC Teams channel, disables the Entra user and isolates the device via Defender for Endpoint. ▼ ④ Closed loop The playbook comments back on the incident with what it did; the analyst confirms and sets the classification to True Positive. Press Play to step through the healthy auto-response. Then press Break it . ▶ Play Next ▶ ⚠ Break it ↺ Reset Quick check · Q3 of 10 · Apply You want a playbook to run automatically when an incident is created. Which trigger must it use? a) The entity trigger b) The alert trigger c) The incident trigger d) A scheduled timer trigger Correct: c. Only incident-triggered playbooks can be attached to an automation rule and run automatically. Alert- and entity-triggered playbooks are run manually on demand. 👉 So far: Playbooks = Azure Logic Apps workflows with incident, alert or entity triggers and connector actions (enrich, notify, disable, isolate). Only incident-triggered playbooks can be run automatically by a rule. ## ④ 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. Figure 5 — Design a safe auto-response Build the playbook, test it manually, then promote it to automatic via an automation rule. Design a safe auto-response Build Logic Apps actions Run manual human in the loop Watch runs Logic Apps history Attach rule incident trigger Automate fires on create Build the playbook, test it manually, then promote it to automatic via an automation rule. Rohit at a Pune fintech SOC faces this A 'suspicious sign-in' analytics rule starts firing dozens of incidents a night during a scheduled load test, and a new auto-response playbook is disabling real test accounts. Likely cause The playbook was attached to an automation rule with no condition scoping and no expiry, so it disables users for every matching incident — including planned test traffic. Diagnosis Open the incident queue and the Logic Apps run history — most disabled accounts are the load-test service accounts; the rule had no condition on severity or account type and ran straight to disable. Defender portal ▸ Microsoft Sentinel ▸ Configuration ▸ Automation ▸ Automation rules Fix Add conditions (exclude the test accounts, require High severity), set the playbook to notify Teams for approval instead of auto-disable, and add a time-limited suppression rule with an expiry to auto-close the load-test noise. Verify Re-run the load test: noisy incidents auto-close, no real accounts are disabled, and genuine suspicious sign-ins still raise an incident and ping the SOC channel. Prove it from the Logic Apps run history Never trust 'the playbook probably ran'. Every playbook run is logged in Azure Logic Apps with each action's input and output. Open the run, follow it action by action, and you can see exactly where it succeeded or failed (e.g. a missing Defender 'Machine.Isolate' permission) instead of guessing. Quick check · Q4 of 10 · Analyze What is the safest way to roll out a playbook that isolates a device? a) Set it to fully automatic on day one for all incidents b) Run it manually first, watch the run history, then promote trusted cases to automatic with a human gate on high-impact actions c) Never test it, just enable it d) Only ever run it by editing the Logic App code each time Correct: b. Isolate/disable are high-impact. Start manual (human in the loop), verify behaviour in the Logic Apps run history, then automate the low-risk steps while keeping a human approval gate before destructive actions. 👉 So far: Run playbooks manually first, then automate via an automation rule; keep a human gate before isolate/disable. In 2026 it all lives in the unified Defender portal (Azure portal retires 31 Mar 2027). ### 🤖 Ask the AI Tutor Tap any question — instant, scoped to this lesson. No login, no waiting. What is the difference between an automation rule and a playbook? How does an alert become a worked incident? What are the three playbook triggers and which can auto-run? What kinds of actions can a playbook take? How should I roll out an auto-response without causing damage? Where does Sentinel SOAR live in 2026? Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in. ## 📝 Wrap-up assessment — six more You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end. Q5 · Remember Which two trigger events can an automation rule fire on? a) Incident created or updated (and alert created) b) Workspace created or deleted c) Only on a schedule d) Only when a workbook is opened Correct: a. Automation rules trigger on an incident being created or updated, and can also trigger on alert creation. They are not timer-based; that confusion comes from Logic Apps' own scheduled triggers. Q6 · Understand Why does Microsoft recommend automating around incidents rather than raw alerts? a) Alerts cannot be queried b) Incidents are modifiable case files with status, owner, severity and the full evidence trail, so they are the right unit to track and act on c) Incidents are cheaper to store d) Alerts are always false positives Correct: b. An incident aggregates related alerts plus entities and comments into one modifiable case with status, owner and severity. That is the natural focal point for triage and automation, unlike a single immutable alert. Q7 · Apply You need to disable a compromised Microsoft Entra user as part of the response. What do you build? a) A playbook (Logic Apps) using the Entra ID connector, optionally called by an automation rule b) An automation rule action only c) A KQL analytics rule d) A workbook tile Correct: a. Disabling an Entra user is a cross-system action, so it needs a playbook with the Microsoft Entra ID connector. An automation rule can call that playbook, but the rule itself can't disable a user. Q8 · Analyze Two automation rules apply to the same incident. How is the outcome determined? a) Both run in parallel and conflicts are random b) They run sequentially by order number, and a later rule sees the incident as left by earlier rules c) Only the newest rule ever runs d) Order has no effect Correct: b. Automation rules run sequentially by their order number within a trigger type; a later rule evaluates conditions against the incident's state after earlier rules acted (e.g. a severity it already lowered). Create-trigger rules run before update-trigger rules. Q9 · Evaluate During a planned penetration test the SOC is flooded with known false incidents. Best Sentinel response? a) Delete the analytics rule permanently b) Disable the whole workspace c) Create a time-limited automation rule (with an expiration date) that auto-closes and tags those incidents, then expires on its own d) Ignore the incidents manually one by one Correct: c. A suppression automation rule with an expiration date auto-closes the planned noise and tags it, then disables itself when the test window ends — no need to remember to turn it off, and the real detection logic stays intact. Q10 · Evaluate What is the strongest design principle for a safe auto-response in a busy SOC? a) Automate every action including isolate and disable, with no human step b) Never automate anything c) Only automate during business hours d) Automate the repeatable low-false-positive steps (enrich, tag, ticket, notify) and keep a human gate before high-impact actions like isolate or disable Correct: d. Good SOAR augments analysts: automate the boring, reliable steps to cut alert fatigue, but require human approval before destructive, hard-to-reverse actions. Binary, low-variation use cases are the right candidates for full automation. Submit all answers Try again Lesson complete — saved to your profile. Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again". ### 🧠 In your own words Type one line: what is the difference between a Sentinel automation rule and a playbook? Then compare with the expert version. Compare with expert answer Expert version: An automation rule is the no-code orchestrator inside Microsoft Sentinel: it fires on an incident being created or updated, checks conditions, and runs ordered actions — tag, assign, change severity, close, add tasks — and it can call a playbook. A playbook is an Azure Logic Apps workflow that performs the real cross-system actions through connectors — enrich, notify Teams, open a ServiceNow ticket, disable an Entra user, isolate a device in Defender for Endpoint. Only incident-triggered playbooks can be run automatically by a rule; alert and entity playbooks are manual. Rule = traffic cop, playbook = the actions, and in 2026 it all runs in the unified Microsoft Defender portal. ### 🗣 Teach a friend Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary. Generate my one-liner 📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Microsoft Sentinel at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time. ### 📖 Glossary Incident A case file in Microsoft Sentinel that groups related alerts, entities, comments and tags. Carries a status, owner and severity. Alert A single piece of evidence raised by an analytics rule. Many alerts can be grouped into one incident. Status / owner / severity The triage fields on an incident: status (New/Active/Closed), the assigned analyst (owner), and severity (Informational/Low/Medium/High). Automation rule A no-code orchestrator in Sentinel that fires on incident created/updated, checks conditions, and runs ordered actions — tag, assign, change severity, close, add tasks, call a playbook. Playbook A response workflow built on Azure Logic Apps, triggered by an incident, alert or entity, that chains connector actions to enrich, notify, disable or isolate. Azure Logic Apps The cloud workflow service that playbooks are built on, providing a visual designer, a connector gallery and a per-action run history. Connector A pre-built Logic Apps integration to another system (Teams, ServiceNow, Entra ID, Defender for Endpoint) so a playbook can act without custom code. Trigger (playbook) What starts a playbook: the incident trigger (whole incident), the alert trigger, or the entity trigger. Only incident-triggered playbooks can auto-run from a rule. Automation rule order The sequence number that controls which automation rules run first; a later rule sees the incident as left by earlier rules. Unified Defender portal The single security.microsoft.com portal where Sentinel and Defender XDR share one incident queue; the Azure portal Sentinel experience retires 31 Mar 2027. #### 📚 Sources Microsoft Learn — Automation in Microsoft Sentinel: Security orchestration, automation, and response (SOAR) . learn.microsoft.com/azure/sentinel/automation/automation - Microsoft Learn — Automate threat response in Microsoft Sentinel with automation rules (triggers, conditions, order, expiration) . learn.microsoft.com/azure/sentinel/automate-incident-handling-with-automation-rules - Microsoft Learn — Automate threat response with playbooks in Microsoft Sentinel (Logic Apps, roles) . learn.microsoft.com/azure/sentinel/automation/automate-responses-with-playbooks - Microsoft Learn — Supported triggers and actions in Microsoft Sentinel playbooks (incident / alert / entity) . learn.microsoft.com/azure/sentinel/automation/playbook-triggers-actions - Microsoft Learn — Automate and run Microsoft Sentinel playbooks (manual vs automatic, Defender portal) . learn.microsoft.com/azure/sentinel/automation/run-playbooks - Microsoft Learn — Microsoft Sentinel in the Microsoft Defender portal & Defender XDR integration (unified incident queue, bi-directional sync) . learn.microsoft.com/azure/sentinel/microsoft-sentinel-defender-portal ### What's next? Got the response side? Next, go back to the start of the pipeline: how KQL and analytics rules turn raw logs into the alerts that became these incidents — scheduled queries, entity mapping and incident-creation settings. Next · All interview lessons → Practice on exam.techclick.in → --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt