Events, Alerts and Incidents

What is it?

An event is any recorded occurrence on a system. An alert is an event, or pattern of events, that a detection rule decided a human should look at. An incident is an alert that investigation confirmed represents real, unwanted activity.

Why it matters

These three words are often used interchangeably in conversation, but in a SOC they carry different obligations. Events are stored. Alerts are triaged. Incidents are responded to and reported. Calling something an incident too early triggers escalation, wakes people up, and can halt production systems.

Where you see it

Events live in log sources: Windows Security logs, firewall logs, DNS logs, EDR telemetry. Alerts appear in the SIEM queue. Incidents appear in a case management system with an owner and a severity.

What normal looks like

A healthy environment produces enormous numbers of events, a much smaller number of alerts, and very few incidents. A single workstation can emit tens of thousands of events per day without anything being wrong.

What suspicious looks like

Suspicion comes from the relationship between events, not from any single event. One failed logon is noise. Forty failed logons from one source followed by one success is a pattern worth opening.

How analysts investigate

Start from the alert, then widen. Identify the host, the account and the time window. Pull the surrounding events for that host and account. Ask what happened immediately before and immediately after the alert fired.

Common beginner mistakes

Treating every alert as an incident, which floods escalation channels and destroys the team's trust in your judgement.
Closing an alert because a single event looked normal, without checking what surrounded it.
Reporting a conclusion without recording the evidence that supports it.

Security monitoring is a funnel. Raw telemetry enters at the top in enormous volume, detection logic narrows it, and human judgement narrows it further. Understanding where you sit in that funnel is what stops an L1 analyst from either drowning or missing the one alert that mattered.

  EVENTS        ~500,000 / day    all recorded activity
     |
     |  detection rules
     v
  ALERTS        ~120 / day        worth a human look
     |
     |  triage (you are here)
     v
  INCIDENTS     ~3 / day          confirmed, owned, reported

Indicative volumes for a mid-sized organisation. The exact numbers vary; the shape does not.

Term	Produced by	Your obligation
Event	A system doing its job	Nothing — it is context
Alert	A detection rule	Triage it and record a verdict
Incident	Your investigation	Escalate, contain, report

Windows Security — WS-042

02:14:07  4625  Logon failed   user=a.kamal  src=10.20.4.15  type=3
02:14:09  4625  Logon failed   user=a.kamal  src=10.20.4.15  type=3
02:14:11  4625  Logon failed   user=a.kamal  src=10.20.4.15  type=3
02:14:26  4624  Logon success  user=a.kamal  src=10.20.4.15  type=3

Four events. One alert would fire here. Whether it becomes an incident depends on what you find next.

Classifying the four lines above

Walk the same evidence a real analyst does — decide where each line sits on the event → alert → incident ladder.

Read each 4625 line on its own.
Each is an EVENT — a recorded failed logon. One failed logon at 02:14 is noise; the system is doing its job by recording it.
Now read the four lines together as a pattern.
Three failures from one source in seconds, then a SUCCESS from that same source — the pattern a detection rule flags. This is an ALERT: worth a human's attention.
Ask what would make it an incident.
Only VALIDATION does: confirm a.kamal was not working at 02:14 and that 10.20.4.15 is not their machine. Confirmed unwanted access = INCIDENT. Until then it is an alert under triage, not an incident.