Choosing a SIEM usually starts with a feature spreadsheet and ends with a license bill nobody saw coming. The right question is not "which SIEM has the most features" but which threats do I need to detect, with which data, and who will act when the alert fires.
What a SIEM does, and what it does not
A SIEM (Security Information and Event Management) collects events from many sources, normalizes the data, keeps the history and applies correlation rules to raise alerts. NIST covers the foundations in SP 800-92, Guide to Computer Security Log Management, and in its draft revision, the Cybersecurity Log Management Planning Guide (SP 800-92 Rev. 1, 2023), which defines log management as the process of generating, transmitting, storing, accessing and disposing of log data.
What a SIEM does not do on its own: decide which logs matter, write and tune rules for your environment, investigate an alert and contain an attack. Those parts depend on people and process.
Before comparing products: define what you want to detect
Best Practices for Event Logging and Threat Detection, published in August 2024 by Australia's ASD's ACSC together with CISA, the FBI, the NSA and partners from other countries, organizes the topic around four points: an enterprise-approved logging policy, centralized log collection and correlation, secure storage with log integrity, and a detection strategy focused on relevant threats.
In practice, that means listing your critical assets, the attack scenarios that worry you most (ransomware, credential theft, fraud, data leakage) and the sources that reveal each of them. That list becomes your evaluation criteria.
The criteria that really matter
- Sources and parsers. Check for maintained connectors and parsers for what you use: firewall, EDR, Active Directory and identity provider, cloud (IaaS and SaaS), email, VPN, databases and in-house applications. A log that arrives without being parsed correctly is useless for correlation.
- Licensing model. The most common models charge by ingested volume (GB per day), events per second (EPS), asset or user. Each has side effects: volume-based pricing discourages sending useful but verbose logs; EPS pricing penalizes spikes. Model the cost with your real volume and expected growth, not the vendor's estimate.
- Retention and storage cost. Separate "hot" retention, searchable on demand, from long-term retention, cheaper and slower. Investigations often need to look months back, because an attacker may have been in the environment for a long time before being detected.
- Detection content mapped to MITRE ATT&CK. Out-of-the-box rules help, but what matters is documented coverage: which ATT&CK techniques have detections, from which sources, and how easily you can build and test your own rules.
- UEBA. User and entity behavior analytics helps uncover misuse of valid credentials that static rules miss, but it needs a baseline and tuning.
- SOAR integration. Check whether the SIEM triggers enrichment and response playbooks (isolate a host, disable an account, open a ticket) natively or through integration, and with what approval controls.
- Cloud or on-premises. A cloud SIEM reduces infrastructure work and scales more easily; on-premises may be required by data residency rules or internal policy, but brings the cost of hardware, upgrades and high availability.
- Compliance and legal retention. Map the requirements that apply to you. In Brazil, for example, the Internet Civil Framework (Law 12,965/2014) requires connection providers to keep connection records for one year and application providers to keep access records for six months. Regulated sectors such as finance have their own rules. The SIEM must ensure integrity and access control over those records.
How to run a useful proof of concept
A proof of concept (PoC) is only worth it if it uses your environment. A lean script:
- Pick three to five attack scenarios tied to the risks you listed, such as brute force followed by a successful login, an unusual new admin account and lateral movement.
- Connect the real sources behind those scenarios and measure the integration and parsing effort.
- Simulate the techniques in a controlled way and check whether the alert appears, with what context and how fast.
- Measure the noise. How many alerts per day the environment generates and how many deserve investigation.
- Project the three-year cost with real volume, retention and growth, including storage and staff hours.
In May 2025, CISA and ASD's ACSC, with partners, published guidance specifically for organizations procuring SIEM and SOAR, with versions for executives and for practitioners, plus a guide on prioritizing logs for SIEM ingestion.
Common pitfalls
- Ingesting everything "just in case". It raises cost and noise without improving detection. Start with priority sources and expand deliberately.
- Ingesting too little to save money. The opposite also fails: without identity, endpoint and cloud logs, the SIEM cannot see the most common stages of an attack.
- Turning on default rules and forgetting them. Without tuning, false positives pile up and the team starts ignoring alerts.
- Not defining who responds. An alert with no owner, outside business hours, is a lost alert.
Why a SIEM alone is not enough
Detection happens in three layers: data, analysis and action. A SIEM handles the first well and part of the second. The rest depends on:
- People. Analysts who triage, investigate, hunt for threats that have not yet raised an alert (threat hunting) and tune rules after every false positive.
- Process. Severity criteria, playbooks, escalation and integration with the incident response plan, aligned with NIST SP 800-61 Rev. 3.
- Continuous coverage. Attacks do not keep office hours. A critical event at 3 a.m. on a Saturday needs someone watching at that moment.
How XDR, Open XDR and a 24×7 SOC complete the picture
XDR (Extended Detection and Response) focuses on actionable detection and response: it correlates signals from endpoint, network, cloud, identity and email, groups events into incidents with context and triggers containment actions. Open XDR does this openly, integrating the tools the company already has, including the SIEM itself, without locking operations into a single vendor.
At Network Secure, the Open-XDR platform is the core that connects our services: it ingests telemetry from multiple sources, uses artificial intelligence to correlate signals and rebuild an attack timeline, and triggers response through playbooks, with the SOC operating 24×7 and human validation when needed. Network Secure's SOC is ISO/IEC 27001:2022 certified. To see what to expect from that operation, read Traditional SOC vs. modern SOC and our SOC and MDR service.
Frequently asked questions
What is the difference between SIEM and XDR?
A SIEM centralizes logs and correlates them with rules, with a strong role in retention and compliance. XDR focuses on detection and response, with cross-layer correlation and automated actions. The two can coexist, and XDR can consume SIEM data.
How do I estimate the cost of a SIEM?
Measure the real event volume from priority sources over a few weeks, apply each vendor's licensing model, add the required retention and expected growth, and include the staff hours needed to run the platform.
Which logs should I prioritize first?
Usually identity and authentication, endpoint (EDR), firewall and VPN, cloud services and email, because they cover the most common stages of an attack.
Sources consulted: NIST SP 800-92, Guide to Computer Security Log Management (2006), and NIST SP 800-92 Rev. 1 (draft), Cybersecurity Log Management Planning Guide (2023); ASD's ACSC, CISA, FBI, NSA and partners, Best Practices for Event Logging and Threat Detection (August 2024); CISA, ASD's ACSC and partners, Implementing SIEM and SOAR Platforms and Priority Logs for SIEM Ingestion (May 2025); MITRE ATT&CK; NIST SP 800-61 Rev. 3; Brazilian Law 12,965/2014 (Internet Civil Framework), arts. 13 and 15. This article is educational; the suggested criteria do not replace a technical assessment of your environment or legal advice on data retention.