Five vendors, three quotes, and not one of them can be compared to another. One is priced per gigabyte a day. One is priced per node, with a separate number for “analytics.” One quotes credits, and nobody in the room can tell you what a credit buys. Your ingest estimate came from a colleague who said “probably 200 gig a day?” in a meeting, and that guess is now load-bearing for a three-year contract.
Stop the bake-off. The product comparison is not where this goes wrong.
Almost every SIEM regret traces back to one of three things decided before anyone opened a vendor deck: the ingest volume nobody forecast honestly, the fact that no one was funded to tune it after go-live, and buying a platform when the business actually needed a managed service. Get those right and several products on your shortlist will work. Get them wrong and the best SIEM on the market becomes an expensive, noisy log archive that one overloaded person logs into on Tuesdays.
Here is how to choose a SIEM in the order that actually protects you.
Answer three questions before you look at a single product
Write the answers down and send them to whoever signs the cheque. If you cannot answer all three, you are not ready to shortlist.
1. Who runs this day to day, and for how many hours a week? Not “the security team.” A name, and a number. If the honest answer is “Priya, about six hours a week, between her other job,” that is a legitimate answer, and it disqualifies most of what you are about to be shown. Six hours a week buys triage of a small, well-tuned alert set. It does not buy content development, source onboarding, parser maintenance, or overnight coverage.
2. What is your realistic daily ingest in GB, and how fast does it grow? Measure, do not guess. Most sources report their own volume before you buy anything: your EDR console, your firewall management platform, your cloud provider’s audit log metrics, your domain controllers. Pull thirty days from each, add it up, then apply a growth factor you can defend. Ingest rises with headcount, with every new SaaS app that ships logs, with every cloud account someone spins up, and with every vendor upgrade that adds verbosity you did not ask for. A three-year contract sized to today’s volume is one you renegotiate from a weak position.
3. What retention do you owe, and to whom? A legal question, not a technical one, and the answer shapes the architecture. If you take card payments, PCI DSS v4.0.1 Requirement 10.5.1 is explicit: retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. That single sentence defines a two-tier storage design. Your own customer contracts may impose longer clocks than any regulator does. NIST’s draft revision of its log management guidance treats retention as a per-source decision rather than a blanket policy.
The pricing models, and how each behaves as you grow
Vendors compete less on price than on which variable they charge against. Pick the model whose variable you can control and whose growth curve matches your own.
- Per-GB ingested. The most common model, and the most brutal when sizing is wrong, because cost scales with the thing you control least. Microsoft Sentinel bills on daily ingestion in GB, with pay-as-you-go rates and commitment tiers reserving daily capacity from 100 GB up to 50,000 GB for a fixed daily fee. Read the mechanics: commitment tiers are billed whether or not you use the capacity, overage bills at the same discounted rate, and a 31-day minimum applies before you can step down.
- Per-node, per-endpoint or per-user. Predictable, budgets cleanly, mostly immune to a chatty log source. Different trap: volume can triple with no licence change while the platform quietly falls over, or the vendor meters something adjacent instead. Read what counts as a node, and whether a container counts.
- Credits or consumption. Sumo Logic prices in credits consumed across ingest, retention and data scanned by queries. Decoupling storage from use helps if you hold large low-value data and search narrowly. It also means an analyst running a wide hunt across a year of data creates cost. Ask what that looks like during an incident.
- Capacity or resource-based. Elastic prices hosted deployments on allocated compute and storage, and self-managed licensing on nodes and RAM. Flat capacity suits volatile ingest plus real infrastructure skill, and moves cost from the licence line to the headcount line, which is still a cost.
- Packaged tiers. Google Security Operations sells Standard, Enterprise and Enterprise Plus with ingestion-based pricing and 12 months of telemetry retention included, and those tiers gate capability, not just capacity: the permitted number of single-event and multi-event detection rules differs by tier, as does how much pipeline filtering and transformation you get. Splunk publishes several models at once, including ingest, workload, entity and activity-based pricing.
Now the trap that catches everyone. A handful of sources produce most of your volume and a small minority of your detections: firewall logs with accepts enabled, DNS query logs across a large estate, raw endpoint telemetry at full fidelity, cloud audit logs once object-level data events are switched on. Any one can exceed everything else combined. On a per-GB model, one engineer enabling verbose logging in a change window moves your monthly bill, and nobody notices until the invoice. So make ingest volume by source a monitored metric with an alert on day one, before you have a single detection.
Ingest what detects, not everything you can reach
The default failure mode is collecting everything “so we have it.” SANS’s 2025 SOC Survey, written by Christopher Crowley, found 42% of SOCs dump all incoming data into a SIEM, often with no retrieval or management plan. Self-reported survey data, so hold the precision loosely, but the pattern will be familiar to anyone who inherited a SIEM.
NIST’s draft SP 800-92r1 offers a better discipline: decide, for each log source type, whether it is required, recommended, not recommended, or prohibited. That fourth category is the one people forget exists. Some logs cost more than they detect and should be excluded on purpose, with the reasoning written down so the argument is not re-litigated every quarter.
The order in which sources usually earn their place:
- Identity. Authentication, MFA events, privilege grants, conditional access, directory changes. Most intrusions touch identity and the volume is modest against the detection value.
- Endpoint detection telemetry. Process execution, command lines, persistence. Send detections and high-value process telemetry, not always the full raw stream.
- Cloud control plane audit logs. Management events. Add data events only when a specific detection needs them.
- Email security and remote access. Delivery, quarantine and click events; VPN and ZTNA sessions. The initial-access story lives here.
- Only then the network firehose: DNS, proxy, firewall. Investigation fuel more than detection fuel, and it can live somewhere cheaper.
That last distinction is the whole game. Data you detect on must be hot, parsed and indexed, which is expensive. Data you investigate with needs to be findable within an hour. Data a regulator wants needs to be retrievable within days. Three tiers, three unit costs. Push back on any vendor pricing all of it identically.
Build, buy, or hand it to someone else: the shift arithmetic
This decision is usually made by default. It deserves a spreadsheet. A week has 168 hours. One full-time analyst is contracted for about 40 of them, and after leave, training, sickness and meetings the on-console figure is lower. Continuous single-analyst coverage therefore needs roughly 4.2 FTE minimum, before anyone is ill, on holiday, or resigning. Refuse single-person night shifts and that doubles. Add a shift lead, a detection engineer, and someone owning platform health and source onboarding, and a genuinely self-run 24/7 SOC lands in the high single digits to low teens of headcount. That is arithmetic, not a benchmark, and it does not bend because your budget is smaller.
The SANS numbers show the squeeze: 79% of respondents said their SOC runs 24/7, while 2 to 10 people was the most common size for a fully staffed SOC. Those facts only reconcile if much of that “24/7” is on-call rotation, a provider, or optimism. Decide which you are buying.
- Self-run SIEM. You own the licence, the tuning and the roster. Right when you have the headcount, unusual detection needs, or residency constraints.
- SIEM plus MSSP. You own the platform and the data, a provider watches it out of hours or around the clock. Keeps portability and the content you build. You still own integration, and you need a hard definition of who escalates what and what “response” means contractually.
- Co-managed or fully managed detection and response. Provider brings platform, content and analysts. Fastest to a working outcome, least internal drag, least control. Ask whether you can export your data, whether detection content is yours or theirs, and what exit looks like at renewal.
Detection engineering is the real cost centre
The licence is the visible cost. The ongoing cost is people writing, testing and retiring detections, and when that work is unfunded the platform degrades on schedule.
Out-of-the-box rule packs are a starting point and nothing more. Written for a generic environment, a rule that is sensible in the abstract fires forty times a day because of your backup service account, your vulnerability scanner, or your remote support tool. Leave it untuned for a quarter and analysts learn to close those alerts unread. You have then bought alert fatigue at enterprise pricing. Budget the first ninety days after go-live as a tuning project with a named owner and allocated hours, not “we’ll tune as we go.”
Two practices make it sustainable. First, map detections to MITRE ATT&CK, so coverage becomes a conversation about adversary behaviour instead of rule counts. ATT&CK is free, and it is moving in a direction that helps buyers: the v18 release of 28 October 2025 replaced per-technique detections with Detection Strategies and Analytics as first-class objects, shipping 691 Detection Strategies and 1,739 Analytics for Enterprise and deprecating Data Sources in favour of updated Data Components. That gives you a precise vendor question: which analytics do your shipped rules implement, and which data components do they require? If their content needs telemetry you decided not to ingest, their coverage claim does not apply to you.
Second, treat detections as code. Rules in version control, peer reviewed, tested against sample telemetry, deployed through a pipeline, each with an owner and a retirement date. That is the difference between a detection library and a pile of rules nobody dares delete. It also makes the migration below survivable.
Pipelines, migration and lock-in
Telemetry pipelines. A pipeline layer sits between sources and SIEM, filtering, reducing and routing before data hits a metered ingest point. Five years ago this was exotic. It is now part of the SIEM decision, and the platforms admit it: Sentinel offers a lower-cost data lake tier alongside its analytics tier, and Google SecOps gates pipeline filtering, redaction and routing by package tier. If your platform is weak here, price a standalone pipeline tool into the business case rather than discovering the need later. Anything you drop before ingestion is money you never spend.
Migration. Replacing an existing SIEM means paying for both during a parallel run, rebuilding parsers, porting detections, retraining analysts, and either migrating history or keeping the old system read-only until its retention obligation expires. That last one catches people: you often cannot switch the old SIEM off on cutover day, because the twelve months of history you must retain still lives in it. Ask the incoming vendor, in writing, what migration help is included. Some build for this, as Google’s Enterprise Plus tier does with 12 months of routing to another destination for migrations.
Lock-in. If your estate is overwhelmingly one cloud and one endpoint vendor, that vendor’s native SIEM usually means cheaper integration, content that matches your telemetry, and sometimes discounted ingest of first-party logs. Sentinel includes an allowance of free daily ingestion per user for certain Microsoft 365 security logs. Those discounts are real and a legitimate reason to choose. The cost is optionality: proprietary rule languages do not travel, normalised schemas do not travel, and when one vendor supplies your identity platform, your endpoint agent and your SIEM, your renewal has no leverage in it. That platform also shares a control plane with the estate it monitors. Neither answer is wrong. Price the lock-in rather than ignoring it.
Questions to put to the vendor
- What exactly is metered, and in what unit? Get ingest, storage, search, retention, users and connectors itemised separately.
- Can I filter or route data at the collector, and does that reduce the bill?
- What happens the day I exceed my commitment or tier: throttled, dropped, or billed, and at what rate?
- Which of my log sources are free or discounted, and does that apply to raw or normalised data?
- What is the price in year two and year three, and what caps the uplift contractually?
- What is hot retention, what is cold, what does rehydration cost, and how long does it take?
- Can I export all my data and my detection content on exit, in what format, at what cost, within what window?
- Which ATT&CK analytics do your shipped detections implement, and which data components do they need?
- Out of the box, how many alerts a day should a customer of my size expect, and who does the tuning in the first ninety days, me or you? If you, is it in the price or a services line?
A good vendor answers the pricing questions with numbers and the tuning questions with a methodology. A bad one answers both with the word “AI.” No written answer on overage behaviour and exit terms is on its own a reason to walk. And run the proof of concept on your own data, never a vendor sandbox, with success defined as “did it detect the three things we care most about, and what did that cost in false positives.” Feature demos are theatre. Your noisy telemetry is the truth.
Questions buyers ask next
Is an open-source SIEM actually cheaper? The licence is. The total often is not, because you absorb infrastructure, storage, upgrades, parser maintenance and detection content as engineering work. A real saving if you already have that capability in-house, an expensive way to save money if you do not.
How do I forecast ingest before I own a SIEM? Pull thirty days of volume from each source’s own console, add them, rank by GB, and treat vendor sizing calculators as a floor rather than an answer. Then run a two-week collection trial on your three noisiest sources before signing, because those three decide whether your estimate is roughly right or catastrophically low.
What if we buy a SIEM and nobody watches it overnight? Then you own an investigation tool and a compliance archive, both worth having, and you should call it that rather than let anyone believe you have monitoring. Fund coverage, buy it from a provider, or write down the accepted risk with a named owner and a review date.
If the honest answer to question one is that nobody has the hours, that is a staffing problem wearing a tooling costume, and a bigger platform will not fix it. AB7 Solutions provides SOC analysts and co-managed monitoring cover, detection engineering and tuning support, and VAPT and firewall and server security work, including the out-of-hours shift cover that makes the arithmetic above add up. For a second opinion on a quote in front of you, or on whether your ingest estimate survives contact with reality, call +1 321 341 7733, email ab@ab7solutions.com or director@ab7solutions.com, or start at www.ab7solutions.com.
Sources: NIST, SP 800-92, Guide to Computer Security Log Management (final, September 2006) and SP 800-92r1, Cybersecurity Log Management Planning Guide (initial public draft, October 2023, still in draft at the time of writing); MITRE, ATT&CK v18 release notes (28 October 2025) and ATT&CK version history (v19.2 current, 28 April 2026); PCI Security Standards Council, PCI DSS v4.0.1, Requirement 10.5.1; vendor pricing pages consulted for pricing models only: Microsoft Sentinel, Splunk, Sumo Logic, Elastic, Google Security Operations; Christopher Crowley, SANS 2025 SOC Survey (July 2025, self-reported respondent data).
Related reading
Related AB7 service: cybersecurity services (managed SOC, VAPT).