Playbooks

Overview

Playbooks connect a supported product event to a response: they apply the conditions you select, then perform the action shown in the editor. They live in the relevant Security or Awareness module and reuse the existing issue, training and communication workflows.

The available triggers, conditions, and actions depend on the module, connected source, and source capabilities. Treat the options displayed in the playbook editor as the source of truth for your organization.

Open Playbooks

Sign in to the EU admin portal or US admin portal, then open Security, choose a module, and select Playbooks.

For a phishing simulation, open Awareness → Phishing → Playbooks instead.

Playbooks currently appear under:

• Data Protection
• Third-Party Apps
• Authentication
• Browser Security
• Phishing in Awareness, when Phishing is available to your organization

There is no separate global Playbooks page. Each module owns its available starter templates and configured workflows.

How a playbook works

Trigger

The trigger identifies the product event the workflow evaluates. Current trigger families include:

• Credentials entered on the page of a phishing simulation
• An externally shared object in Data Protection
• A detected third-party application, CVE, or data breach in Third-Party Apps
• An account using the wrong authentication method in Authentication
• Supported browser findings, such as sensitive input, sensitive file upload, potential data exfiltration, or access to an unauthorized application

The selected source can change which triggers are available.

Conditions

Conditions narrow the workflow to the relevant findings. Depending on the trigger and source, the editor can offer conditions based on members, groups, issue dates, data-sharing or content attributes, application attributes, or browser-finding details.

Some conditions are evaluated when a finding is created; date-based conditions can be evaluated later. A workflow only acts when its configured conditions match.

Action

The editor only offers actions supported for the selected trigger and source. Current action types include:

• Distribute issue to make a supported issue available to the affected employee
• Assign a training to connect a supported detection to an existing lesson for the person involved
• Notify admins using the configured organization or per-user communication channel; the workflow can target selected administrators where that option is available
• Remediate issue for a source-supported permission or account action
• Block browser action for supported sensitive-input or file-upload findings
• Block page access for supported unauthorized-application findings

Some issue-distribution workflows can add remediation after a configurable waiting period. Review the exact period and source-changing action in the editor before activation.

Assign a training after a detection

Use Assign a training where the selected trigger offers it. Choose an existing library or custom lesson and a due period of 1 to 365 days; the default is 14 days. Starter templates connect phishing credential submissions, supported external file sharing, Google application access and browser findings to a relevant lesson. Review the proposed lesson and conditions before activation.

• A coaching playbook has one action. Keep issue distribution, remediation or browser blocking in a separate playbook if you need both responses.
• Only new matching detections after activation, resumption or a change to the training action can assign the lesson. Existing findings are not replayed. The first scan of a source connected later counts as new detections, so start with a narrow scope.
• The person must be eligible for training. elba skips a lesson the person has already received (pending, started or completed), and assigns at most one playbook training per person in your organization within seven days, across playbooks.
• A lesson their program only schedules for a later date is not skipped: it is brought forward. The person receives it now, with the playbook's due period, and their program does not schedule it again. Their other scheduled lessons do not move at that moment; the next time their program is recalculated, the lessons that followed it come one period earlier. See Training.
• A playbook assignment uses the existing employee training experience, due dates and completion tracking. It does not reset the recurring program or add the lesson to its sequence. Employees can access their assigned training even when no recurring program is active.
• The training notice gives the lesson, due date and a link. It does not copy file names, application names, prompts or other sensitive detection details into the message.

Review assigned and skipped results in the module's playbook action history where available. An assignment or queued notification is not proof that the employee received or completed the lesson. See Training for the employee and reporting journey.

Behavior by module

Phishing

Open Awareness → Phishing → Playbooks as an organization owner or admin. The starter template Train people who enter their credentials in a phishing simulation uses the trigger Credentials entered in a phishing simulation, the existing lesson Phishing refresher: fake login pages, and a 14-day deadline. Review or change the lesson and deadline before activation. You can limit the audience by Member or Group.

The trigger follows a credential submission, rather than an email open or a link click. Choose one action:

• Assign a training adds the selected lesson to the person's existing Training page under the eligibility, already-covered and seven-day limits described above. The message explains why it was assigned, and follows the person's configured Slack, Microsoft Teams, Google Chat or email channel and language.
• Notify admins tells all or selected admins that the person entered their credentials in a simulation, through their configured communication channels. This action does not assign a lesson. To do both, configure two playbooks with the same trigger.

