Blog post

SOAR and Ticketing: Friends, Frenemies or the Same thing?

By Anton Chuvakin | November 03, 2017 | 6 Comments


We continue our journey through SOAR mysteries with this one: what is the relationship between case management (aka ticketing) and SOAR? So far, we have encountered these views (overdramatized for added hilarity!):

  1. “Are you dumb? SOAR and security case management are essentially the same thing; you cannot have a SOAR tool without incident case management, human workflow is the heart of SOAR for most clients.” [common]
  2. “Well, our SOAR has a bi-directional link to our IT case management, they are not the same system since IT uses ticketing, but security team uses SOAR, but they must link.” [common]
  3. “Wait…what? SOAR automates stuff so that we don’t have to open the stupid tickets. Our SOAR tool does not really have ticketing [or: it is weak] and we don’t really care much if integrates with external ticketing.” [rare]
  4. “Our SOAR includes ticketing, but also integrates with ticketing. Confused? Don’t be – this is security workflow vs IT workflow, we have to keep them separate, but we need both”

This is befuddling! It would be as if we’d have a debate on whether log collection is a central feature of SIEM or more of an add-on… So, is ticketing a central feature of SOAR or a nice-to-link adjacent technology? Is “O&A” the heart of SOAR or is that case management?

In all honesty, we are leaning towards the centrality or at least high relevance of case management as either part of SOAR or something very closely integrated. “SOAR as glue” (or middleware) just does not seem to have the mass appeal, we think.

What is your view of the ideal relationship between SOAR and ticketing?

Blog posts related to this topic:

The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.

Comments are closed


  • CP Morey says:

    We typically see option 2… “We have a ticketing system, want to integrate it w/ SOAR and execute actions like create/update/close a ticket through an automation playbook.” … and option 4… “Since we sometimes deal with sensitive cases, we want a ticketing system that only the security team can access, but for other, less sensitive cases we also want to integrate with IT’s.”

  • I have found that security teams with case management still seek out SOAR solutions to solve their challenges with making sure the right action is taken. So, while ticketing vendors may claim SOAR capabilities, if these were effective, there wouldn’t be so many organizations looking for SOAR.

    I consider the two friends when we’re talking about best-of-breed for each use case, frenemies when security teams want fewer vendors.

    • Thanks for the comment, Matt. Indeed, it is an astute point that the facts do not seem to support the idea that SOAR = ticketing — still, the q remains as to this being a central feature of SOAR or more of an integration…

  • Amos Stern says:

    I cant really imagine a “SOAR” without case management. That would just be “A”, a back-end automation tool.

    Security case management is an essential part of SOAR while at the same time integration to IT-ticketing is also a requirement.

    There are too many reasons for this to be able to count in a short comment (maybe a blog post is ensued), but a couple main ones are:

    1. Security teams need a dedicated work-bench to analyze security threats, understand the full context across the many security tools, perform a fast triage, analyze previous responses, invoke more investigative actions, collaborate, etc. The same reason why you don’t use a general-purpose ticketing system for running a sales process.

    2.The SOC process IN REALITY involves many varying degrees of automation, most of which are not 100%, and need to move between manual and automated actions back and forth. I cant imagine how this works with an integration to an external ticketing system.

    Just this morning I had a conversation with a customer, saying “I’d like that sometime a Case in Siemplify will open a ticket in an IT ticketing system, but dont want my analysts to ever need to go there” << there you have it.

    We tend to conflate the two, but O and A are VERY different things.

    The way I see it:

    Orchestration = integrating all your security tools (the "glue") + Context and analytic layer to connect all the pieces and disparate alerts + Security case management (analyst workbench, triage, collaboration) + workflow management (playbook editing and documenting) + BI (measurements, dashboards, reporting) == running a SOC.

    Automation = Automating of parts within an orchestrated process (typically certain actions within the workflow/playbook).