Automate threat response with playbooks in Azure Sentinel

This article explains what Azure Sentinel playbooks are, and how to use them to implement your Security Orchestration, Automation and Response (SOAR) operations, achieving better results while saving time and resources.

What is a playbook?

SIEM/SOC teams are typically inundated with security alerts and incidents on a regular basis, at volumes so large that available personnel are overwhelmed. This results all too often in situations where many alerts are ignored and many incidents aren't investigated, leaving the organization vulnerable to attacks that go unnoticed.

Many, if not most, of these alerts and incidents conform to recurring patterns that can be addressed by specific and defined sets of remediation actions.

A playbook is a collection of these remediation actions that can be run from Azure Sentinel as a routine. A playbook can help automate and orchestrate your threat response; it can be run manually or set to run automatically in response to specific alerts or incidents, when triggered by an analytics rule or an automation rule, respectively.

For example, if an account and machine are compromised, a playbook can isolate the machine from the network and block the account by the time the SOC team is notified of the incident.

Playbooks are created and applied at the subscription level, but the Playbooks tab (in the new Automation blade) displays all the playbooks available across any selected subscriptions.

Azure Logic Apps basic concepts

Playbooks in Azure Sentinel are based on workflows built in Azure Logic Apps, a cloud service that helps you schedule, automate, and orchestrate tasks and workflows across systems throughout the enterprise. This means that playbooks can take advantage of all the power and customizability of Logic Apps' built-in templates.


Because Azure Logic Apps are a separate resource, additional charges may apply. Visit the Azure Logic Apps pricing page for more details.

Azure Logic Apps communicates with other systems and services using connectors. The following is a brief explanation of connectors and some of their important attributes:

  • Managed Connector: A set of actions and triggers that wrap around API calls to a particular product or service. Azure Logic Apps offers hundreds of connectors to communicate with both Microsoft and non-Microsoft services.

  • Custom connector: You may want to communicate with services that aren't available as prebuilt connectors. Custom connectors address this need by allowing you to create (and even share) a connector and define its own triggers and actions.

  • Azure Sentinel Connector: To create playbooks that interact with Azure Sentinel, use the Azure Sentinel connector.

  • Trigger: A connector component that starts a playbook. It defines the schema that the playbook expects to receive when triggered. The Azure Sentinel connector currently has two triggers:

    • Alert trigger: the playbook receives the alert as its input.

    • Incident trigger: the playbook receives the incident as its input, along with all its included alerts and entities.


      • The incident trigger feature for playbooks is currently in PREVIEW. See the Supplemental Terms of Use for Microsoft Azure Previews for additional legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability.
  • Actions: Actions are all the steps that happen after the trigger. They can be arranged sequentially, in parallel, or in a matrix of complex conditions.

  • Dynamic fields: Temporary fields, determined by the output schema of triggers and actions and populated by their actual output, that can be used in the actions that follow.

Permissions required

To give your SecOps team the ability to use Logic Apps for Security Orchestration, Automation, and Response (SOAR) operations - that is, to create and run playbooks - in Azure Sentinel, you can assign Azure roles, either to specific members of your security operations team or to the whole team. The following describes the different available roles, and the tasks for which they should be assigned:

Azure roles for Logic Apps

  • Logic App Contributor lets you manage logic apps and run playbooks, but you can't change access to them (for that you need the Owner role).
  • Logic App Operator lets you read, enable, and disable logic apps, but you can't edit or update them.

Azure roles for Sentinel

  • Azure Sentinel Contributor role lets you attach a playbook to an analytics rule.
  • Azure Sentinel Responder role lets you run a playbook manually.
  • Azure Sentinel Automation Contributor allows automation rules to run playbooks. It is not used for any other purpose.

Learn more

Steps for creating a playbook

Use cases for playbooks

The Azure Logic Apps platform offers hundreds of actions and triggers, so almost any automation scenario can be created. Azure Sentinel recommends starting with the following SOC scenarios:


Collect data and attach it to the incident in order to make smarter decisions.

For example:

An Azure Sentinel incident was created from an alert by an analytics rule that generates IP address entities.

