You automate containment in Microsoft Sentinel with automation rules that run playbooks when an incident or alert matches conditions you set. A playbook is an Azure Logic Apps workflow that can take actions such as isolating a device or blocking an account. The harder part is deciding, before any incident, which threats are allowed to trigger those actions without waiting for a person.
Before you automate
- Automation rules decide when. They act on incidents and alerts that match your conditions, and they can start a playbook.
- Playbooks decide what. They enrich incidents, notify people, open tickets and take response actions.
- Approval comes first. Automatic containment works once your organization has agreed which threat types allow it.
- Testing keeps it working. A playbook that has not been checked recently may fail when an incident needs it.
On this page
How do automation rules and playbooks work together?
Microsoft describes playbooks as automated workflows that help you respond to threats quickly and consistently. A playbook can run automatically when an automation rule fires on a matching alert or incident, or an analyst can run it manually on a specific entity or alert.
Microsoft gives the example of a compromised account and machine, where a playbook isolates the machine from the network and blocks the account before the SOC team is notified. Because playbooks run on Azure Logic Apps, additional charges can apply, and automation rules need the Microsoft Sentinel Automation Contributor role on the playbook’s resource group before they can run it.
Source: Automate threat response with playbooks in Microsoft Sentinel, Microsoft Learn. Microsoft also states that after March 31, 2027, Microsoft Sentinel will be available only in the Microsoft Defender portal.
What should run automatically, and what should wait for a person?
Actions that change nothing in your environment are safe to automate first. Actions that disconnect people or systems need an agreement in advance about when they may run on their own.
| Response action | Run automatically when | Keep a person in the decision when |
|---|---|---|
| Enrich the incident with user and device details | Always, because it only adds context | Not needed |
| Notify the owner or open a ticket | Always, so the owner hears about it right away | Not needed |
| Revoke sessions or block an IP address | The detection is high confidence and the threat type is pre-approved | The account or address is on an exclusion list your team keeps |
| Isolate a device or disable an account | The asset is confirmed compromised and the threat type is pre-approved | The asset supports a service that needs a planned response |
The agreement is the step that removes waiting. Our post The Alert Fired. The Team Froze. explains how approvals and unclear ownership slow a response.
What does Microsoft Defender XDR contain on its own?
Defender XDR includes automatic attack disruption. While an attack is in progress, Defender contains compromised assets the attacker is using, with actions such as containing or isolating a device and disabling a user account. Microsoft states that every automatic action can be undone by your security team, and you can exclude critical assets.
Sentinel playbooks extend automation to the steps your own environment needs, such as updating a firewall blocklist, opening a ticket in your service desk or posting to a Teams channel. The two work together, and your team decides which tool owns which action.
Source: Automatic attack disruption in Microsoft Defender XDR, Microsoft Learn.
How do you build containment automation step by step?
- Choose the threats that justify automatic action. Agree with security and business owners which confirmed threats allow immediate containment, and list the assets that need a person to decide.
- Start with enrichment and notification. Build playbooks that add context to incidents and alert the right owner, since they change nothing in your environment.
- Build the containment playbook. Create the Logic Apps workflow for the action, such as isolating a device or blocking an account, and grant only the permissions it needs.
- Attach it with an automation rule. Create an automation rule with conditions that match the approved threat types so the playbook runs when a matching incident is created.
- Test it and retest after changes. Run the playbook against test incidents and check it again whenever permissions or connectors change.
For a worked example, our post on automating identity threat response describes open-source playbooks that block IP addresses from a Sentinel incident and revoke the user’s sessions when a sign-in succeeded. A companion playbook removes the blocks later so blocklists stay clean. The playbooks are published in the Accelerynt GitHub library.
Why does containment automation need testing?
A playbook that ran last spring proves only that it ran last spring. Permissions expire and connectors change, so automation can stop working without anyone noticing until an incident depends on it.
We treat a working playbook as something to prove again whenever the thing underneath it changes. Our post Security Leaders: How Do You Measure Readiness? explains why a proof has to be able to fail and why it expires. For checking the rest of your controls the same way, read what continuous control validation is.
What does this mean when you choose an MDR provider?
When buyers ask which MDR providers respond the fastest, much of the answer depends on what the provider is allowed to do without asking. A provider that has agreed containment authority with you, and has tested the automation that carries it out, can act as soon as a matching threat is confirmed.
- Agreed protocols. In Accelerynt MDR, your team and ours define how we respond to specific threat types before an incident, so containment runs inside your tenant without approval delays.
- Playbooks in your workspace. We build Sentinel and Defender playbooks for host isolation and account lockdown inside your tenant, and we test them regularly to verify they work.
- Published commitments. Detection within 30 minutes is a published commitment, and containment time commitments apply once response protocols are approved, as the MDR stages page explains.
- Yours to keep. Detection rules and playbooks live in your Sentinel workspace and stay with you.
For the criteria to compare across providers, read how to choose MDR for a Microsoft environment.
For why waiting on approvals slows a response, read why incident response stalls after the alert fires.
Frequently asked questions
How do you automate incident response in Microsoft Sentinel?
Create playbooks in Azure Logic Apps for the actions you want, then create automation rules that run those playbooks when an incident or alert matches your conditions. Start with enrichment and notification, then add containment for threat types your organization has approved.
What is the difference between an automation rule and a playbook?
An automation rule decides when something happens, based on conditions such as the analytics rule or severity of an incident. A playbook is the workflow that runs, such as isolating a device or opening a ticket.
Which MDR providers respond the fastest?
Speed depends on whether the provider may contain threats without waiting for your approval. Look for a provider that agrees response protocols with you in advance, runs tested playbooks inside your environment and publishes its detection and containment commitments. Accelerynt MDR works this way inside your Microsoft tenant.
Who reviews an incident after automatic containment?
Your team or your provider still investigates the incident after automation contains it. Automatic containment buys time, and the investigation decides what happened and when to restore access.