SOAR and Incident Response Automation: Playbooks in Action

1. Introduction

SOAR incident response automation is the natural evolution of any security operations center that has outgrown email alerts and Excel spreadsheets. When a SOC matures, the alert volume grows faster than the team that must analyze it, which is where automation stops being a luxury and becomes an operational necessity. This article explains what lies behind SOAR incident response automation, with real examples you can adapt to your own environment.

I will assume you already know what a SIEM is and how a basic SOC works: if you need to refresh that foundation, the end of this article points you to practical material. Here we focus on the orchestration layer of SOAR incident response automation: how to turn an alert into a reproducible response, how to write playbooks that do not depend on whoever is on duty, and how to measure whether the whole machinery is actually delivering value.

2. SOAR incident response automation: what it is and why it matters

SOAR (Security Orchestration, Automation and Response) is a platform that connects detection, analysis and response tools to run automated workflows during incidents. Orchestration alone does not reduce risk; only repeatable, tested automated response does. SOAR incident response automation rests on three pillars: orchestration (connecting disparate tools), automation (running tasks without human intervention) and response (applying containment and remediation actions in a structured way).

The figure that convinces any manager is the meantime to respond (MTTR). A manual SOC takes hours or days to classify an alert, correlate context, locate the affected host and block the vector. With a well-designed orchestration layer, the same cycle shrinks to minutes. This is not about replacing the analyst, but about removing repetitive work so that their time goes to the cases that require judgment: that is the philosophy behind SOAR incident response automation.

An everyday example: a phishing alert reaches the SIEM. The SOAR platform extracts the artifacts (URL, sender, subject), checks reputation against VirusTotal, blocks the link in the corporate filter and opens a case with all the collected evidence. What used to consume forty minutes of an expert analyst’s time now takes three, and it always executes the same way, without errors caused by fatigue or rush. That kind of consistency is the most visible value of SOAR incident response automation.

3. Playbooks and runbooks: the heart of automation

The playbook is the heart of SOAR incident response automation: a structured document that defines, step by step, what to do for a specific type of incident. The runbook is the executable version of that document, one that the platform can interpret and run. The difference matters: you first write the playbook in human language and then translate it into a machine-readable format such as YAML or JSON.

A good playbook defines the trigger (which alert activates it), the input conditions (who can execute it), the analysis steps and the response actions with their approval criteria. It must also define what to do when something fails: mature SOAR incident response automation automates not only the happy path, but also the error path, something many implementations overlook until the first real incident hits. A playbook without a failure path produces follow-up tickets automatically, so design the error flow first.

3.1 Playbook anatomy for SOAR incident response automation

For a SOAR incident response automation platform to remain understandable and maintainable, the playbook must clearly separate analysis from containment. The minimum structure is: trigger (what fires the flow), enrichment (what context is gathered), decision (which criterion selects the next step) and action (what gets executed and against which system). With that template, any analyst can read someone else’s playbook and grasp it in five minutes.

4. Reference architecture with TheHive, Cortex and Splunk SOAR

Although there are many commercial solutions, the open architecture based on TheHive (case management) and Cortex (analysis engines) is the most didactic way to understand which pieces participate in SOAR incident response automation. TheHive centralizes alerts and cases; Cortex runs analyzers (VirusTotal, AbuseIPDB, PassiveTotal, YARA) and responders (block an IP, send an email, isolate a host).

On the commercial side, Splunk SOAR (formerly Phantom) is the benchmark within the Splunk Enterprise Security ecosystem: it offers visual playbooks, native connectors for more than 300 technologies and a very complete approval model for regulated environments. The choice between one or the other depends on budget and team, but the concepts behind SOAR incident response automation are identical: alert sources, execution engines, integrations and a versioned playbook catalog.

One detail that makes the difference in practice: integrations must use dedicated service credentials with least privilege, exactly as you would do with any other service account. A SOAR incident response automation platform holding administrator permissions over the entire estate is a giant target for an attacker, so treat orchestration credentials as the highest value asset in the SOC.

5. Practical example: a phishing response playbook

Let us put everything above into practice with a real, reproducible case. We are going to define a phishing playbook for TheHive and Cortex, expressed in YAML, covering SOAR incident response automation from alert to case closure:

name: "Playbook: phishing alert response"
description: "Enrichment, analysis and containment of a malicious email"
trigger:
  type: alert
  source: thehive
  filter:
    type: "phishing"