The incident triggers an automation rule which runs a playbook with the following steps:

  • Start when a new Azure Sentinel incident is created. The entities represented in the incident are stored in the incident trigger's dynamic fields.

  • For each IP address, query an external Threat Intelligence provider, such as Virus Total, to retrieve more data.

  • Add the returned data and insights as comments of the incident.

Bi-directional sync

Playbooks can be used to sync your Azure Sentinel incidents with other ticketing systems.

For example:

Create an automation rule for all incident creation, and attach a playbook that opens a ticket in ServiceNow:


Use the SOC chat platform to better control the incidents queue.

For example:

An Azure Sentinel incident was created from an alert by an analytics rule that generates username and IP address entities.

The incident triggers an automation rule which runs a playbook with the following steps:

  • Start when a new Azure Sentinel incident is created.

  • Send a message to your security operations channel in Microsoft Teams or Slack to make sure your security analysts are aware of the incident.

  • Send all the information in the alert by email to your senior network admin and security admin. The email message will include Block and Ignore user option buttons.

  • Wait until a response is received from the admins, then continue to run.

  • If the admins have chosen Block, send a command to the firewall to block the IP address in the alert, and another to Azure AD to disable the user.


Immediately respond to threats, with minimal human dependencies.

Two examples:

Example 1: Respond to an analytics rule that indicates a compromised user, as discovered by Azure AD Identity Protection:

  • Start when a new Azure Sentinel incident is created.

  • For each user entity in the incident suspected as compromised:

    • Send a Teams message to the user, requesting confirmation that the user took the suspicious action.

    • Check with Azure AD Identity Protection to confirm the user's status as compromised. Azure AD Identity Protection will label the user as risky, and apply any enforcement policy already configured - for example, to require the user to use MFA when next signing in.


      The playbook does not initiate any enforcement action on the user, nor does it initiate any configuration of enforcement policy. It only tells Azure AD Identity Protection to apply any already defined policies as appropriate. Any enforcement depends entirely on the appropriate policies being defined in Azure AD Identity Protection.

Example 2: Respond to an analytics rule that indicates a compromised machine, as discovered by Microsoft Defender for Endpoint:

How to run a playbook

Playbooks can be run either manually or automatically.

Running them manually means that when you get an alert, you can choose to run a playbook on-demand as a response to the selected alert. Currently this feature is supported only for alerts, not for incidents.

Running them automatically means to set them as an automated response in an analytics rule (for alerts), or as an action in an automation rule (for incidents). Learn more about automation rules.

Set an automated response

Security operations teams can significantly reduce their workload by fully automating the routine responses to recurring types of incidents and alerts, allowing you to concentrate more on unique incidents and alerts, analyzing patterns, threat hunting, and more.

Setting automated response means that every time an analytics rule is triggered, in addition to creating an alert, the rule will run a playbook, which will receive as an input the alert created by the rule.

If the alert creates an incident, the incident will trigger an automation rule which may in turn run a playbook, which will receive as an input the incident created by the alert.

Alert creation automated response

For playbooks that are triggered by alert creation and receive alerts as their inputs (their first step is “When an Azure Sentinel Alert is triggered”), attach the playbook to an analytics rule:

  1. Edit the analytics rule that generates the alert you want to define an automated response for.

  2. Under Alert automation in the Automated response tab, select the playbook or playbooks that this analytics rule will trigger when an alert is created.

Incident creation automated response

