A SIEM collects logs from many systems, normalizes them, correlates events and raises alerts. To evaluate SIEM tools, do not compare feature lists. Feed each candidate your real log sources for two weeks, replay a handful of known events, and measure what it caught, what it missed and how much work tuning took.
What is a SIEM supposed to do?
NIST SP 800-92, the guide to computer security log management, frames the underlying job: generate logs, transport them, store them, analyze them and dispose of them under a policy. A SIEM automates the middle of that chain. The hard parts are unglamorous: getting logs in, parsing them consistently and keeping them long enough to be useful.
Why do feature lists mislead?
Every product claims correlation, dashboards and threat detection. The difference shows up when your actual sources arrive. A firewall that logs in a format the tool does not parse produces events that nothing can match. A cloud audit log sent with a delay of minutes breaks any rule that depends on sequence.
A trial plan with five test events
Pick sources first: identity provider, endpoint agent, cloud audit logs, VPN or firewall, and one business application. Then create these events in a test account and see what each tool does with them. They are constructed examples; adapt them to your stack.
- Impossible sign in. One user signs in from two distant locations within an hour.
- Privilege change. A test account is added to an administrator group at night.
- Mass download. A test user pulls hundreds of files in a few minutes.
- Disabled logging. A test cloud trail or audit setting is switched off.
- New persistence. A scheduled task or startup entry is created on a test endpoint.
For each, record whether an alert fired, how long it took, whether the alert held enough context to act without opening five other consoles, and whether it matched a rule you wrote or one that shipped with the product.
What costs surprise buyers?
- Ingestion volume. Noisy sources, such as debug logs, can double volume. Check how the tool is metered before you connect everything.
- Retention. Hot search for 30 days and archive for a year are different prices and different speeds. Decide what you must keep for audits and for investigations.
- Parsing upkeep. Each new log format needs maintenance. Ask who writes parsers and how fast.
- Staff time. A tool with no one tuning it turns into an alert pile.
What should the first month after purchase look like?
Resist enabling every rule at once. Turn on a small set tied to the five test events, route them to a named analyst and check that each alert holds enough context. Add sources one at a time, confirming the parsing before moving on. Keep a log of tuning changes with the reason, so that next year's team knows why a rule was muted.
Plan a quarterly review of rules that have never fired. Some are correct and quiet. Others silently broke when a log format changed.
How to check or apply this
- List your log sources and rank them by the decisions they support.
- Write retention requirements from your regulatory and investigation needs.
- Run each candidate with the same sources for two weeks.
- Replay the five events and score each tool on detection, speed and context.
- Count analyst hours spent on setup and tuning.
- Test export: can you get your logs and rules out in a usable form?
- Check time synchronization across sources, since correlation depends on it.
Quick check
Do you need a SIEM if you already have endpoint detection?
They see different things. Endpoint tools watch hosts. A SIEM brings identity, cloud, network and application logs together. Many teams need both over time, but start with the gap that hurts most.
How long should SIEM logs be kept?
It depends on your regulatory and investigation needs. Intrusions are often discovered long after they begin, so keep identity and cloud audit logs longer than low value ones.
Sources
Last reviewed: 18 October 2026.