Nothing runs while the playbook is a draft. Once active, it follows matching submissions; earlier submissions are not replayed as training assignments. There is currently no test-campaign exclusion: submitting credentials in a simulation you use for testing can also trigger an active playbook.

What the employee sees

After submitting, the simulation's result page checks what followed. It links to the lesson only when the assignment is confirmed. It can also explain that the person already has the lesson, that the seven-day limit applies, that the selected lesson is unavailable, or that the assignment failed. While the result is pending, it checks for up to one minute before saying it is taking longer. If no playbook applies or the page cannot verify the simulation reference, the usual result page remains.

The reference comes from the simulation link, so a forwarded link can be treated as the original recipient. An automated tool that submits the form and is not recognized as a scanner can also count as a failure. A result-page confirmation proves an assignment, not message delivery or lesson completion.

Review the playbook's action history under Phishing → Playbooks, then follow the existing Training reporting journey for completion.

Data Protection

Data Protection playbooks evaluate detected external-sharing issues. They can distribute matching issues to employees and, for sources that expose the required capability, add a remediation action. Conditions can cover sharing, content, risk, age, format, tags, members, groups, and issue state when those fields are available for the selected source.

For Google Drive, a playbook cannot remove sharing inherited from a parent folder on the file itself. That issue stays open; review the source folder in Google Drive. For direct permissions, Elba checks the removal outcome and reopens an issue when access remains or the result cannot be confirmed.

See Data Protection for issue investigation, previous-removal limits, and employee remediation behavior.

Third-Party Apps

Third-Party Apps playbooks can distribute supported application issues. If CVE or data-breach monitoring is temporarily unavailable, the activation or resume action explains it. You can still view or pause an existing playbook and edit unrelated settings.

See Review CVEs and data breaches for vulnerability and incident records. Application, publisher, reputation, permission, compliance, hosting, AI, member, group, and issue conditions are available only where the selected trigger supports them.

See Third-Party Apps for the inventory and issue workflow.

Authentication

Authentication playbooks can distribute supported wrong-authentication-method issues. The configured workflow and connected identity source determine which accounts are evaluated and what employee action is available.

See Identity and access reviews for related account-review workflows.

Browser Security

Browser Security playbooks work with findings reported by an enrolled browser extension and a connected browser source. Depending on the trigger, a workflow can block a supported browser action or page, or notify administrators. Member, group, AI-tool, and exfiltration-severity conditions are available for the relevant browser triggers.

The browser extension caches the active blocking workflows for the signed-in user. A newly activated or edited workflow can therefore take effect after the extension refreshes its configuration rather than at the exact moment the admin saves it.

See Browser extension capabilities for the supported controls and prerequisites.

Create or update a playbook

1. Open the relevant module's Playbooks tab.
2. Choose a starter template, or open an existing workflow.
3. Review the trigger and, where required, select the connected source.
4. Add only the conditions needed for the intended scope.
5. Review the action, recipients, and any waiting period shown in the editor.
6. Save the workflow as a draft or activate it.
7. Return to the module's Playbooks list to review its status, then use the module's issue or action history where available.

Configured workflows can be Draft, Active, or Paused. A source connection error is also surfaced in the Playbooks list because it can prevent the workflow from completing source-dependent work.

For Browser Security, saving or activating a playbook refreshes the list and template library. If your organization already has a playbook linked to a starter template, selecting that template opens the existing playbook instead of creating another copy. Older duplicate workflows may still appear in the list; remove only the copies you no longer need.

Remove an unwanted Browser playbook

Organization owners and administrators can delete a draft or paused playbook in their organization. An active playbook must be paused first.

1. Open Security → Browser security → Playbooks.
2. Select the unwanted playbook to open its details panel.
3. If it is active, select Pause, then Pause playbook to confirm. Wait until its status is Paused.
4. Select Delete, review the warning in the confirmation dialog, then select Delete to confirm.
5. Check that the playbook no longer appears in the list.

Deletion permanently removes the playbook. It does not undo actions the playbook already performed. If an error appears, reload the list and check the playbook's current state before retrying; do not assume it was removed.

Safe rollout

1. Review representative findings before creating an automation.
2. Start with a narrow member, group, source, or risk scope.
3. Confirm notification recipients and employee communication settings.
4. Test source-changing or blocking behavior with a controlled group.
5. Review the workflow activity and affected issues before expanding its scope.
6. Pause the workflow if the connected source changes or results differ from the intended policy.

Detection, notification delivery, and source remediation depend on connected services and their current health. For an urgent incident, verify the result in the source system instead of relying on a playbook as the only response control.