SIEM Tools: How to Evaluate a SIEM Platform

What must a SIEM tool do?

At minimum, a SIEM tool must collect logs from all relevant sources, normalize them into a common schema, detect threats through correlation and other analytics, alert with a useful priority, and retain data for investigation and audit. A product that misses any of these is a log store or a point tool, not a SIEM.

Feature matrices are of limited help, because almost every vendor ticks the same boxes. What separates SIEM software in practice is how well each capability works on your data, how much effort it takes to keep running, and how the cost behaves as you grow. The baseline capabilities to verify are:

• Collection over standard methods (syslog, REST APIs, agents, file collection) and integrations for cloud services.
• Parsing and normalization, with the ability to add custom parsers.
• Correlation rules, threshold and sequence detection, threat intelligence matching and anomaly detection.
• Alert management with severity or risk scoring, deduplication and suppression.
• Fast search, investigation timelines and case or incident management.
• Retention with integrity protection, plus reporting for audits.
• Role-based access control and an audit trail of analyst actions.

Keep the shortlist short. Two or three products tested properly tell you more than ten compared on paper, and a good proof of concept needs real effort from your own team as well as from the vendor's.

How do you evaluate data source coverage and parsing?

Start from your own inventory: list every log source you need, then check how each SIEM collects and parses it. A source that arrives but isn't parsed into usable fields can't drive detections, so parsing quality matters as much as connectivity.

Collection methods differ by source. Network devices usually send syslog, cloud services and SaaS applications expose REST APIs, Windows hosts typically need an agent or an event forwarding setup, and legacy applications may only write local files. A good SIEM supports all of these without forcing you to build and maintain glue code.

What to check

• Out-of-the-box parsers — are your firewall, identity, endpoint and cloud sources parsed into named fields, including the event types you care about?
• Custom parsers — can you write or request parsers for in-house applications, and how long does that take?
• Normalization schema — do fields like user, source IP, destination and action mean the same thing across every source, so one rule covers all your firewalls?
• Parsing failures — what happens to events that don't match a parser? They should stay searchable as raw data and show up as parsing errors, not disappear silently.
• Time handling — does it record both the event time and the time received, and handle time zones and clock drift correctly?

Joint guidance on SIEM and SOAR implementation from CISA, Australia's ACSC and partner agencies (2025) includes a separate document on prioritizing log sources for SIEM ingestion and advises building up the number and types of ingested sources gradually. That is a good way to run an evaluation, too: test your highest-value sources first and add the rest once they work.

How should you test correlation and detection?

Test detection with your own data and known attack scenarios, not the vendor's demo dataset. Look at how rules are written, how many useful alerts they produce compared with false positives, and how easily your team can tune them.

Correlation is the core of a SIEM: linking events across sources and time, such as failed VPN logins followed by a successful login and a privilege change on a server. Ask to see how a rule like that is expressed, and whether your own analysts could write, test and maintain it. It also helps if a new rule can be run against historical data first, to see how many alerts it would have produced.

Also check whether built-in rules are mapped to MITRE ATT&CK techniques, which makes coverage gaps visible, and whether alerts carry a severity or risk score that combines asset importance, indicator matches and user behavior. A SIEM that raises hundreds of equally weighted alerts a day will be ignored, however impressive its rule library looks.

Finally, follow one alert all the way through. From the alert, can an analyst see the related events, users, hosts and IP addresses, add notes, assign it and turn it into a case without switching tools?

How do you evaluate scale, performance and retention?

Size the SIEM for your peak event rate rather than your average, and for the retention period your policies require. Then measure search speed over long time ranges and confirm what happens when ingestion spikes or a component fails.

• Ingestion — measure your real daily volume per source and the peak events per second (EPS). Ask what happens above licensed or designed capacity: buffering, throttling, dropped events or overage charges.
• Search performance — run the queries you would use in a real investigation over 24 hours, 30 days and 12 months of data.
• Retention tiers — how long is data searchable at full speed, and how are older logs archived and restored?
• Integrity — can the platform show that archived logs haven't been altered, for example through hashing and trusted RFC 3161 timestamps?
• Availability — is there a high-availability cluster option, and can logs be replicated to a secondary site for disaster recovery?
• Collector resilience — can collectors buffer events locally when the central platform is unreachable, and resend them afterwards?
• Multi-tenancy — if you are a managed service provider or a group of companies, can tenants be fully separated?

NIST SP 800-92 names the number, volume and variety of log sources among the main challenges of log management, and it calls for protecting the confidentiality, integrity and availability of stored logs. Both points belong in your test plan: generate realistic load, then verify that the archive can prove it is complete and unmodified.

Retention requirements come from regulations, contracts and internal policy; our guide to log retention covers how to set them.

Should you choose a cloud or self-hosted SIEM?

Choose a cloud SIEM if you want the vendor to run the infrastructure and your logs may leave your environment; choose self-hosted if data residency, regulation or network isolation requires logs to stay on your own servers. Some products, including Logchase, offer both.

Regulation is often the deciding factor. Data protection laws such as the GDPR and Turkey's KVKK restrict transferring personal data, which logs frequently contain, to other countries, and some sector and national rules set their own logging and storage requirements. Check where a cloud vendor stores and processes data, and which of its staff can access it.

Hybrid setups are common too: collectors run on site and forward to a cloud SIEM, or a self-hosted SIEM handles sensitive sources while other data goes elsewhere. Whichever model you pick, ask how logs are encrypted in transit from collectors to the platform, and how you get all of your data back if you leave the vendor.

Self-hosting also means your team owns capacity planning, backups, upgrades and the security hardening of the SIEM itself, a system that holds sensitive data and that attackers would like to reach.

How are SIEM tools priced?

SIEM solutions are usually priced by data ingested per day, by events per second, by the number of log sources or devices, by users or employees, or as fixed packages. The right model is the one whose cost stays predictable as your log volume grows.

Whatever the model, build a three-year estimate that includes storage and retention, extra modules (threat intelligence, file integrity monitoring, SOAR), high availability, professional services and, above all, staff time to operate and tune the platform. Ask for a quote based on your measured volumes and source counts, including expected growth such as new cloud services or offices. Open source options have no license fee, but the operating effort is real, as discussed in open source vs commercial SIEM.

For reference, Logchase's on-premise packages (Core, Advanced, Enterprise and Elite) list EPS as unlimited and differ by the number of log sources, system users and included features such as file integrity monitoring, threat intelligence and disaster recovery.

What questions should you ask SIEM vendors?

Ask questions that force concrete answers about your environment: which of your sources are parsed today, how detections are built and tuned, what happens at peak load, how logs are protected, and what the total cost will be over three years. Vague answers are worth following up in the proof of concept.

1. Which of our log sources do you parse out of the box, and which need custom work? Can we see the field mapping?
2. How do we write, test and version our own correlation rules? Are built-in rules mapped to MITRE ATT&CK?
3. What happens to events when ingestion exceeds capacity or a collector loses its connection?
4. How long is data searchable at full speed, and how do we restore archived logs?
5. How do you prove that archived logs have not been modified?
6. Where is our data stored and processed, and who at your company can access it?
7. Which features require a higher tier or an add-on license?
8. What does a typical deployment involve, and how much ongoing tuning do customers do?
9. Can we run a proof of concept with our own data and attack scenarios?
10. How do we export all of our data if we leave?

To see how one platform answers these questions, you can explore the Logchase SIEM and its correlation, risk scoring and incident management features, or start with the basics in What is SIEM?.