I am doing research on Security orchestration and automation response (SOAR) and three above terminologies make me very confused.

We are currently following the workflow like: some security events trigger an alert, these alert will be passed to the analyst, and if the alert is a real issue, then we create a ticket on our client's ticketing system.

But when I read about SOAR where the term incident appears, I found it is difficult to find exact definitions for those terms and explain them to other parties (analyst, clients).


3 Answers 3


Your chain is correct.

The event is a data point of activity, i.e. something that happened. A user logged in. A system failed. A TCP packet arrived. Typically it is an atomic unit, at least to the point that splitting it up further (e.g. the user login into individual interactions) would not make sense.

An alert is information about an event. A notification containing event details.

The incident is bigger than the event. The incident is the container of things that happened, including the (typically several) events, their impact and consequences and other relevant details.

As a metaphor, the incident would be a break-in. The smashing of the window is an event and part of that incident. The theft of the TV is an event within that incident. The alarm system going off when the window was smashed was the alert. (and the ticket is the police report you file)


An event is something that happens that might cause a security problem; an incident is something that happens that does cause a security problem.


There is certainly some ambiguity when dealing with some of the terms mentioned above, as they are defined by the context in which they are used. In general, the SOAR industry is an extension of the SIEM market and this is important to note as terms are defined.

The simplest place to start is with events. Events can be viewed as the building blocks of everything else since they are the raw data that is ingested into the system in question, whether this be a Security and Event Management Tool (SIEM) or Orchestration and Automation Tool (SOAR). So in the IT space, events are any piece of information ingested into the platform, ie log events, packet sessions, endpoint processes, etc.

As these events are ingested into your SIEM, alerts are generated by rules that have been put into place, applied to raw events and match certain conditions. For example, a rule could be created to say if there are more than ten failed authentication attempts to a system within 2 minutes, create an alert. As the Active Directory (AD) logs are monitored and the raw log events are ingested into the SIEM, if this condition should occur an alert is created.

Just as basic rules are created to capture and alert analysts as to activity within their IT infrastructure, more sophisticated scenarios and rules can be implemented. Lets say another rule is created so that when a users permissions are changed in AD and alert is created within your SIEM. Now it is possible to create a chain of requirements for notifying an analyst. So another more complex rule is created to capture multiple failed login attempts followed by account privilege escalation by way of AD changes. So if both of our previous rules are met, we will create an incident within our SIEM. This incident would have two alerts associated with it.

Here the term incident is used as it is more generally accepted than the word ticket, as Incident management is a big part of a SIEM platform. But this IT security incident may have larger impact to the business. In this case a ticket would be created in order to increase the visibility of the security incident to a larger scope of teams ie finance, accounting, devops etc. Tickets are generally created in a case management platform such as RSA Archer, ServiceNow or JIRA. So a ticket is very similar to an incident, but is usually implemented at a higher level of the organization.

Now to loop back around to the specific problem domain of SOAR. SOAR is an evolving space that is generally being seen as an extension to SIEM. It is managed by Security Operation Center analysts and leveraged by taking security incidents from the traditional SIEM and automated a response. This might be IP enrichment, security scanning, etc. Essentially when we see an incident of a certain type created in our SIEM, we want to implement x,y,z steps in response. These steps are automated by making api calls to other tools within the IT space. So in essence the SOAR tool is ingesting incidents from your SIEM.

This is not to say that tickets are not ingested from say Service Now or Jira for automation. This is the other common source of initiating playbooks in your SOAR tool. So tickets and incidents are very much the same thing, as they serve the same purpose, it just depends on if you are talking to the web dev, SOC analyst, project manager etc.

Source: I work as a Systems Engineer on SIEM and SOAR platforms.

Not the answer you're looking for? Browse other questions tagged .