How Sentinel responds: automation rules, playbooks, and the human gate

People list automation-and-playbooks as one feature. They're two mechanisms doing two different jobs, and keeping them apart is the whole lesson. One decides when and in what order things happen; the other does the actual work — and only one of them can reach outside Sentinel to touch the world.

Mental model

An automation rule is a reflex — the involuntary flinch when something touches the incident. It's fast, lives inside you, and doesn't reach for anything; it just decides this matters, in this order, do that. A playbook is the muscle that actually moves — it reaches out, picks something up, acts on the world. A reflex with no muscle can only twitch; muscle with no reflex just sits there until you move it by hand. Response is the two wired together.

Reflex, then muscle. The automation rule never leaves Sentinel — it triages the incident and decides what runs. The playbook is the only thing here that crosses the boundary to act on Entra, Defender, or your ticketing system. Wire them together and the incident triggers action; leave either out and nothing moves on its own.

01Automation rules vs playbooks

One manages the incident; the other reaches out and does. Sort every "can Sentinel do X automatically?" question onto the right side of this line.

Aspect	Automation rule	Playbook (Logic App)
Runs where	Inside Sentinel	Azure Logic Apps
Reach	Manages the incident — tag, severity, owner, status, close, suppress	Reaches out — Entra, Defender, Teams, ITSM, any API
Style	No-code; conditions and ordering	Low-code workflow of connector actions
Triggered by	Incident/alert create or update	Called by an automation rule — or run by hand
Typical job	Triage, routing, suppression, ordering	Enrichment and remediation — the actual doing

So the relationship is simple to state and easy to forget: automation rules decide when and in what order; playbooks do the doing. An automation rule with no playbook can tag and triage but never touches anything outside; a playbook with no automation rule just sits there until a human runs it. The chain is: incident fires → automation rule catches it → runs a playbook → playbook acts.

02The highest-leverage automation nobody brags about

Before you automate a single remediation, automate this — it pays back every day and can't hurt anyone.

The moment an incident fires, a playbook can run your standard first-ten-minutes investigation — recent sign-ins for the user, what else that IP touched, the device's recent process events — and paste the results straight into the incident as a comment before a human ever opens it. When the analyst picks it up, the enrichment is already sitting there. This is the single highest-leverage automation in a SOC, because it collapses the opening of every investigation to zero, and it's completely safe: reading and summarising changes nothing in the world.

Enrich first, always. This is the automation to build on day one. It never touches a user or a device — it just does the reading a human would have done, so the human starts from a briefing instead of a blank incident.

03Remediation — and the blast radius

The consequential actions are all playbooks, and this is where "automate everything" quietly becomes a self-inflicted outage.

Blocking or disabling a user, isolating a device, marking an account compromised — every one of these is a playbook, because every one reaches into another product (Entra, Defender) to change the world. And every one is consequential and hard to reverse in the moment. Auto-disabling a user on a rule that occasionally false-positives means you've built a machine that locks out a real employee at 3 a.m. and calls it security. The consequences of an automated action scale with how wrong the triggering rule can be.

The gate is the whole discipline. Enrichment is reversible, so automate it freely. Remediation is consequential, so put a human on the trigger — a playbook can post "Isolate this device? Approve / Reject" to Teams and wait. Automate the reflex you'd never regret; gate the ones you might.

Automate the reversible; gate the irreversible

The mature pattern isn't "automate everything," it's a split: enrichment runs fully unattended because it can't do harm, and remediation waits behind a human approval step because it can. The question to ask of any candidate for full automation is brutally simple — if this fires on a false positive, what breaks, and can I undo it before Monday? If the answer is "a real user's access" and "not easily," it belongs behind the gate.

The one-line model

Automation rules are the reflex, playbooks are the muscle — and the skill is knowing which actions you trust the reflex to take alone. Enrich on everything; remediate with a human on the trigger.

04Where the series goes from here

That closes the platform loop: in three posts we've gone from an empty subscription to data that's sorted and priced (Part 1), to detection that turns tables into incidents (Part 2), to response that turns incidents into action (this one). The whole thing — connectors, DCRs, tiers, rules, alerts, incidents, automation — is one pipeline, and every piece is a trade between coverage, speed, and cost.

From here the series turns to the sources that feed this pipeline, each of which plugs into exactly the architecture we've drawn:

Defender XDR — the endpoint, identity, and cloud-app detections that arrive as alerts and land in the lake.
Defender for Cloud Apps (MDCA) — sanctioning and governing the SaaS estate.
Email & Collaboration (Defender for Office 365) — the largest attack surface most orgs have, and how its signal flows back into everything here.

Sources & further reading

Automate incident handling with automation rulesconditions, ordering, and actions inside Sentinel
Automate threat response with playbooksLogic Apps, triggers, and connector actions
Respond to threats using playbooksa worked automatic + interactive response

How Sentinel responds: the reflex and the muscle