Ansible splunk.es Collection: Automating Security Incident Response Workflows

Introduction

At Red Hat Tech Day Netherlands 2026, held on 3 June 2026 in Bunnik, the Ansible team unveiled twelve new content collections built for Red Hat Ansible Automation Platform (AAP) 2.7. The announcement grouped these collections under four themes — Efficiency, Resilience, Governance, and Scale — spanning cloud providers, network infrastructure, identity and secrets management, and IT operations. Among the security-focused additions, three collections target Splunk directly: splunk.enterprise for Universal Forwarder lifecycle automation, splunk.itsi for IT Service Intelligence paired with Event-Driven Ansible (EDA), and splunk.es, which is the subject of this guide.

The splunk.es collection brings Splunk Enterprise Security (ES) incident workflows and response plan automation directly into Ansible playbooks. For security operations (SecOps) teams already standardized on AAP for infrastructure and configuration automation, this collection closes a long-standing gap: it lets the same automation platform that patches servers and enforces compliance also drive the triage and remediation steps that follow a Splunk ES notable event.

See also: AAP MCP Security and Compliance Tool Set: Audit Trails via AI Agents

Why splunk.es Matters for Incident Response

Splunk Enterprise Security is widely deployed as a SIEM layer for correlation searches, risk-based alerting, and notable event management. Historically, turning a notable event into an actual remediation action required either manual analyst intervention or a separate SOAR (Security Orchestration, Automation, and Response) tool bolted on alongside Splunk. The splunk.es collection changes that equation by exposing Enterprise Security's incident review and response plan constructs as Ansible-native tasks.

This matters for three practical reasons:

• Consolidation of tooling. Teams that already run AAP for network, cloud, and endpoint automation can extend the same control plane into security incident response instead of maintaining a separate orchestration stack.
• Auditability and governance. Every automated response action executed as an Ansible playbook run is logged, versioned, and subject to AAP's role-based access control (RBAC) — an important governance property for security teams facing compliance audits.
• Closed-loop potential. When paired with Event-Driven Ansible, notable events in Splunk ES can trigger rulebooks that kick off splunk.es playbooks automatically, moving organizations closer to real closed-loop detection-to-remediation pipelines.

What the Collection Covers

Based on the Red Hat Tech Day Netherlands 2026 announcement, splunk.es is scoped around two core capability areas: Enterprise Security incident workflows and response plan automation. In practice, that means the collection is designed to let playbooks interact with the objects analysts already work with inside ES — notable events, incident review statuses, and the response plans (formerly known as adaptive response actions and workflow actions) that ES uses to drive remediation steps.

A representative, illustrative task set looks like this:

---
- name: Handle high-severity Splunk ES notable events
  hosts: localhost
  gather_facts: false
  vars:
    splunk_es_host: "splunk-es.example.internal"
    splunk_es_port: 8089
    notable_event_id: "{{ event_id }}"

  tasks:
    - name: Retrieve notable event details from Enterprise Security
      splunk.es.notable_event_info:
        server_uri: "https://{{ splunk_es_host }}:{{ splunk_es_port }}"
        validate_certs: false
        event_id: "{{ notable_event_id }}"
      register: notable_event

    - name: Update incident review status to In Progress
      splunk.es.incident_review:
        server_uri: "https://{{ splunk_es_host }}:{{ splunk_es_port }}"
        event_id: "{{ notable_event_id }}"
        status: "in_progress"
        owner: "soc-automation"
        comment: "Auto-assigned by AAP for triage playbook execution"

    - name: Trigger the response plan for compromised-credential events
      splunk.es.response_plan:
        server_uri: "https://{{ splunk_es_host }}:{{ splunk_es_port }}"
        event_id: "{{ notable_event_id }}"
        plan_name: "credential_compromise_response"
        state: executed

    - name: Close the notable event once remediation succeeds
      splunk.es.incident_review:
        server_uri: "https://{{ splunk_es_host }}:{{ splunk_es_port }}"
        event_id: "{{ notable_event_id }}"
        status: "closed"
        comment: "Remediated via automated response plan"
      when: notable_event.severity == "high"

The module and parameter names above are illustrative — they follow Splunk ES terminology (notable events, incident review, response plans) and standard Ansible collection conventions, since Red Hat has announced the collection's scope but has not yet published its full module reference. Treat this pattern as a starting template to adapt once the formal documentation ships with AAP 2.7.

How splunk.es Fits Alongside the Other Splunk Collections

Red Hat's Tech Day announcement grouped three Splunk-related collections together, and understanding how they divide responsibility helps teams plan adoption.

See also: Agent Identity and Guardrails: Securing OpenClaw Access to Ansible Automation Platform

Getting Ready for splunk.es in AAP 2.7

Since splunk.es was announced alongside AAP 2.7 rather than shipped as a standalone community release, teams should plan their adoption path now:

1. Confirm Enterprise Security version compatibility with your Splunk deployment before scheduling an upgrade window.
2. Inventory existing notable event workflows — the response plans and correlation searches your SOC already relies on — so you know which ones are candidates for automation first.
3. Plan credential handling for the collection's Splunk API connections; pairing it with the hashicorp.vault collection (also announced at the same event) is a natural fit for dynamic, short-lived credentials rather than static API tokens.
4. Evaluate Event-Driven Ansible integration as a follow-on step once basic playbook-driven response plans are validated, to move from on-demand execution to automatic triggering.

Key Takeaways

• splunk.es is one of twelve new collections announced for AAP 2.7 at Red Hat Tech Day Netherlands 2026 (3 June 2026, Bunnik), focused on Splunk Enterprise Security incident workflows and response plan automation.
• It complements splunk.enterprise (forwarder lifecycle) and splunk.itsi (IT Service Intelligence with EDA), together covering the full data-to-detection-to-remediation chain.
• Typical automation targets include notable event retrieval, incident review status updates, and triggering or closing response plans — all executable as auditable, RBAC-governed AAP job templates.
• Pairing splunk.es with hashicorp.vault and Event-Driven Ansible points toward a genuinely closed-loop security automation pipeline.
• Full module documentation should be validated against the official Ansible Automation Platform 2.7 release notes once generally available, since exact parameter names may differ from the illustrative examples above.