Home > SOC Analysis

Event, Alert, Incident

In a SOC, Event → Alert → Incident is the fundamental lifecycle of threat detection. Every SIEM, EDR, firewall, cloud platform, and monitoring system follows this chain. If you do not fully understand the difference between events, alerts, and incidents, you cannot triage correctly, cannot investigate correctly, and cannot build professional SOC workflows.

This chapter explains each stage in depth with practical examples, real logs, analyst actions, and how an event becomes an alert and then escalates into an incident.

What Is an Event?

An event is any activity logged by a system.
Events are raw data. They are not warnings. They are not security signals. They are simply recorded actions.

Every system generates thousands of events per second:

  • Logon attempts

  • Process starts

  • File access

  • Firewall connections

  • DNS queries

  • Registry changes

  • Cloud API calls

  • Authentication attempts

Events alone do not mean danger.

Examples of normal events

Windows:

4624 - Successful Logon

Linux:

sshd: Accepted password for mayur from 10.0.0.20

Firewall:

Allow TCP 10.0.1.5 → 8.8.8.8:53

Cloud:

IAM: ListUsers API Call

The SOC may collect millions of events per day. Only a few matter.

Analyst perspective

Events are data, not problems.

Analysts do not respond to events directly.

What Is an Alert?

An alert is a notification generated by a SIEM, EDR, firewall, IDS/IPS, or cloud security tool when certain events match a detection rule or suspicious pattern.

Alerts are created by:

  • Correlation rules

  • Behavioral analytics

  • Thresholds

  • Threat intel matches

  • Machine learning anomalies

  • Signature detections

  • Suspicious sequences of events

An alert is a potential security issue, but not confirmed yet.

Real SIEM Alert Example

ALERT: Suspicious PowerShell Execution
Host: WIN-PC34
Event: powershell.exe -enc JAB...
Parent: winword.exe
Severity: High

This alert was generated because Sysmon + SIEM rule matched:

  • parent_process = winword.exe

  • powershell invoked

  • encoded payload

EDR Alert Example

Behavioral Alert: LSASS memory dump attempt detected
Tool: Mimikatz-like activity

Firewall Alert Example

IPS: SQL Injection Attempt Blocked
Source IP: 91.22.14.7
Target: 10.0.0.50

Alerts require triage by analysts.

Analyst perspective

Alerts must be:

  • Validated

  • Investigated

  • Classified

  • Escalated or closed

L1 analysts handle most alert triage.

What Is an Incident?

An incident is a confirmed security event that requires response actions, containment, and documentation.

An incident means:

  • The alert is real (true positive)

  • Malicious behavior occurred

  • Systems, users, or data are at risk

  • SOC must take action

Incidents are escalated to L2/L3 analysts and incident responders.

Examples of incidents

  • Compromised user account

  • Malware execution on endpoint

  • Ransomware spreading in network

  • Data exfiltration attempt

  • Unauthorized privilege escalation

  • Successful SQL injection on a server

  • Cloud API abuse leading to resource creation

  • Insider data theft

  • C2 communication from infected host

Real Incident Example

Incident: Internal Host Compromised
User: admin
Evidence:
  - SIEM: Multiple failed logins → success
  - Sysmon: PowerShell encoded command
  - Firewall: Outbound traffic to malicious IP
  - EDR: Credential dumping detected
Actions:
  - Host isolated
  - Password reset
  - Forensic artifacts collected

Incidents trigger the Incident Response (IR) process:

  • Containment

  • Eradication

  • Recovery

  • Documentation

  • Lessons learned

Analyst perspective

Incidents require:

  • Immediate action

  • Deep technical investigation

  • Coordination with IR team

  • Full documentation

Alerts become incidents only after verification.

How an Event Becomes an Alert and Then an Incident

Step 1 — Event

Raw data appears:

4625 — Failed Logon

One event means nothing.

Step 2 — Repeated Events

Multiple failures:

4625 repeated 20 times in 2 mins

The SIEM rule triggers an alert:

ALERT: Possible Brute Force Attack

Step 3 — Analyst Reviews Alert

L1 checks:

  • IP reputation

  • User context

  • Past activity

Finds pattern:

  • 4624 (successful login after failures)

  • From suspicious IP

  • Admin role

Step 4 — Escalation

L1 escalates to L2:

Potential account compromise

Step 5 — Incident Declared

L2 finds supporting evidence:

  • PowerShell encoded command

  • Outbound C2 traffic

  • Persistence created

SOC declares:

INCIDENT: Account Compromise + Post-Exploitation Activity

IR begins.

Full Practical Example (End-to-End)

Event

Sysmon Event ID 1: powershell.exe launched

Alert (SIEM rule triggers)

ALERT: Suspicious PowerShell Execution with Base64 Payload

Incident (confirmed malicious)

INCIDENT: Malware Execution and Internal Reconnaissance Detected
- Host isolated
- Malicious process killed
- Hash blocked in EDR
- Firewall rules updated
- Forensic data collected

This is how SOC decision-making works.

Intel Dump

  • Events are raw logs generated by systems.

  • Alerts are suspicious activity identified by SIEM/EDR based on rules or behavior.

  • Incidents are confirmed security threats requiring action.

  • Analysts do not act on events, but they investigate alerts, and they respond to incidents.

  • Events → Alerts → Incidents is the core SOC detection lifecycle.

  • Real incidents require containment, eradication, and documentation.

  • Multi-stage detection and correlation transform isolated events into complete attack narratives.

HOME LEARN COMMUNITY DASHBOARD