An event is something that happened and was recorded. An alert is a notification produced when a rule matches events. An incident is an occurrence that actually or potentially jeopardizes confidentiality, integrity or availability, so it needs a response. Most events are routine, many alerts are not incidents, and only some alerts become one.
Definitions
Event. A logged occurrence: a login, a file upload, a permission denial. Most are harmless. Logging them is what makes later questions answerable.
Alert. A message to a person or system, created because a rule or threshold matched. An alert is a claim that something deserves attention. It may be wrong.
Incident. NIST's glossary, citing FIPS 200, defines an incident as an occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information it processes, stores or transmits. It also covers violations or imminent threats of violation of security policies, procedures or acceptable use policies. Another NIST glossary variant adds the words "without lawful authority".
Note the phrase "actually or potentially". An incident does not need confirmed data loss. A credible threat can qualify, which is why organisations write their own thresholds.
How they relate
| Term | Source | Volume | Human action |
|---|---|---|---|
| Event | Application, system and network logs | Very high | None by default |
| Alert | Detection rule or threshold on events | Lower | Triage |
| Incident | A triaged alert, or a report from elsewhere | Low | Response and review |
The flow is a funnel. Millions of events produce hundreds of alerts that produce a handful of incidents. If the funnel is wrong, two bad things happen: too many alerts and the team ignores them, or too few and real attacks pass through.
Why the vocabulary matters for application teams
First, it sets what you log. If you only record what you already know is an incident, you will have nothing to look at when one is discovered later. Log broadly, alert narrowly.
Second, it sets your severity scheme. A failed login is an event. Fifty failed logins across fifty accounts from one source is an alert. A confirmed account takeover is an incident. Using one word for all three makes reporting meaningless.
Third, it affects obligations. Many laws and contracts attach duties, such as notification windows, to incidents or breaches, not to events or alerts. Check what your own contracts and applicable laws say, and agree internally who decides when an alert becomes an incident.
A simple handoff
- Define a short list of alert types your application can raise.
- For each, say who triages it and within what time.
- Define what makes a triaged alert an incident, and who declares it.
- Link to your response plan. OWASP Top 10 A09 recommends an incident response and recovery plan, citing NIST SP 800-61r2 or later as an example.
- After each incident, review which events helped and which were missing, and add them.
For tips on keeping alerts meaningful, see an alert nobody acts on is not a control.
Quick check
Is every alert an incident?
No. An alert is a possible signal. It becomes an incident after triage shows a real or potential impact on security.
Do we need an incident to start logging?
No. Log events from the start, so evidence exists before anyone knows it is needed.
Safeguard's policies and gates turn selected findings into enforced checks in your pipeline, and its free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