For playbooks that are triggered by incident creation and receive incidents as their inputs (their first step is “When an Azure Sentinel Incident is triggered”), create an automation rule and define a Run playbook action in it. This can be done in 2 ways:

  • Edit the analytics rule that generates the incident you want to define an automated response for. Under Incident automation in the Automated response tab, create an automation rule. This will create a automated response only for this analytics rule.

  • From the Automation rules tab in the Automation blade, create a new automation rule and specify the appropriate conditions and desired actions. This automation rule will be applied to any analytics rule that fulfills the specified conditions.


    Azure Sentinel automation rules require permissions to run playbooks.

    To run a playbook from an automation rule, Azure Sentinel uses a service account specifically authorized to do so. The use of this account (as opposed to your user account) increases the security level of the service and enables the automation rules API to support CI/CD use cases.

    This account must be granted explicit permissions (taking the form of the Azure Sentinel Automation Contributor role) on the resource group where the playbook resides. At that point, any automation rule will be able to run any playbook in that resource group.

    When you add the run playbook action to an automation rule, a drop-down list of playbooks will appear for your selection. Playbooks to which Azure Sentinel does not have permissions will show as unavailable ("grayed out"). You can grant permission to Azure Sentinel on the spot by selecting the Manage playbook permissions link.

    In a multi-tenant (Lighthouse) scenario, you must define the permissions on the tenant where the playbook lives, even if the automation rule calling the playbook is in a different tenant. To do that, you must have Owner permissions on the playbook's resource group.

    There's a unique scenario facing a Managed Security Service Provider (MSSP), where a service provider, while signed into its own tenant, creates an automation rule on a customer's workspace using Azure Lighthouse. This automation rule then calls a playbook belonging to the customer's tenant. In this case, Azure Sentinel must be granted permissions on both tenants. In the customer tenant, you grant them in the Manage playbook permissions panel, just like in the regular multi-tenant scenario. To grant the relevant permissions in the service provider tenant, you need to add an additional Azure Lighthouse delegation that grants access rights to the Azure Security Insights app, with the Azure Sentinel Automation Contributor role, on the resource group where the playbook resides. Learn how to add this delegation.

See the complete instructions for creating automation rules.

Run a playbook manually on an alert

Manual triggering is available from the Azure Sentinel portal in the following blades:

  • In Incidents view, choose a specific incident, open its Alerts tab, and choose an alert.

  • In Investigation, choose a specific alert.

  1. Click on View playbooks for the chosen alert. You will get a list of all playbooks that start with an When an Azure Sentinel Alert is triggered and that you have access to.

  2. Click on Run on the line of a specific playbook to trigger it.

  3. Select the Runs tab to view a list of all the times any playbook has been run on this alert. It might take a few seconds for any just-completed run to appear in this list.

  4. Clicking on a specific run will open the full run log in Logic Apps.

Run a playbook manually on an incident

Not supported yet.

Manage your playbooks

In the Playbooks tab, there appears a list of all the playbooks which you have access to, filtered by the subscriptions which are currently displayed in Azure. The subscriptions filter is available from the Directory + subscription menu in the global page header.

Clicking on a playbook name directs you to the playbook's main page in Logic Apps. The Status column indicates if it is enabled or disabled.

Trigger kind represents the Logic Apps trigger that starts this playbook.

Trigger kind Indicates component types in playbook
Azure Sentinel Incident/Alert The playbook is started with one of the Sentinel triggers (alert, incident)
Using Azure Sentinel Action The playbook is started with a non-Sentinel trigger but uses an Azure Sentinel action
Other The playbook does not include any Sentinel components
Not initialized The playbook has been created, but contains no components (triggers or actions).

In the playbook's Logic App page, you can see more information about the playbook, including a log of all the times it has run, and the result (success or failure, and other details). You can also enter the Logic Apps Designer and edit the playbook directly, if you have the appropriate permissions.

API connections

API connections are used to connect Logic Apps to other services. Every time a new authentication to a Logic Apps connector is made, a new resource of type API connection is created, and contains the information provided when configuring access to the service.

To see all the API connections, enter API connections in the header search box of the Azure portal. Note the columns of interest:

  • Display name - the "friendly" name you give to the connection every time you create one.
  • Status - indicates the connection status: error, connected.
  • Resource group - API connections are created in the resource group of the playbook (Logic Apps) resource.

Another way to view API connections would be to go to the All Resources blade and filter it by type API connection. This way allows the selection, tagging, and deletion of multiple connections at once.

In order to change the authorization of an existing connection, enter the connection resource, and select Edit API connection.

The following recommended playbooks, and other similar playbooks are available to you in the Azure Sentinel GitHub repository:

Next steps