A security analyst may spend more time moving information between tools than actually investigating an incident. An alert arrives in a SIEM, its IP address needs checking against threat intelligence, endpoint details must be retrieved from an EDR platform, a ticket needs creating, and the right team must be notified. If the incident requires containment, another system has to be updated.

Each step may be straightforward. The difficulty is repeating them consistently across hundreds of alerts while preserving enough context for an analyst to make sound decisions.

Security Orchestration, Automation and Response (SOAR) platforms address this operational problem. They connect security products, turn repeatable procedures into workflows, and coordinate actions across an organization’s security environment.

But SOAR is not simply a tool that automatically blocks suspicious activity. Its real value lies in making response processes repeatable, auditable, and appropriately controlled. The difference between a useful deployment and an expensive collection of unused playbooks often comes down to workflow design, integration quality, and how much authority the organization gives its automation.

What makes SOAR different from ordinary workflow automation?

Traditional workflow automation moves information between applications or performs predefined business tasks. SOAR applies that principle specifically to security operations, where workflows must account for incident context, security policies, investigation evidence, and potentially disruptive response actions.

A typical SOAR workflow combines three related functions:

• Orchestration: Connects security products and coordinates actions across them. For example, an alert from a SIEM can trigger information gathering from an identity provider, endpoint platform, and threat intelligence service.
• Automation: Executes repeatable tasks such as extracting indicators, checking reputation data, enriching alerts, assigning tickets, and preparing incident reports.
• Response: Helps analysts carry out appropriate actions, which may include escalating an incident, requesting approval, disabling an account, or initiating containment through an integrated security product.

The distinction matters because an organization might already have automation scripts without having a complete SOAR capability. A collection of scripts can perform individual tasks, but a SOAR platform provides a structured environment for connecting those tasks to incident workflows, managing execution, and recording what happened.

How a SOAR playbook works

A playbook is a defined sequence of tasks, conditions, decisions, and actions used to handle a particular security scenario.

Imagine an employee reporting a suspicious email.

A well-designed phishing investigation playbook might:

1. Receive the alert from an email security platform or SIEM.
2. Extract the sender, recipient, URLs, file hashes, and other relevant indicators.
3. Check available threat intelligence sources.
4. Retrieve information about the affected email and user.
5. Determine whether the message was delivered to other employees.
6. Create or update an incident record.
7. Present the evidence and recommended next steps to an analyst.
8. Request approval before removing messages or taking other consequential action.
9. Record the final outcome and notify the appropriate team.

Not every step needs to be automated. Some decisions require human judgment, especially when the available evidence is incomplete or an action could disrupt legitimate business activity.

A useful playbook therefore combines automated tasks with decision points and manual approvals. It should make the analyst’s work easier without removing the ability to intervene.

The SOAR platforms that take different approaches

The market includes dedicated SOAR products, broader security operations platforms, and workflow automation tools designed to support security teams. These products overlap, but their architectures and intended workflows are not identical.

Cortex XSOAR: Structured incident workflows across a broad security ecosystem

Cortex XSOAR from Palo Alto Networks is designed around incident management, integrations, playbooks, and coordinated security response.

Its playbook model supports automated tasks, conditional logic, manual analyst tasks, and reusable workflow components. This allows teams to create processes that combine information gathering, investigation, escalation, and remediation rather than treating each integration as an isolated automation. Cortex XSOAR+1

One important part of the platform is its content-pack ecosystem. Packs can contain integrations, automation scripts, playbooks, dashboards, and other components used to implement security workflows. This gives teams a starting point for common use cases while allowing them to develop custom integrations and procedures. Palo Alto Networks+1

The product is particularly relevant to security operations teams that need structured incident handling across a diverse collection of security tools. Its incident collaboration and investigation capabilities are also relevant to teams that need a shared workspace for coordinating analysts.

The trade-off is the effort required to maintain a large automation environment. Content packs, integration dependencies, authentication, custom scripts, and playbook changes all require governance. Organizations should also distinguish between vendor-maintained content and third-party or community contributions when assessing support responsibilities.

Cortex XSOAR deserves consideration when the organization needs a dedicated security orchestration platform with substantial playbook customization and incident management.

Splunk SOAR: Automation for teams already invested in Splunk workflows

