If you’ve been working within the information security domain for a while you’ve likely listened to persons stating things like the following on several occasions: 

“These logs are replete with incidents that have not been reported!” 

“How many event alerts make an incident?” 

“I just got an event for the alert…” 

And so on. We essentially have a mess of mixed-up terminologies. 

There is massive confusion – even among those in the domain – with regards to what comprises an event, an alert, and an incident. 

The following is a breakdown is on the basis of analysis of many several differing industry definitions. 

• An event is a change that has been observed to the typical behaviour of a system or framework, environment, process, workflow, or person. Instances: router ACLs were updated, firewall policy was pushed. 
• An alert is a notification that is a specific event (or series of events) has happened, which is sent to accountable parties for the purpose of spawning action. Instances: the events above are delivered to on-call personnel. 
• An incident is an event that negatively impacts the confidentiality, integrity, and/or availability (CIA) at an organization in a fashion that influences the business. Instances: attacker posts organizational credentials online, attacker steals client credit card database, worm spreads via network. 

If we had to sum things up in a single sentence, we’d say – Events are captured changes in the environment, alerts are notifications that particular events occurred, and incidents are special events that negatively impact CIA and create an impact on the business.  

NOTES 

1. It is feasible to give definition to an incident in an array of ways on the basis of the organization, and it’s ok for there to be some variance on the basis of varying organizational requirements. However, it will always be a special variant of event that needs an organized and timely response. 
2. NIST and CERT define an incident as a violation of explicit or implicit policy, and in our opinions, that’s far too typical in most businesses to be practical. When determining how broad or narrow of a definition to leverage, consider that all incidents should spawn an IR response. If you’re unable to perform that as there are thousands upon millions of them each day or week, modify your definition accordingly. 
3. Another critical point on this definition of incident that we’re leveraging is that it must influence the business. If it negatively impacts CIA but there is no impact to the business, it appears strange to label that as an incident in the same fashion as something that does. 
4. CERT leverages the NIST 800-61 definition of “An incident is the action of violating an explicit or implicit security policy” 
5. Several would-be incidents are either human-created but non-malicious, or are human/malicious, however, don’t turn an issue, but unless both are true at the same time they aren’t usually managed by the information security department. (For example, earthquake, HR update.) 
6. There is some amount of debate on if to refer to something an event if it wasn’t captured. We’re in the camp that states you don’t, which is why we defined it as an “observed” change. 
7. “Disruption of business” doesn’t only imply that the organization is not able to function, it could additionally imply that those carrying out the business have totally lost their sanity and are demanding answers.