defensiva
SIEM
Security Information and Event Management
SOC

What Is SIEM: How It Works, SOAR vs XDR and Use Cases

What a SIEM is, how it works, how it differs from SOAR and XDR, real use cases, leading platforms and how it fits NIS2, ENS, ISO 27001 and PCI DSS.

SecraMay 4, 202610 min read

A SIEM (Security Information and Event Management) is the platform that collects logs and events from across the entire infrastructure of a company, normalises them, correlates them and fires security alerts in real time. It is the brain of any SOC: it turns millions of scattered log lines (firewall, EDR, Active Directory, cloud, SaaS) into a handful of actionable alerts that an analyst can investigate and respond to. Without a SIEM, the logs exist but nobody looks at them; with a properly configured SIEM, an intrusion that would take months to notice gets detected in minutes.

This guide explains what a SIEM is, how it works internally, how it differs from SOAR and XDR, the typical use cases, the platforms most used in the Spanish market and how it fits NIS2, ENS, ISO 27001 and PCI DSS.

What a SIEM is: technical definition

A SIEM is a security platform that centralises, normalises and correlates events coming from the entire technology footprint of an organisation to detect threats, investigate incidents and prove compliance. The acronym stands for Security Information and Event Management and unifies two disciplines that used to live apart:

  • SIM (Security Information Management): collection and long-term retention of logs.
  • SEM (Security Event Management): correlation and real-time alerting on events.

The combination is what makes the SIEM useful: it gathers history for forensics and compliance and, at the same time, fires alerts the moment it detects a suspicious pattern.

How a SIEM works under the hood

The operational flow of any SIEM (Splunk, Microsoft Sentinel, Elastic Security or Wazuh) always follows the same six blocks:

  1. Ingestion. Logs arrive at the platform from dozens of sources: firewalls, EDR, IDS, servers, Active Directory, cloud IdP (Okta, Entra ID), applications, containers, critical SaaS, CloudTrail, Azure Activity Logs and Google Cloud Audit Logs.
  2. Normalisation. Each source ships events in its own format. The SIEM transforms them into a common schema (fields like user, src_ip, dst_ip, action, timestamp) so they can be correlated against each other.
  3. Enrichment. The platform adds context to each event: IP geolocation, domain reputation, user identity, asset criticality, CVE identifiers applicable to the asset and external threat intelligence (IoC feeds).
  4. Correlation and detection. Rules and models analyse the events. A rule can be as simple as "more than 10 failed logins in a row" or as complex as "login from new country plus mass download plus creation of a forwarding rule within 15 minutes". Modern SIEMs add behaviour analytics (UEBA) and machine learning to catch what static rules miss.
  5. Alerting and dashboards. Prioritised alerts reach the SOC L1 analysts with the context they need to triage them. Dashboards show operational health, coverage metrics and trends.
  6. Retention. Events are kept for the period mandated by regulation or internal policy. ENS high category requires months; PCI DSS demands at least 12 months; NIS2 sets no concrete period but presumes traceability for incident investigation.

SIEM, SOAR and XDR: how they differ

The three terms get mixed up in vendor proposals and are not the same thing:

  • SIEM. Centralises logs and events, correlates and alerts. The detection foundation.
  • SOAR (Security Orchestration, Automation and Response). Automates response to alerts: isolate an endpoint, disable an account, open a ticket, notify the user. Usually integrates with the SIEM to close the detect, decide, respond loop.
  • XDR (Extended Detection and Response). A more recent evolution focused on unified telemetry across endpoint, network, identity and cloud, with detection and response natively integrated in a single vendor platform.

Quick rule: a modern SOC uses SIEM as the event pipeline, SOAR for response orchestration and XDR as the deep telemetry layer over specific domains (typically endpoint and cloud).

Typical SIEM use cases

The five operational applications that justify a SIEM in a real company:

  1. Real-time threat detection. Rules that fire alerts on brute force attempts, credential stuffing, privilege escalation, data exfiltration or anomalous use of privileged accounts.
  2. Behavioural detection (UEBA). Machine learning that learns the normal pattern of each user and asset and warns when something deviates: a marketing employee suddenly querying HR databases at 3 a.m., a service account starting to iterate over S3 buckets.
  3. Forensic investigation. When an incident happens, the SIEM lets you reconstruct the full timeline of the attack. Without it, logs sit on each server and reconstruction takes weeks.
  4. Compliance. Log retention, auditable evidence, recurring reports to satisfy NIS2, ENS, ISO 27001, GDPR or PCI DSS without building them by hand.
  5. Threat hunting. L3 analysts run proactive queries over the event history looking for MITRE ATT&CK TTP patterns that static rules do not catch.

SIEM platforms most common in the Spanish market

The market splits across five main families worth recognising when evaluating vendors:

  • Splunk Enterprise Security. The historical leader. Very powerful, very scalable, with a per-GB ingestion cost that blows up the bill if you do not filter ingestion well.
  • Microsoft Sentinel. Cloud-native SIEM on Azure. Attractive when the client is already on Microsoft 365 or Azure because of the native integration with Defender, Entra ID and Microsoft Graph.
  • IBM QRadar. Traditional in banking and public administration. Powerful correlation, complex licensing model.
  • Elastic Security (ELK Stack). Based on Elasticsearch. Open source with a commercial tier. Flexible and cheap at small scale, complex to operate at scale.
  • Wazuh. Open source SIEM of Spanish origin, fork of OSSEC. Very popular in the Spanish mid-market and public administrations thanks to its free model and active community.
  • Sumo Logic, LogRhythm, Securonix, Exabeam. Other platforms that occasionally appear in tenders.

