Most SIEM platforms are chosen on a demo and regretted at the first renewal, when ingestion has doubled, the detection library turns out to need weeks of tuning, and leaving means rewriting years of content. The market spans SaaS, self-managed and data lake designs, priced on gigabytes, compute, events per second or entities. This vendor-neutral buyer's guide is for SOC leads, security architects and procurement teams writing requirements, scoring an RFP or planning a proof of value. The SIEM Guide covers how a SIEM works and is run; this page covers what to require, ask and test before you sign.
Key takeaways
- Price your data, not the licence. Joint CISA and ASD guidance notes that "Most SIEM pricing models are based on the quantity of data the SIEM ingests" and tells buyers to look for hidden costs. Price your measured sources under each model.
- Coverage claims need evidence. An ATT&CK heatmap shows rules that exist, not rules that fire on your data. Emulate techniques in the proof of value and count alerts.
- Normalisation and detection as code decide portability. Parsers that map to an open schema such as OCSF or ECS, and rules kept as code in a format like Sigma, cut the cost of the next migration.
- Identity telemetry is where many intrusions show first. Score how the platform ingests and models identity provider, directory and cloud sign-ins, including service principals, managed identities and API keys, not only human users.
- The SIEM is a high-value target. It holds your logs, connector credentials and API tokens. Score its own admin security, audit logging and API controls as hard as its features.
Define requirements
The first procurement principle in the joint Implementing SIEM and SOAR platforms practitioner guidance is to "develop a proof of concept (POC)" before investing. Write these answers down first.
- Use cases and sources: the detections and investigations you need in year one, and the sources behind them. Measure daily volume for your ten largest sources over a month, including peaks.
- Retention by tier: how many days each source must stay hot and searchable, how long it must be kept in total, and legal hold needs. See the Log Management and Retention Guide.
- Data location: hosting regions, sub-processors and where support staff sit. NCSC's cloud security principles say asset protection should account for "the legislation that your data is subject to".
- People: who will run the platform and write detections. The executive guidance warns that "multiple personnel will need to work on implementing the SIEM and/or SOAR on a full-time basis".
- Integrations: EDR, identity threat detection, ticketing, threat intelligence, any log pipeline layer and SOAR. The same guidance advises "Properly implement a SIEM before you consider implementing a SOAR". See the SOAR and Security Automation Guide.
- Content to migrate: count rules, searches and dashboards in active use; this sizes the migration.
| Deployment model | Strengths | Trade-offs | Usually fits |
|---|---|---|---|
| Cloud-native SaaS | No cluster operations, elastic scale, vendor-maintained parsers and content | Regions and upgrade timing set by the provider; cost follows ingestion or compute | Most organisations without platform engineers |
| Self-managed (on-premises or your own cloud) | Control of data location, retention and cost at scale; isolated or classified networks | You size, patch, scale and back up search clusters | Regulated or high-volume estates with engineering capacity |
| Data lake plus analytics | Cheap storage, often in open columnar formats such as Apache Parquet; query in place; separate detection tier | Lake tiers search more slowly and may not support real-time rules; more components to run | Long retention and bulk telemetry |
| Bundled with a platform licence | Low entry cost; deep integration with that vendor's telemetry | Third-party source support and retention may be limited | Estates standardised on one security platform |
The practitioner guidance asks buyers to "Consider a SIEM product with a data lake architecture" and notes that some platforms "are designed to integrate with other products made by the same vendor". Small organisations are usually better served by SaaS or a bundled SIEM; data lake designs pay off at large volumes.
| Pricing model | What is counted | Cost risk | What to fix in the contract |
|---|---|---|---|
| Ingest volume | Gigabytes or terabytes per day ingested | Verbose defaults, noisy network sources, incident log storms | Whether filtered data is billed; overage rates |
| Events per second | Peak or average EPS | Bursty sources and incident spikes | How peaks are measured; burst allowance |
| Compute or query | Search and analytics compute | Heavy hunting, scheduled searches, AI assistant queries | Query budgets, alerts before limits, throttling behaviour |
| Entity or asset | Users, employees, endpoints or workloads | Growth in workloads and service accounts if they count as entities | Written definition of an entity |
| Storage and rehydration | Retained data and archive restores | Long retention; investigations restoring old data | Rehydration price and time |
The practitioner guidance warns that "Some SIEM platform default settings and recommendations will tend to increase the quantity of logs that are ingested" and that competitive licence prices may be negated by implementation costs. Require per-source billing reports, budget alerts and unbilled pre-ingest filtering.
Evaluation criteria
An illustrative weighting is 25% detection, 20% data and cost, 15% search, 15% platform security and 25% the rest; adjust it to your requirements.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Parsers and normalisation | Maintained parsers for your sources; fields mapped to a documented schema such as OCSF (a "vendor-agnostic core security schema") or the Elastic Common Schema; unparsed event reporting | "Supported" means raw text; one field named differently per source (the guidance's example: "src_ip" and "sourceAddress") |
| Tiering and retention | Per-source hot, lake and archive tiers; documented features lost per tier; known rehydration time; immutable option | Archive restores only by support ticket; retention priced per day with no tiers |
| Detection content and coverage | Each rule lists the data sources and fields it needs, its ATT&CK technique and, where relevant, the ATT&CK detection strategy (DET IDs); test evidence | Coverage percentages with no data requirements behind them |
| Detection as code | Full rule lifecycle through an API; version history; test before deploy; rollback; import or conversion of Sigma rules. See the Detection Engineering Guide | Rules editable only in the console; no export |
| Search performance | Predictable 7, 30 and 90 day query latency at your volume; cross-source correlation | Benchmarks quoted on demo data only |
| UEBA and identity analytics | Baselines and peer groups for users and non-human identities; entity resolution across directory, IdP and cloud; risk scoring an analyst can explain | Black-box scores; service accounts excluded or treated as users |
| SOAR and case management | Two-way case sync, enrichment and response actions with approval steps | One-way alert forwarding only |
| AI assistants | Shows the generated query and source events; respects roles; states where prompts are processed and whether data trains models | Answers without evidence; usage costs not disclosed |
| Platform, admin and API security | SSO and phishing-resistant MFA included; granular roles down to data sets; customer-visible audit log of searches and changes; scoped, expiring API tokens; IP restrictions; customer-managed keys option | SSO or audit logs sold as add-ons; long-lived admin API keys |
| Openness and exit | Bulk export of data, rules and cases in documented formats; full API | Export priced punitively or limited to the UI |
Where identity fits
Identity connectors often miss the non-human part. Microsoft Entra, for example, separates four sign-in log types: interactive user, non-interactive user, service principal and managed identity sign-ins, and notes that "The legacy sign-in logs experience only includes interactive user sign-ins." Check connectors collect all of them, and equivalent workload and API activity from clouds and SaaS. Service accounts and workloads behave predictably, so a new source address, new API calls or an interactive sign-in (abuse of valid cloud accounts, ATT&CK T1078.004) is a strong signal, if the UEBA baselines non-human identities separately rather than as users. The SIEM also creates its own non-human identities (collectors, cloud roles, OAuth apps, API keys); require federated or short-lived credentials. The Sumo Logic breach showed how one compromised credential at a log analytics provider led to customer-wide advice to rotate keys. See the ITDR Guide and the Service Account Security Guide.
Questions to ask vendors
- Using our measured volumes for the top ten sources, what will year one and year three cost, including retention, rehydration, AI assistant use and overage?
- Which of our sources have maintained parsers, to which schema, and how are unparsed events reported?
- Can we export your detection library with each rule's required data sources and ATT&CK mappings, to check coverage against what we collect?
- Can we manage every rule from our own repository through an API, test it before deployment and roll it back? Do you import or convert Sigma?
- What latency should we expect for a 30-day search across identity and endpoint data at our volume, and how are lake or archive tiers queried?
- What does the AI assistant send to which model, where is it processed, and can analysts see the query and events behind each answer?
- Are SSO and MFA included at no additional cost, as CISA's Secure by Demand Guide asks? Is there a customer-visible audit log of searches, rule changes and API token use?
- At contract end, how do we export data, rules and cases, in which formats, and at what cost?
Red flags
- Quotes built on the vendor's volume estimate rather than your measured data, with no cap on overage.
- ATT&CK coverage claims with no list of required data sources and no test evidence.
- A proprietary query language with no export or conversion path for rules.
- SSO, MFA or the platform's own audit log sold as premium features. Secure by Demand says SaaS providers should "make available to customers security logs for at least six months at no additional charge".
- AI features that cannot show evidence or send data outside your region.
- No built-in alert when a source goes silent. ATT&CK T1685 covers adversaries "interfering with logging pipelines and forwarding mechanisms (e.g., SIEM ingestion)".
Proof of concept
- Scope and pass criteria: four to six weeks; your IdP, EDR, a cloud control plane, one high-volume network source and one custom application log. Agree pass marks first; the guidance expects an evaluation process "to determine if the POC was successful".
- Your data at real volume: fork a copy of production logs from your collectors or pipeline for at least two weeks, leaving the current SIEM untouched. Compare billable volume with raw volume. Rollback is simply stopping the fork.
- Parsing quality: for each source, check that key fields (user, source address, action, outcome, target) are normalised and record the unparsed event rate.
- Detection: emulate 10 to 15 techniques that matter to you in a test environment, for example T1110.003 Password Spraying against the IdP, a service account signing in interactively, and T1685.002 Disable or Modify Cloud Log. Record which alerted, how fast and with what context.
- Detection as code and migration: port five existing rules through the API or a Sigma conversion, deploy them from your pipeline, then roll one back.
- Investigation and AI: time analysts on the same hunts over 30 and 90 days, then repeat with the AI assistant and check its answers against the raw events.
- Platform security and exit: enforce SSO and MFA, create a scoped API token, confirm the audit log records searches and rule changes, stop one collector and time the health alert. Then export data and rules, revoke connector credentials and request written tenant deletion.
Score the trial on numbers to keep tracking after go-live: billable volume against forecast, percentage of events parsed, techniques detected out of those emulated, median 30-day query time, and analyst minutes per investigation.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: SIEM Guide · Log Management and Retention Guide · Detection Engineering Guide · ITDR Buyer's Guide · MDR Guide