Splunk SOAR combines playbook automation, orchestration, and case management. It is available in cloud and on-premises forms, giving organizations different choices for where their automation environment operates. Platform (last updated lastModifiedISO)+1

A notable distinction is its developer-oriented automation model. Splunk SOAR supports visual playbook development alongside Python-based automation and APIs. Teams can create workflows that connect security products, process event data, and execute actions across integrated systems. Platform (last updated lastModifiedISO)+1

This makes it relevant to organizations that already use Splunk for security monitoring and want to connect detections to repeatable response procedures. It can also support environments where analysts and security engineers need to develop custom automation rather than rely exclusively on prebuilt workflows.

However, Python flexibility introduces a responsibility: custom code must be maintained, tested, reviewed, and secured. An organization should not assume that every playbook will remain compatible as external APIs, authentication methods, and integrated products change.

Buyers should also examine the differences between the cloud and on-premises editions, including administration, migration requirements, integration execution, and support arrangements.

Splunk SOAR is a logical candidate when the team wants a dedicated automation platform and has the technical skills to develop and maintain its workflows.

FortiSOAR: Enterprise orchestration with extensive integrations

FortiSOAR from Fortinet focuses on centralizing security operations and coordinating workflows across security and IT systems.

Its documented capabilities include alert ingestion, case management, investigation, playbooks, and integrations with products from multiple vendors. Fortinet also describes support for extensive prebuilt connectors and solution packs covering common operational use cases. Fortinet+1

A relevant distinction is its attention to enterprise and managed security service provider environments. Fortinet documents multi-tenancy capabilities and workflows intended to support organizations managing multiple customers or security operations teams. It also describes deployment choices that include SaaS and self-managed software. Fortinet

FortiSOAR may be particularly relevant where an organization needs centralized case handling across a large security ecosystem, including environments that combine IT and operational technology requirements.

The important procurement question is not simply how many connectors are advertised. Buyers should test the exact actions required by their workflows. A connector may support event ingestion without supporting every response action, and a workflow may depend on specific permissions or product editions.

The organization should also assess how FortiSOAR fits with its existing Fortinet infrastructure and whether it can coordinate effectively with third-party tools.

Swimlane Turbine: Low-code orchestration with customizable security workflows

Swimlane Turbine is designed to help security teams build workflows and manage security operations through a customizable automation environment.

Its platform includes low-code playbook development, case management, dashboards, and integrations. Swimlane’s documentation describes both hosted cloud deployment and installation of its platform on-premises, including air-gapped environments. Swimlane Knowledge Center+1

This deployment flexibility is relevant to organizations that cannot move all security operations into a public cloud environment. The ability to construct workflows and case-management processes also gives teams room to adapt the platform to their own operating procedures.

Swimlane has introduced AI-assisted capabilities through its Hero AI offering, including assistance with playbook creation and security operations workflows. These capabilities should be evaluated as workflow-support features rather than assumed to replace analyst validation or established automation controls. Swimlane Knowledge Center+1

The main consideration is implementation complexity. A highly customizable platform can reflect an organization’s processes closely, but the organization must still define and maintain those processes. Buyers should test how easily workflows can be documented, versioned, reviewed, and transferred between development and production environments.

Turbine is worth evaluating when customization, case management, and deployment flexibility are important requirements.

Tines: Security workflow automation beyond the traditional SOAR model

Tines takes a workflow-oriented approach to security automation.

Rather than relying only on conventional security playbooks, Tines allows teams to build workflows that connect applications, process information, and coordinate tasks across different services. Its security offering emphasizes integration, workflow design, incident response, and human control over automated actions. tines.com+1

This approach can be useful for security teams that want to automate work extending beyond traditional alert response. Examples include access requests, employee onboarding and offboarding processes, security reporting, vulnerability coordination, and incident communications.

Tines also documents a case-management capability that provides a shared workspace for tracking work, assigning responsibility, recording progress, and coordinating actions. Tines 3B Docs

Its flexibility is an advantage, but it also means teams need to establish clear workflow ownership. Without standards, a growing collection of automations can become difficult to understand and maintain.

Tines is particularly relevant to organizations that want a flexible automation platform for security and adjacent operational workflows rather than a narrowly defined incident-response system.