steps:
  - id: enrich_url
    action: cortex.analyzer
    provider: VirusTotal.GetReport
    parameters:
      artifact: "${alert.url}"
      tlp: 2
  - id: decide
    action: python.execute
    script: |
      score = artifact_report.get("positives", 0)
      if score >= 5:
        severity = "HIGH"
      else:
        severity = "LOW"
  - id: block_sender
    action: email.gateway.block
    condition: "${severity} == 'HIGH'"
    parameters:
      sender: "${alert.sender}"
  - id: create_case
    action: thehive.create_case
    parameters:
      title: "${alert.title}"
      severity: "${severity}"
      artifacts: "${alert.artifacts}"

Fig. 1 – YAML playbook for automated phishing response.

Notice the flow: first the URL is enriched with a VirusTotal analyzer, then a small function decides the severity based on the score and, only if it is HIGH, the sender is blocked at the email gateway and a case is created. In a SOAR incident response automation playbook, the main risk is the quality of the input data, because the platform’s YAML code is only a sample of the real logic. The alert arriving from the SIEM must already bring a clean structure, like this one from TheHive:

{
  "title": "Possible phishing detected",
  "severity": 2,
  "tags": ["phishing", "malware"],
  "artifacts": [
    {"data": "https://evil.example.com/landing", "dataType": "url"},
    {"data": "phishing@evil.example.com", "dataType": "mail"}
  ]
}

Fig. 2 – JSON alert that the SIEM sends to TheHive and triggers the playbook.

If you prefer to run the enrichment outside the playbook’s visual editor, the Cortex API lets you launch analyzers from Python. This small script checks the reputation of an artifact and returns the score your playbook will use to decide; it is also a practical starting point for introducing SOAR incident response automation into your own lab:

from cortex4py.api import Api

api = Api('http://cortex.local', 'API_KEY_CORTEX')
report = api.analyzers.run_by_name(
    'VirusTotal_GetReport',
    artifact={
        'data': 'https://evil.example.com/landing',
        'dataType': 'url'
    }
)
print(report.report['positives'])

Fig. 3 – Launching a Cortex analyzer from Python.

The official TheHive Project documentation maintains integration guides with Cortex and with most SIEMs on the market, while the Splunk SOAR documentation covers the commercial version with visual playbooks and native connectors. Both are mandatory reference material when you start building your own playbook catalog.

6. Success metrics: MTTR and SOC effectiveness

A SOAR incident response automation platform is only justified if its metrics improve, and the key metrics are few and clear. The first is MTTR (Mean Time to Respond), the average time from alert generation to containment. The second is the false positive rate, because if you automate a bad detection you only generate garbage faster. The third is the automation index: the percentage of alerts closed without human intervention, the real summary of your SOAR incident response automation level.

The numbers in the table below are representative of real implementations I have observed in mid-size companies, and they serve as a reference for setting achievable goals in your own project:

Table 1. Manual operations versus SOAR incident response automation
Process	Manual operation	With SOAR
Classification of a standard alert	25-40 min	1-3 min
Enrichment with external reputation	15 min	30 s
Containment of a compromised host	60-90 min	5-10 min
Case documentation	30 min	Automatic on completion
False positives closed without analysis	Not detected	Filtered by playbook

Let us be honest about the goals: SOAR incident response automation does not eliminate SOC headcount, it reassigns it. The analyst stops executing tasks that a machine does better and moves on to validating decisions, managing exceptions and writing new playbooks. If you start an implementation without first addressing the quality problems of the SIEM alerts, you will be building automation on swampy ground. That is why I recommend starting with the highest volume, lowest complexity use cases, and growing step by step.

7. Conclusion

SOAR incident response automation is neither a fad nor a miracle product: it is an engineering discipline that turns the analysts’ tacit knowledge into reproducible, measurable SOAR incident response automation workflows. Well-designed playbooks, least privilege integrations and objective MTTR metrics let you build a SOC that responds in minutes and learns from every incident.

My advice for getting started is modest: pick a single use case, for example phishing response, and take SOAR incident response automation all the way to the end on that flow before expanding the catalog. Write the playbook, run it against simulated incidents, measure the times and then publish the results. That proof of concept is worth more than any three-year roadmap. Once the flow is proven, standardize it and hand it to the rest of the team.

If you want to see a complete SOC and SIEM implementation in a hands-on environment, I recommend these articles. Related articles: Master SOC Box: SIEM and SOC demo and Master SOC on Box: SIEM and SOC implementation.

Need help with SOAR incident response automation?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.