The security operations landscape has shifted considerably in recent years, and the tools that once defined a single category now overlap in ways that can make procurement decisions genuinely difficult. Security orchestration, automation, and response — commonly abbreviated as SOAR — is a prime example. What was once a distinct product category with clearly defined boundaries has evolved into a set of capabilities that now appear across multiple security tool families. Understanding this evolution is the first step toward making a sound purchasing decision.
The most important observation from the current market is that features that were once exclusive to SOAR platforms have migrated into other security products. Incident response capabilities, for instance, are now commonly found in endpoint detection and response (EDR) tools. Orchestration functions have become a joint effort with security information and event management (SIEM) platforms. This means that when you begin evaluating SOAR products, you are no longer looking at a single, isolated category. Instead, you are looking at a spectrum of tools that may already include some of the functionality you thought you needed to buy separately.
This convergence has practical implications for your evaluation process. If your organisation already operates a SIEM platform, you may discover that some orchestration features are already available within that tool. Similarly, if you have invested in EDR solutions, some response automation may already be present. The question then becomes not simply "which SOAR product should we buy?" but rather "what gaps exist in our current security toolset, and which SOAR product — or SOAR-like capability — fills those gaps most effectively?"
Another critical factor to consider is the relationship between SOAR and SIEM in the current market. Many vendors have tied their SOAR and SIEM tools together, creating integrated platforms that offer both capabilities in a single package. Examples of this integration include Palo Alto Networks' Cortex, Microsoft's Sentinel, and NetWitness' Orchestrator. These integrated offerings can be attractive if you are looking for a unified approach to security operations, but they also mean that you may be committing to a particular vendor's ecosystem when you choose a SOAR product.
On the other hand, some vendors offer SOAR as a standalone product. Swimlane and D3 Security, for instance, offer only a SOAR product, with no accompanying SIEM offering. These standalone products typically feature wide third-party integrations, which means they can be positioned alongside your existing security tools rather than replacing them. This approach may be preferable if you have already invested significantly in a SIEM platform and want to add orchestration and automation capabilities without ripping out your existing infrastructure.
Deployment model is another key consideration. SOAR products are available in both cloud and on-premises configurations, and the right choice depends on your organisation's specific requirements. Cloud deployment offers advantages in terms of scalability and reduced infrastructure management burden, but some organisations have compliance or data sovereignty requirements that make on-premises deployment more appropriate. The source material does not provide specific guidance on which deployment model is superior, so this decision must be made based on your organisation's unique circumstances.
Third-party integration capabilities are arguably the most important technical factor to evaluate. A SOAR platform that cannot communicate effectively with your existing security tools is of limited value. The source material emphasises the importance of third-party integrations, and this is a theme that runs throughout the buyer's guide. When evaluating products, you should examine not only the breadth of integrations available but also the depth of those integrations. A product that offers hundreds of integrations but only at a superficial level may be less useful than one that offers fewer integrations but with deeper, more meaningful functionality.
Market segmentation is another factor that can inform your evaluation. Forrester Research partitions SOAR products into several categories: platforms, products that focus on threat intelligence, and those that are more centred around automation tasks. GigaOm divides the space into its own three categories: SOAR-only pure plays, full security platforms that integrate with other tool collections, and crossover products that originate from IT service management and automation segments. Understanding these categories can help you narrow your options based on what your organisation actually needs.
The sheer number of vendors in the SOAR market is worth noting. The source material indicates that the market segment has more than 30 vendors. This is a crowded field, which means there is likely a product that fits your specific requirements — but it also means that the evaluation process can be time-consuming. You will need a structured approach to filter the options effectively.
Practical steps
Begin your SOAR evaluation by conducting a thorough assessment of your current security operations. Document the tools you already have in place, including your SIEM, EDR, and any existing automation or orchestration capabilities. Identify the gaps in your current workflow. Where are your analysts spending too much time on repetitive tasks? Where are response times slower than they should be? What manual processes could be automated? This assessment will serve as the foundation for your entire procurement process.
Once you have a clear picture of your current state, define your requirements. Consider the specific use cases you want to address. Are you primarily looking for automation of routine tasks? Do you need better orchestration across multiple security tools? Is threat intelligence integration a priority? The source material notes that Forrester Research categorises SOAR products into platforms, threat-intelligence-focused products, and automation-centred products. Your requirements should align with one or more of these categories, which will help you narrow the field.
Next, determine whether an integrated SOAR/SIEM offering or a standalone SOAR product is more appropriate for your organisation. If you are already committed to a particular SIEM vendor, check whether that vendor offers SOAR capabilities. Palo Alto Networks' Cortex, Microsoft's Sentinel, and NetWitness' Orchestrator are examples of integrated offerings, according to the source material. If you are satisfied with your current SIEM and do not want to switch vendors, a standalone SOAR product with wide third-party integrations — such as those offered by Swimlane or D3 Security — may be a better fit.
Evaluate the deployment options available. Cloud deployment may offer faster time-to-value and reduced infrastructure overhead, while on-premises deployment gives you greater control over data and may be required for compliance reasons. The source material does not provide specific guidance on which deployment model is better, so this decision should be based on your organisation's specific needs, including any regulatory requirements that govern where your security data can be stored and processed.
Create a shortlist of vendors based on your requirements and deployment preferences. With more than 30 vendors in the market, you will need to be disciplined about your filtering criteria. Use the market segmentation from Forrester Research and GigaOm to help you categorise the products you are considering. Forrester's categories of platforms, threat-intelligence-focused products, and automation-centred products can help you match products to your specific needs. GigaOm's categories of SOAR-only pure plays, full security platforms, and crossover products from IT service management and automation segments can help you understand the strategic positioning of each vendor.
For each vendor on your shortlist, examine the third-party integration capabilities in detail. The source material emphasises the importance of these integrations, and this should be a major factor in your evaluation. Look at the specific integrations that matter for your environment. If you use a particular EDR tool, does the SOAR product integrate with it? If you have a specific ticketing system, can the SOAR product create and update tickets automatically? The depth and quality of integrations can vary significantly between products, so you should look beyond the marketing materials and request demonstrations that show real-world integration scenarios.
Request demonstrations from your shortlisted vendors. During these demonstrations, focus on the specific use cases you identified in your requirements definition. Ask to see how the product handles the types of incidents your team actually deals with. Ask about the workflow-based playbooks that the product supports. The source material notes that some SOAR products offer both automatic and customised playbooks, which define the steps that should be taken for different types of incidents. This is an important capability to evaluate, as playbooks are the mechanism through which automation is applied to real-world scenarios.
Consider the incident management capabilities of each product. The source material mentions that some SOAR tools offer options for assigning incidents to personnel and tracking status updates as incidents are worked. This is an important operational consideration. Your team needs to be able to manage incidents effectively, and the SOAR product should support your existing incident management processes rather than requiring you to adapt to a new way of working.
Evaluate the total cost of ownership for each product. The source material does not provide specific pricing information, so you will need to obtain quotes from vendors. Consider not only the licence cost but also the cost of implementation, training, and ongoing maintenance. If you are considering a cloud deployment, factor in the ongoing subscription costs. If you are considering an on-premises deployment, factor in the hardware and infrastructure costs.
Finally, before making a final decision, conduct a proof of concept with your top one or two vendors. This will give your team hands-on experience with the product and allow you to validate that it meets your requirements in practice. The proof of concept should be based on real-world scenarios from your environment, not just the vendor's standard demonstration. This is your opportunity to identify any issues with integrations, playbooks, or usability before you commit to a purchase.
Common mistakes to avoid
One of the most common mistakes in SOAR procurement is assuming that you need a SOAR product without first assessing what capabilities you already have. As the source material notes, features that were once exclusive to SOAR have bled into other tools. Response capabilities can now be found in EDR tools, and orchestration is now a joint effort with SIEM tools. If you already have these capabilities in your existing toolset, you may not need a full SOAR platform. Purchasing a SOAR product without first assessing your current capabilities can result in redundant functionality and wasted budget.
Another common mistake is failing to consider the integration requirements carefully. The source material emphasises the importance of third-party integrations, and this cannot be overstated. A SOAR product that cannot integrate with your existing security tools will create more problems than it solves. Your analysts will end up manually transferring data between systems, which defeats the purpose of orchestration and automation. Before purchasing any SOAR product, verify that it integrates with the specific tools in your environment — not just the tools the vendor claims to support in its marketing materials.
Choosing a product based solely on the vendor's reputation or the product's market share is another pitfall. The SOAR market has more than 30 vendors, according to the source material, and the right product for your organisation depends on your specific requirements, not on what is most popular. A product that works well for a large enterprise may not be appropriate for a smaller organisation with fewer resources. Similarly, a product that is well-suited to a particular industry may not translate well to your sector. Take the time to evaluate products based on your specific needs rather than relying on general market sentiment.
Overlooking the deployment model is another common mistake. The source material notes that SOAR products are available in both cloud and on-premises configurations, and the right choice depends on your organisation's requirements. Some organisations assume that cloud deployment is always the best option, while others assume that on-premises is necessary for security reasons. Neither assumption is universally correct. You need to evaluate your specific requirements, including compliance obligations, data sovereignty concerns, and infrastructure capabilities, before making this decision.
Failing to plan for the operational impact of SOAR is another significant mistake. Implementing a SOAR platform is not just a technical project; it is an operational change. Your team will need to learn how to use the new tools, develop new playbooks, and adapt their workflows. The source material mentions that some SOAR products offer workflow-based playbooks, both automatic and customised, which define the steps that should be taken for different types of incidents. Developing these playbooks takes time and expertise. If you do not allocate sufficient resources to this effort, your SOAR implementation may not deliver the expected benefits.
Another mistake is treating SOAR as a replacement for your security team rather than as a tool to enhance their capabilities. SOAR is designed to automate repetitive tasks and orchestrate responses across multiple tools, but it does not replace the need for skilled security analysts. The source material does not suggest that SOAR eliminates the need for human expertise, and you should not make this assumption. Instead, you should view SOAR as a force multiplier that allows your team to focus on higher-value activities.
Ignoring the vendor's roadmap and long-term strategy is also a mistake. The SOAR market is evolving rapidly, and the source material notes that features once exclusive to SOAR have bled into other tools. This suggests that the market will continue to evolve, and you need to consider whether the vendor you choose is well-positioned for the future. A vendor that is heavily invested in SOAR as a standalone product may face challenges as orchestration and automation capabilities become more common in other security tools. Conversely, a vendor that is integrating SOAR into a broader security platform may offer more long-term value.
Finally, failing to involve your security operations team in the evaluation process is a critical mistake. The people who will be using the SOAR product on a daily basis need to be part of the selection process. They will have insights into the specific challenges of your environment that you may not have considered. They will also be the ones who need to embrace the new tool, and involving them in the evaluation process can help build buy-in and reduce resistance to change.
The SOAR market is complex and crowded, with more than 30 vendors competing for your business. By taking a structured approach to your evaluation, focusing on your specific requirements, and avoiding these common mistakes, you can select a product that genuinely enhances your security operations. The source material provides a useful framework for understanding the market, but ultimately, the right choice depends on your organisation's unique circumstances.
Sources
https://www.csoonline.com/article/3622920/soar-buyers-guide-11-security-orchestration-automation-and-response-products-and-how-to-choose.html
Published by Vigla Media OÜ (Estonia).