Microsoft Sentinel playbooks: SOAR capabilities built into a SIEM environment

Microsoft Sentinel includes SOAR capabilities through automation rules and playbooks.

Its playbooks are built using Azure Logic Apps. They can respond to incidents, individual alerts, or specific entities, and can be triggered automatically or run manually by an analyst. Microsoft Learn+1

Automation rules provide a central way to manage incident handling, including assigning incidents, adding tags, closing eligible records, and triggering playbooks. Logic Apps provides the workflow engine for more complex actions and integrations. Microsoft Learn+1

This makes Sentinel attractive to organizations that already use it as their SIEM. Instead of purchasing and maintaining a separate orchestration platform for every routine response task, teams can extend existing security workflows through its automation capabilities.

However, Sentinel playbooks are not a cost-free extension. Logic Apps can introduce additional charges, and the workflow may depend on Azure permissions, authentication connections, and the services being automated. Microsoft Learn

Organizations should also consider the platform’s ongoing transition into the Microsoft Defender portal and plan their operational workflows around the supported management experience. Microsoft Learn

Sentinel is a practical option when the organization already relies on Microsoft’s security ecosystem and its automation requirements can be met through the available playbook model.

Shuffle: An open-source starting point for security automation

Shuffle offers a workflow-based approach with an open-source foundation.

Its workflow editor connects triggers, applications, conditions, and variables to create automated processes. The platform supports integration development and can use APIs to connect services that do not have a dedicated application integration. GitHub+1

Shuffle can be relevant to security engineers who want to experiment with orchestration, connect open-source security tools, or develop custom workflows without immediately purchasing a commercial SOAR platform.

Its licensing requires careful attention. The project documents different licenses for its components: the main platform backend uses AGPLv3, while workflows and several other components use MIT licensing. Organizations should review the applicable license terms for the components they deploy and modify. GitHub+1

Self-hosting also transfers operational responsibility to the organization. Infrastructure, credentials, workflow execution, upgrades, backups, and security monitoring still need to be managed.

Shuffle is worth considering for technically capable teams that want to build and operate their own automation environment. It should not be assumed to provide the same support model or managed operational experience as a commercial enterprise product.

Comparing the different SOAR approaches

Platform	Main approach	Deployment considerations	Important trade-off
Cortex XSOAR	Dedicated security incident management and playbooks	Confirm available deployment and licensing terms	Custom content and integrations need ongoing governance
Splunk SOAR	Playbook automation with Python and Splunk ecosystem integration	Cloud and on-premises editions	Custom development requires technical maintenance
FortiSOAR	Enterprise orchestration and multi-tenant security operations	SaaS and self-managed options	Validate connector actions and third-party interoperability
Swimlane Turbine	Low-code workflows and customizable case management	Hosted cloud and on-premises, including air-gapped installation	Customization requires workflow ownership
Tines	Flexible security and IT workflow automation	Confirm service and hosting requirements	Broad flexibility can create workflow sprawl
Microsoft Sentinel playbooks	SOAR workflows integrated with a SIEM	Azure Logic Apps-based	Additional service costs and Azure dependencies
Shuffle	Open-source workflow-based security automation	Self-managed and subscription-supported options	Infrastructure and maintenance remain the user’s responsibility

These platforms should not be treated as interchangeable products. Some are dedicated SOAR systems, while others combine orchestration with SIEM or broader workflow automation. The most appropriate shortlist depends on whether the organization needs a central incident-management environment, a flexible automation engine, or response workflows inside an existing security platform.

The open-source alternative: TheHive and Cortex

Not every organization needs a conventional commercial SOAR product. A combination of open-source security incident management and automation components can provide an alternative, particularly for technically capable teams.

TheHive is designed to support incident investigation and coordination. Cortex complements it by automating the analysis of observables and executing response actions through analyzers and responders.

Cortex can analyze information such as IP addresses, file hashes, and domains through connected services. Its responders can perform actions associated with alerts, cases, tasks, and observables. TheHive can connect to Cortex to use these capabilities during an investigation. TheHive 6 Documentation+1

This combination is worth understanding because it separates two important responsibilities:

• TheHive provides the incident investigation and coordination environment.
• Cortex provides analysis and response capabilities that can be invoked through integrations.

