Cybersecurity & Information Security

What is SIEM and How Does It Work From Log Collection to Incident

7 min readPublished: August 5, 2026

Professional visual illustration of what SIEM is in the field of SIEM and detection

Quick answer

SIEM — Security Information and Event Management — is a system that centralizes security data from many sources, transforms disparate records into searchable and comparable information, runs detection logic, and organizes findings as alerts or incidents for investigation. The value is not in merely storing logs, but in the ability to connect time, user, asset, IP address, and behavior into a narrative that the analyst can verify and act upon.

A modern organization generates security data at almost every layer: endpoints, servers, Active Directory, cloud services, applications, Firewalls, VPNs, DNS, mail systems, and EDR products. Each source speaks a different language. A login event might appear with a username in one format in Entra ID, a different format in Windows, and a third identifier in a business application. Without a layer that centralizes and links this information, an analyst must switch between screens and manually piece together the picture.

A SIEM system is designed to solve the problem of dispersion. It ingests telemetry, stores it according to policy, allows for searching and querying, applies detection logic, and provides a case management environment for investigation. However, installing a product does not automatically create a good SOC. A quality SIEM depends on correct sources, accurate time, proper parsing, ownership of rules, and a clear response process.

This guide follows a single login event from the server to the analyst's screen, explaining at each stage what the system does, what can go wrong, and what professional decision is required.

Why an Organization Needs SIEM

The first goal is central visibility. When a user logs in from an unusual country, their workstation runs PowerShell, DNS queries a new domain, and the Firewall detects outbound traffic, each record alone might seem benign. Connecting them within a time window and in the context of the same user and asset might indicate a compromised account.

The second goal is consistency. SIEM allows an organization to define Use Cases, Severity, Owners, Playbooks, and closure criteria. Instead of each analyst deciding anew how to investigate a Password Spray or Malware alert, the team works according to measurable and improvable logic and documentation.

The third goal is historical retention and investigation. Sometimes an organization discovers an Indicator weeks after a breach. If the relevant logs were saved, the IP, hash, domain, or account can be searched retrospectively, a timeline can be built, and the extent of the impact can be assessed. Retention must be determined by risk, regulation, cost, and investigation needs — not by an arbitrary default.

The First Step: Data Sources and Collection

A Data Source is where an event originates: Windows Security Log, Firewall Syslog, SaaS Audit log, EDR Telemetry, or VPN Authentication log. Collection is done via Agent, Data Connector, API, Syslog/CEF, Event Forwarding, or a built-in cloud service. Each method has advantages, limitations, and permissions.

Before connecting a source, define the purpose of the collection. The question is not “what logs can be sent?”, but “what behavior do we want to detect or investigate, and what fields are needed for that?”. Password Spray, for example, requires at least time, login result, user, source address, and sometimes application or Tenant. If the user field is missing, a sophisticated rule will not solve the problem.

Layer	Examples of Sources	Central Quality Question
Identity	Entra ID, Active Directory, VPN	Is there a user, result, MFA, and source address?
Endpoint	EDR, Sysmon, Windows Events	Is there a Host, Process, Parent, Command line, and hash?
Network	Firewall, DNS, Proxy, IDS	Is there Source/Destination, Port, Action, and Protocol?
Cloud and Application	AWS CloudTrail, Azure Activity, SaaS Audit	Are the action, resource, and Actor identified?

Parsing, Normalization, and Enrichment

After ingestion, the system needs to understand the record. Parsing extracts fields from text or JSON. Normalization maps different names to a consistent model: src_ip, sourceAddress, and ClientIP may represent the same idea. In Microsoft, ASIM provides a normalization model that allows writing a Query or Detection against a unified schema instead of adapting logic to each product separately.

Normalization does not delete the source. It is recommended to also keep the raw event to verify details and investigate incorrect parsing. When a Parser changes, a Rule may quietly stop working. Therefore, schema changes, empty fields, ingestion delay, and abnormal volume are measured.

Enrichment adds context that did not appear in the log: asset criticality, system owner, department, GeoIP, Threat Intelligence, whether the account is Privileged, whether the IP belongs to an organizational VPN, and whether the activity matches an approved Change. Enrichment changes the quality of the decision. One failed login to a test server is not the same as the same login to a Domain Admin account.

Detection: From Query to Alert

A Detection rule examines data according to a condition. It can look for a known Indicator, a sequence of events, a Threshold, a deviation from a Baseline, or a combination of sources. A Scheduled rule runs a Query at intervals and examines a Lookback window. If the results exceed a threshold, an Alert is generated. Other products import ready-made Alerts, and SIEM may aggregate several of them into one Incident.

A good Rule starts with a Use Case and a hypothesis, not a technical command. It should define the behavior, what sources are needed, what constitutes a single unit of result, what Entities will be mapped, what the Severity is, what the Expected noise is, and what the analyst is supposed to do. A Rule that cannot be investigated creates a burden even if it “catches” many events.