Don't choose by brand. Choose by expected event volume, budget, existing integrations and maturity of the team that will operate the SIEM.

SIEM and compliance: NIS2, ENS, ISO 27001, PCI DSS

The SIEM is the technological piece that produces evidence for several mandatory controls in the frameworks that apply to Spanish and EU organisations:

  • NIS2 (article 21). Risk management measures require detection, logging and analysis capabilities. An operational SIEM is the usual proof of compliance. More in NIS2 in Spain: a compliance guide for 2026.
  • ENS (Spanish Royal Decree 311/2022). Measures op.exp.10 (activity logging), op.mon.1 (intrusion detection) and op.exp.8 (logging and review) presume a centralised log and event management platform.
  • ISO 27001 (controls A.8.15 Logging, A.8.16 Monitoring activities). Require systematic logging and review of events.
  • PCI DSS v4.0 (req. 10). Defines in detail which events must be logged, for how long (minimum 12 months) and how to review them daily. A SIEM makes automated compliance possible.

If your organisation falls under any of these frameworks, the SIEM is not optional. It is the foundation on which the evidence is built.

How to choose a SIEM: four practical criteria

Four decisions shape the outcome of the project:

1. Expected event volume and licensing model. Splunk charges per GB ingested, Sentinel per GB retained, Wazuh is free but requires operation. Calculate the real (not the desired) volume before asking for a quote.

2. Native integrations with your current stack. If you are already on Microsoft 365, Sentinel connects without effort. If your telemetry comes from a CrowdStrike EDR, its integrations with Splunk and Sentinel are mature. Bespoke integrations are where projects die.

3. Maturity of the team that will operate the SIEM. Wazuh and ELK are cheap but need a team capable of maintaining the platform. Splunk and Sentinel are expensive but the vendor carries much of the operational load. If you do not have an internal team, contracting an MSSP or MDR to operate the SIEM for you is usually the most efficient call.

4. Priority use cases. Need strong UEBA from day one? Securonix or Exabeam stand out. Heavy compliance burden? QRadar has templates. Flexible threat hunting? Splunk and Elastic.

Common mistakes when implementing a SIEM

Three frequent ways to burn the budget:

  1. Ingest everything without filtering. The bill grows out of control and the analysts drown in irrelevant events. Filter noisy logs at the source and prioritise sources that deliver real detection value.
  2. Generic vendor rules without adaptation. Out-of-the-box rules generate thousands of false positives in any real environment. Continuous detection engineering is what makes the SIEM useful.
  3. No team to operate the alerts. A SIEM without analysts responding to alerts is an expensive event repository. If you are not going to build a SOC, contract a managed one.

Frequently asked questions

What is the difference between a SIEM and a SOC?

The SIEM is the platform; the SOC is the team and processes that operate it. A SIEM without a SOC produces alerts nobody investigates. A SOC without a SIEM cannot correlate events at scale. They work as a pair.

How much does a SIEM cost?

Costs vary enormously with event volume and pricing model. Wazuh is free (you only pay operation). Splunk and Sentinel can range from a few thousand to tens of thousands of euros a month depending on volume. The real bill depends on ingestion filtering, retention and add-ons. The reasonable move is to run a POC with your real volume before committing to a licence. For broader pricing logic see penetration testing pricing in Spain.

What is a cloud-native SIEM?

A SIEM designed to operate natively in the cloud, with consumption-based pricing and automatic scaling. Microsoft Sentinel is the clearest example. It removes the cost of maintaining your own infrastructure and usually integrates better with cloud services (CloudTrail, Azure Activity, Google Cloud Audit).

Does an open source SIEM like Wazuh work for a mid-sized company?

Yes, with conditions. Wazuh covers detection, file integrity monitoring, vulnerability management and basic compliance, and many public administrations and mid-market companies run it in production. What the free version trades is internal operation: you only pay for operating it, but you need a team that maintains the platform, tunes rules and handles alerts. If you do not have one, an MSSP that operates Wazuh for you is a common option.

How long do you have to keep logs in the SIEM?

It depends on the applicable framework. PCI DSS demands at least 12 months (with 3 months immediately accessible). ENS and GDPR set no single period, but common practice ranges from 6 to 24 months depending on criticality. NIS2 presumes traceability sufficient to investigate incidents, which in practice means at least 12 months.

Does the SIEM detect ransomware?

Yes, when properly configured. Rules detect typical patterns of modern ransomware: mass file encryption, shadow copy deletion, creation of suspicious processes, communication with known C2, privilege escalation and lateral movement. The SIEM, combined with an EDR, is the layer that shortens the time between the attacker's first move and containment.

SIEM at Secra

At Secra we run the SIEM inside our managed cybersecurity service, with the platform operated by our team, rules tailored to the client's sector and continuous detection engineering so coverage grows with the organisation. If you want a concrete proposal for your volume and current stack, get in touch through contact.

About the author

Secra Solutions team

Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

Share article