It is not identical to a complete commercial SOAR platform. Organizations may need additional components and custom workflows to achieve the same breadth of orchestration, reporting, governance, and enterprise integrations.

For teams that want control over their infrastructure and have the technical resources to maintain the environment, this can be a useful alternative. The total effort should include integration development, upgrades, access control, monitoring, and support responsibilities.

The automation problem is usually harder than the playbook editor

A visual workflow designer can make automation look straightforward. The difficult work begins when a workflow has to operate reliably across real systems with different authentication methods, API limitations, data formats, and permission models.

Several technical issues deserve attention before deployment.

Integration depth matters more than connector count

A vendor may advertise hundreds of integrations, but the number alone says little about whether a product can perform the required task.

For example, a connector might retrieve endpoint information but lack the action needed to isolate that endpoint. Another may support sending alerts into a ticketing system but not updating the ticket when an investigation changes.

For each critical integration, establish:

• Which events and objects can be retrieved?
• Which actions can the automation execute?
• Does the integration support bidirectional communication?
• Which authentication methods are available?
• Can permissions be restricted to specific actions?
• What happens when an API is unavailable or rate-limited?
• How are failed executions retried and recorded?

A proof of concept should test complete workflows, not just successful connections.

Playbooks need error handling and recovery

An automation process can fail halfway through execution. A threat intelligence service may be unavailable, a token may expire, or an endpoint product may reject a response request.

A reliable playbook should define what happens when a step fails.

Depending on the scenario, it may retry an operation, continue with reduced information, pause for analyst review, or create an incident requiring manual intervention.

The workflow should also distinguish between:

• A completed action
• An action that was attempted but rejected
• An action that timed out
• An action that was skipped
• An action whose result could not be verified

This distinction is essential. A workflow should never report that an endpoint has been isolated merely because it successfully submitted an API request.

Credentials and permissions are part of the security architecture

SOAR platforms often hold credentials that allow them to interact with security and business systems. These credentials can provide significant privileges, especially when a workflow can disable accounts, change firewall rules, or modify endpoint configurations.

Organizations should treat the SOAR platform as a sensitive control point.

Important safeguards include:

• Dedicated service identities for integrations
• Least-privilege API permissions
• Secure credential storage and rotation
• Separate development and production environments
• Restricted access to playbook editing and execution
• Approval requirements for high-impact actions
• Audit records for automated and manual activities

A compromised automation platform could provide an attacker with access to multiple connected systems. Its permissions and administrative interfaces therefore deserve the same care as other critical security infrastructure.

Which actions should be automated, and which should remain under human control?

The safest approach is to classify actions by their consequences rather than automate everything that can be connected to an API.

Action type	Example	Suggested control
Information gathering	Retrieve user, device, or IP details	Automate
Data enrichment	Query threat intelligence services	Automate with source and result tracking
Administrative coordination	Create tickets and assign incidents	Automate with validation
Communication	Notify an analyst or incident team	Automate according to policy
Access changes	Disable an account or revoke a session	Require clear conditions and approval where appropriate
Network or endpoint containment	Change access controls or isolate a system	Use strict authorization, testing, and recovery procedures
Incident closure	Close an alert or case	Automate only when closure criteria are reliable and auditable

The objective is not to remove humans from every decision. It is to remove repetitive work while preserving human judgment where uncertainty or operational impact is high.

This is especially important in environments containing production systems, healthcare infrastructure, financial services, or operational technology. A mistaken containment action can interrupt legitimate services.

How to calculate the real value of SOAR

SOAR is often justified through reduced manual effort and faster incident handling. Those benefits should be measured against the actual cost of building and maintaining the automation.

A useful starting point is to select one recurring process, such as phishing investigation or suspicious-login triage, and establish its current operating baseline.

Measure:

• Time analysts spend gathering information
• Number of manual handoffs
• Frequency of repeated tasks
• Time spent creating and updating incident records
• Number of failed or incomplete investigations
• Time required to maintain integrations and playbooks
• Frequency of analyst intervention during automated workflows

Then evaluate the same process after introducing automation.

A simple estimate of potential labour savings can be expressed as:

