Alert, Event, Incident, and Offense: The Differences Every Analyst Needs to Know

Event: The Basic Observation

An Event is a record of an action, state, or change. Examples: a successful login, an authentication failure, process creation, a DNS query, policy change, or network connection. Most Events are legitimate; their value comes from the fields and context.

An Event can originate from a Raw Log, EDR Telemetry, a cloud Audit Log, or a network Flow. A SIEM performs Parsing and normalization to present uniform fields, but the record itself is not yet an assertion that an attack occurred.

Event quality depends on the source: Timestamp, Host, User, Action, Result, and a unique identifier. A missing or incorrect Event can lead to a misleading Alert, which is why professional investigation sometimes refers back to the Raw Data.

Alert: A Signal Generated by Logic

An Alert is created when a rule, model, signature, or analytics identifies a match. It may be based on a single Event, a sequence, a Threshold, an Anomaly, or an IOC. An Alert means “worth checking,” not “this event is malicious.”

An Alert typically includes a Title, Severity, time, Entities, Evidence, and Detection name. It can be a True Positive, Benign Positive, or False Positive. The role of Triage is to determine if there is enough context to open an investigation, close it, or enrich it.

In different systems, an Alert may be called a Detection, Finding, or Signal. It's important to check the product documentation to understand if it's a raw result, an aggregation, or already an investigation object.

Incident: An Investigation and Response Story

An Incident centralizes Alerts, Entities, Evidence, Timeline, and actions around a single scenario. In Microsoft Defender XDR, related Alerts are grouped to present the attack story across Endpoint, Identity, Email, and Cloud. An Incident can be updated as new information arrives.

At an organizational level, an Incident is not just a technical object. It includes an Owner, Status, Severity, Classification, Tasks, Comments, and response. A genuine Alert might not become an Incident if its impact is negligible and it's handled automatically; conversely, an Incident might be opened manually based on a user report, even without an automated Alert.

The term should be linked to the organization's criteria: when a finding becomes an event requiring Response, who is authorized to declare it, and how it is closed.

Offense in QRadar

QRadar collects Events and Flows and runs a Custom Rule Engine. When conditions are met, a Rule can contribute to the creation of an Offense. An Offense aggregates related Events and Flows and provides Context for investigation.

An Offense is not a general term for any Incident. It is an object specific to the QRadar model. It includes a Magnitude calculated based on Severity, Relevance, Credibility, and other factors. The analyst opens the Offense, checks Rules, Events, Source/Destination, Assets, Notes, and Timeline.

Sometimes an Offense represents a suspected policy violation or attack, but it still needs to be classified. It can be closed as a False Positive, Non-Issue, Policy Violation, or according to a local Taxonomy.

Finding, Case, and Detection

A Finding is an observation requiring attention, common in Cloud and Vulnerability tools. A Detection can be the detection logic or its result, depending on the product. A Case is a broad work wrapper that centralizes several Incidents or a cross-system investigation.

Instead of arguing over the “right word,” build an organizational dictionary: the term name, its source, what it represents, who the Owner is, what Statuses exist, and what creates or closes it. This dictionary is especially important when connecting multiple products to a SOAR.

Example Chain from Log to Incident

1. A Domain Controller logs an Event of fifty failed logins from one IP address. 2. A SIEM Rule counts the events within a five-minute window and creates an Alert for Password Spray. 3. Another Alert shows a successful Login for one of the users. 4. A correlation engine unifies the two Alerts into an Incident. 5. An analyst checks the Scope, revokes Sessions, and classifies the Incident as a True Positive.

In QRadar, the same Events and Flows might trigger Rules and create an Offense showing the attack source, users, Magnitude, and contributing events. The information is similar, but the names and relationships between the objects are different.

Comparison Table

Sorting Exercise

Practical Checklist

• ✓I checked the term definition in the product documentation.
• ✓I know the source and Trigger of each object.
• ✓I did not treat an Alert as proof of an attack.
• ✓I linked Events to Alerts and Incidents using identifiers.
• ✓I documented Classification and Owner.
• ✓I built a glossary for the team and SOAR.

Common Mistakes

• Calling every log line an “Incident.”
• Using Offense outside the QRadar context as if it's a general standard.
• Counting Events and Incidents with the same metric.
• Closing an Alert without checking if it's part of a broader Incident.
• Assuming the terms are identical between Sentinel, Defender, QRadar, and Elastic.
• Not maintaining a link between objects in the Ticketing system.

Summary and CTA

Open a SIEM or a lab scenario and choose ten items. For each, mark whether it's an Event, Alert, Incident, Offense, or Finding and explain who created it. Then, move on to the article “What is SIEM and how does it work” to understand the full data pipeline. In the HPI course, these terms are practiced within investigation tools, not just as definitions.

FAQ