Correlation connects events. It can identify five failures followed by a success, a suspicious Process after a new login, or the same IP against many users. Important to remember: matching a rule is a lead for investigation, not proof of attack. An analyst must check the source, context, Timeline, and legitimate explanations.

Incident and Case Management

An Alert describes a specific match. An Incident is an investigation case that centralizes Alerts, Entities, Evidence, Timeline, Tasks, Owner, Severity, Status, and responses. Case Management allows hand-off, escalation, documentation, and metric generation. The system should maintain separation between facts, interpretation, and decision.

When opening an Incident, the analyst checks: who is the user and asset, what is the activity time, what sources participated, are there additional Alerts, what is the asset's criticality, and what has changed compared to normal behavior. Then they run supplementary Queries, verify Indicators, build a Timeline, and decide if it is a False Positive, Benign Positive, or True Positive.

Scenario: Login Event from Server to Analyst Screen

A Windows server logs a login event with time, user, Logon type, and source address.
A Forwarder or Connector sends the event to the SIEM. The system adds ingestion time and identifies the data source.
The Parser extracts Account, Computer, Source IP, and Result. The Normalization layer maps them to uniform fields.
Enrichment flags the account as Privileged and the server as Production. Threat Intelligence does not identify the IP, but GeoIP points to an unexpected country.
A Rule identifies several failures followed by a success within a time window. It maps User, Host, and IP and creates an Alert.
Another Alert from EDR identifies an unusual Process on the same workstation. Alert grouping aggregates both into an Incident.
The analyst checks MFA, VPN, Process tree, DNS, and additional activity, builds a Timeline, and decides on Containment and escalation.

What SIEM Does Not Do Alone

SIEM does not guarantee that all data exists or is correct. It does not replace Asset inventory, proper IAM, EDR, Network controls, or skilled professionals. It also does not automatically know what is normal for the organization. Without Owners and Tuning, the system may flood with Alerts or create a false sense of security.

Automation can enrich, open a Ticket, or isolate an asset, but automated action must match the level of certainty and impact. Blocking a critical user based on a noisy Rule can cause an outage. Therefore, Approval, Exceptions, Rollback, and Audit trail are defined.

SIEM vs. Related Systems

Concept	Focus	Practical Difference
Log Management	Collection, storage, and search	May not include full Detection and Case Management
SIEM	Detection, investigation, and event management based on multiple data	Connects Telemetry to the SOC process
SOAR	Automation and orchestration of response	Runs Playbooks and connects systems; sometimes integrated into SIEM
XDR	Integrated detection and response across domains like Endpoint, Identity, and Email	Comes with deep Telemetry and Detections of a specific platform

Checklist for Use Case Implementation

Behavior, not just a Rule name, has been defined.
Required data sources and fields are available.
Event times are synchronized, and the time zone is clear.
Parsing and Normalization have been checked with real examples.
Entities and asset criticality are mapped.
Threshold, Severity, and Expected noise are defined.
A Playbook with supplementary Queries and an escalation path exists.
Owner, Review date, and quality metrics are set.
Retention, cost, and access permissions have been reviewed.

Common Mistakes

Connecting every possible source before defining Use Cases.
Relying on ingestion Timestamp instead of event time.
Assuming every field named 'user' represents the same identity.
Creating a Rule without Entity mapping or investigation instructions.
Closing Alerts as noise without providing feedback to the Detection owner.
Displaying a green Dashboard when a data source has stopped sending.
Storing logs for a period that does not allow for historical investigation.

Summary and CTA

Choose one Use Case — for example, Password Spray — and outline the entire chain: source, fields, Parser, Query, Entity, Incident, and analyst action. Then move on to the KQL guide to write your first search. In HPI's Cybersecurity & AI track, SIEM is practiced as part of a full investigation process, including logs, networks, Windows, and incident response.

FAQ

Is SIEM a product or a process?

SIEM is a product or platform, but its value comes from a process that includes collection, data quality, Detection engineering, investigation, response, and improvement. Purchasing a license alone does not create SOC capability.

Does every event in SIEM become an alert?

No. Most events are stored for searching, Correlation, or investigation. An Alert is only generated when Detection logic or a connected product identifies a defined condition.

What is the difference between an Alert and an Incident?

An Alert is a single detection finding. An Incident is an investigation case that can include multiple Alerts and evidence around the same story or Entity.

Does SIEM have to be in the cloud?

No. Cloud, On-premises, and hybrid platforms exist. The choice depends on architecture, data, regulation, cost, and operations.

Which data source should be connected first?

Start with critical assets and identities and clear Use Cases. Typically, Identity, Endpoint, Firewall/DNS, and Cloud audit provide a strong foundation, but the order depends on organizational risk.