\[ \text{Potential time saved} = (\text{Manual time per case} – \text{Automated handling time}) \times \text{Cases handled} \]

This is only an estimate of time, not a complete financial return. It should account for development, testing, maintenance, licensing, infrastructure, and analyst review.

For example, automating an enrichment process may save analysts several repetitive steps, but the value depends on how frequently the process occurs and whether the results genuinely reduce investigation effort.

A workflow that saves time but regularly produces incorrect outcomes is not a successful automation.

Common mistakes that make SOAR deployments harder to manage

Automating a process that has not been standardized

If analysts follow different procedures for the same incident type, automating the process can make those inconsistencies harder to identify.

Before building a playbook, agree on the expected inputs, decision criteria, responsibilities, and completion conditions.

Building too many playbooks too early

A large automation library can look impressive, but every workflow creates maintenance responsibilities.

Start with a small number of recurring, high-volume processes. Expand only after the initial workflows have demonstrated reliable results.

Giving automation excessive privileges

A playbook that can modify user accounts, network policies, and endpoint configurations should not automatically receive unrestricted administrative access.

Use separate service identities and narrowly scoped permissions. Require approval for actions with significant operational consequences.

Ignoring API failures and changing integrations

Third-party services can change their APIs, authentication requirements, and response formats. Workflows should include error handling, execution monitoring, and periodic integration testing.

Measuring success only through alert volume

Closing more alerts does not necessarily mean the security team is responding more effectively.

Measure the accuracy of the process, quality of investigation evidence, consistency of response, and amount of analyst work genuinely removed.

A practical way to evaluate a SOAR platform

Rather than comparing products through feature lists alone, select one incident workflow that reflects the organization’s actual security environment.

A phishing investigation or suspicious-account activity scenario is a reasonable starting point because it can involve several security products without requiring immediate high-impact containment.

During a pilot, evaluate five areas:

Integration completeness: Can the platform retrieve the required information and execute the actions the workflow actually needs?

Workflow reliability: Can it handle missing fields, unavailable services, expired credentials, and unexpected API responses?

Human oversight: Can analysts review evidence, approve actions, override decisions, and understand why the workflow took a particular path?

Security governance: Are credentials protected, permissions restricted, and execution records available for audit?

Operational maintainability: Can the team understand, test, document, update, and troubleshoot playbooks without depending on a single developer?

Ask vendors to demonstrate failure scenarios, not just successful demonstrations. A platform’s behaviour when an API fails or an approval is denied can reveal more about its operational maturity than a polished happy-path workflow.

When SOAR is unnecessary or premature

A dedicated SOAR platform may be excessive for an organization with only a small number of security alerts, a limited security toolset, and no established incident response procedures.

In such cases, basic automation within existing tools may be sufficient. SIEM rules, endpoint security workflows, ticketing integrations, and simple scripts can handle many repetitive tasks without introducing another platform to administer.

A dedicated SOAR system becomes more valuable when:

• Analysts repeatedly perform the same investigation steps.
• Security tools are disconnected and require manual coordination.
• Incident response involves several teams.
• The organization needs consistent, documented procedures.
• A security operations team manages a high volume of recurring alerts.
• Automation needs to be governed, monitored, and reused across multiple environments.

The decision should be based on the complexity and frequency of the work, not on the assumption that every mature security team must own a separate SOAR product.

Turning automation into a dependable part of security operations

Cortex XSOAR and Splunk SOAR are relevant when an organization needs dedicated security orchestration with structured playbook development. FortiSOAR and Swimlane Turbine offer enterprise-oriented approaches with broad workflow customization. Tines provides a flexible automation model that extends beyond conventional incident response. Microsoft Sentinel playbooks can meet many orchestration requirements within an existing Microsoft security environment, while Shuffle and TheHive with Cortex provide alternatives for teams prepared to manage more of their own infrastructure.

The most important decision is not which platform advertises the largest integration library or the most sophisticated automation features. It is whether the organization can build workflows that are reliable, secure, understandable, and appropriate for its incident response policies.

Start with one process that analysts repeat frequently. Standardize it, automate the low-risk steps, retain human approval for consequential decisions, and measure the result. Expand only when the workflow proves dependable.

That is how SOAR becomes a practical security operations capability rather than another system that the team has to maintain.