Start by clarifying the need: SIEM or log management?
This should be every organization's first question. If your goal is simply to collect logs centrally, search them and keep timestamped archives for compliance, a centralized log management product may be enough. If you need correlation rules running on those logs, anomaly detection and alerting, what you need is a SIEM. We cover the differences in scope, cost and use cases in detail on the SIEM vs. log management comparison page.
A useful rule of thumb: if your security team looks at logs to answer "what happened?", you are at the log management stage; if the question is "what is happening right now, and should I respond?", you are ready for a SIEM.
10 criteria for choosing a SIEM
1. Log collection coverage
A SIEM is only as valuable as the data you feed it. Make sure the product you evaluate goes beyond Syslog: Syslog (UDP/TCP/TLS), NetFlow/sFlow, API-based collection, file ingestion over SFTP/SMB/FTP, database connections and optional agent support should all be available. Also ask which of the firewalls, servers and network devices in your environment are covered by ready-made parsers; every unsupported source means waiting for custom development.
2. Realistic EPS sizing
EPS (events per second) is the basis of both licensing and hardware sizing. Before buying, estimate your own environment's EPS and ask in writing what hardware the product needs to handle that volume. It should be clear how far a single server scales and at what point a cluster architecture is required. You can find example sizing tables on the OrianaSIEM technical specifications and EPS sizing page.
3. Query performance on historical data
Most SIEMs are fast on recent data; the real difference appears when you search logs from 6–12 months ago. Incident investigation and forensic analysis happen precisely on that older data. During the demo, insist on running queries against data that is months old. OrianaSIEM's patented Minimize technology answers queries independently of data age without needing an indexing database (0.95 ms on average in our internal tests); the same architecture also removes the CPU, RAM and disk overhead that indexing creates.
4. Correlation capability and the built-in rule set
Correlation is what separates a SIEM from log management. How the rules work matters as much as how many ship with the product: threshold-based, sequential-event and behavioral (UEBA) engines catch different attack patterns. OrianaSIEM comes with 6 advanced correlation engines and more than 3,500 ready-made correlation rules; being able to write your own rules from the interface is the key to creating value over time.
5. Regulatory compliance
Log integrity and trusted timestamps are core requirements in most regulatory frameworks — GDPR, NIS2, DORA, ISO 27001 and PCI DSS all expect reliable, tamper-evident records. Verify that the product meets these requirements natively, including timestamped archiving and controlled, audited access to logs that contain personal data; you do not want to depend on an external process when an audit comes. If you operate in Türkiye, confirm native support for Law No. 5651 record-keeping with 5070-compliant timestamping as well.
6. Data sovereignty and deployment model
Log data is among an organization's most sensitive assets. Where the data resides, who can access it and which jurisdiction it falls under can decide the choice on its own — especially in government, finance and critical infrastructure. The product should be able to run fully on-premises without sending data back to the vendor. We cover this topic in detail on the data sovereignty SIEM page.
7. Integrations: a SIEM should feed your SOC, not replace it
Your SIEM must not be an island. Check that its alerts can be forwarded to your SOC, SOAR and ticketing systems via Web API, e-mail or SMS, and that it can consume threat intelligence and enrichment sources. A good SIEM joins your existing operation — it does not ask you to rebuild it.
8. Total cost of ownership (TCO)
The license fee is only one part of the total cost. Over a three-year window, list all of it: the licensing model (EPS, source or user based), hardware requirements, disk growth driven by retention, installation and training, annual maintenance, and the staff effort to operate the product. Architectures without an indexing layer shrink the hardware line noticeably. For a first rough estimate, use the SIEM license and EPS calculator.
9. Vendor support and product roadmap
A SIEM is a living product: new log sources, new attack techniques, new regulations. Ask about the vendor's support SLA, release cadence and product roadmap. Direct access to the engineering team — OrianaSIEM is developed entirely in-house — can turn a critical requirement around in weeks instead of months.
10. Verifiable certification and references
Ask for evidence behind every claim in the sales deck: which product and version a certificate covers, the date of the test reports, references from organizations of similar scale. OrianaSIEM holds TRTEST A-Level certification (Türkiye) and runs 24/7 in more than 700 organizations today; demand the same verifiability from every product you evaluate.
8 questions to ask during the demo
- How many of the devices and applications in my environment are covered by ready-made parsers? What is the process for the rest?
- Can you run this search on 6-month-old data right now, in front of me?
- Will you put the recommended hardware for my EPS figure in writing?
- How many correlation rules ship with the product, and can I write my own from the interface?
- Is timestamped, tamper-evident archiving handled inside the product?
- How are alerts forwarded to our existing ticketing/SOAR systems?
- What is the licensing model, and how does cost change as my log volume grows?
- Can you document the scope of your certifications and test reports?
How to run the PoC
Once the shortlist is down to two or three products, the decision should be made by a PoC, not a presentation. For a PoC that actually works:
- Test with real data. Connect your own firewall and server logs, not the vendor's sample data set; parsing quality only shows on your own data.
- Define duration and scope up front. Set 2–4 weeks, 5–10 log sources and measurable success criteria (e.g. "scenario X must raise an alert", "a search across 6 months of archive must return in under Y seconds").
- Run real scenarios. Try 3–5 scenarios that fit your environment — failed logins, privilege escalation, out-of-hours access — identically on every product.
- Measure the operational load. Have your own team, not the vendor, run the product during the PoC; the person-hours daily operation requires matter as much as detection success.
- Score the outcome. Weight the 10 criteria above and score every product in the same table; walk into the decision meeting with that table, not a slide deck.
Conclusion
The right SIEM software collects your log sources completely, keeps its performance as data volume grows, meets your compliance obligations natively and integrates into your existing operation. Base your decision on a PoC run with your own data, not on brochures.
If you would like to test these criteria on OrianaSIEM, a next-generation SIEM, explore our live demo environment — no registration required — or request a demo to plan a PoC with your own data.
Last updated: November 1, 2026. Performance figures are internal test results and may vary by environment and configuration.