SIEM Total Cost of Ownership: What Actually Drives the Bill

SIEM Total Cost of Ownership: What Actually Drives the Bill

Most SIEM budgets are wrong in the same direction. The licence or subscription is the number that gets quoted, approved and tracked — and it is rarely the largest line. The costs that break SIEM projects are storage over the full retention window, the engineering to get the platform out of its noisy default state, and the people who look at what it produces. None of those appear on a vendor quote.

This is the model we use when sizing an engagement, in the order the numbers actually compound.

1. Daily ingest volume

Everything downstream scales from gigabytes per day. It is also the number organisations estimate worst, usually by a factor of several, because the estimate is made from the log sources people remember rather than the ones that generate volume.

The heavy sources are almost always the same: firewall and network device traffic logs, web server access logs, verbose cloud audit trails, and endpoint process-execution telemetry. The sources people think of first — application logs, authentication events — are usually a rounding error next to them.

Do this before anything else: instrument two weeks of real collection from a representative sample of each source type and extrapolate. An architecture sized on a guess is either an outage or a wasted cluster.

2. Retention, which multiplies it

Volume alone is not the storage bill. Volume multiplied by retention is, and retention is usually set by a framework rather than by preference:

• PCI DSS v4.0.1 (10.5.1): twelve months of audit log history, with at least the most recent three months immediately available for analysis.
• CERT-In (2022 directions): 180 days, maintained within Indian jurisdiction — a location constraint as much as a duration one.
• ISO/IEC 27001:2022: no fixed period; you justify it from your own risk assessment and then have to meet what you wrote.
• SOC 2: no fixed period, but a Type 2 observation window is typically three to twelve months and the auditor samples across all of it.

Note the shape of the PCI requirement: three months hot, twelve months retrievable. That is a two-tier architecture, and treating it as twelve months of hot storage is the single most common way to over-spend on a SIEM. Conversely, keeping thirty days because that is what fits on the disk is a finding no tuning can repair later — data you did not keep is gone.

3. Storage tiering, where the savings are

Hot storage is fast, searchable and expensive. Warm is slower and cheaper. Cold or archived storage is cheap and takes time to restore. Mapping the regulatory requirement onto those tiers — rather than keeping everything hot because it is simpler — is usually the largest single cost lever available, and it is a configuration decision, not a purchase.

The related lever is what you index. Raw archives kept for compliance do not all need to be in a searchable index; indexing has its own storage and compute overhead. Deciding what is searchable versus merely retained is worth doing deliberately.

4. The commercial pricing models, and why they feel unpredictable

Understanding how vendors charge explains the anxiety, and these are published models rather than anything specific to a deal:

• Per gigabyte ingested — the traditional model. The problem is not the rate; it is that your bill is a function of a number that grows every time someone enables debug logging or adds a load balancer. Budgeting is guesswork.
• Per endpoint or per user — predictable, which is why it is popular, but it decouples price from value in both directions.
• Per compute unit or workload — cloud-native platforms increasingly price the query and processing rather than the data.
• Tiered storage pricing — cheaper archival tiers, often with a retrieval charge that surprises people during an incident, which is exactly when you need the old data.

Self-hosting an open-source platform removes the licence and replaces it with infrastructure you provision and operate. The costs do not vanish; they move onto your own ledger where you control them. That control is the actual argument, not the saving.

5. Implementation effort

Installation is the short part. The work is everything after:

• Log source onboarding — each distinct source needs collection configured, parsing verified and field mapping checked. Effort scales with the number of distinct sources, not the number of hosts.
• Agent deployment — packaging and rollout across operating systems, plus the long tail of hosts nobody documented.
• Rule tuning — every platform is noisy on day one. The first four to six weeks are spent suppressing what does not matter in your environment. Skipping this produces alert fatigue, which produces a SIEM nobody reads, which fails the monitoring control.
• Compliance mapping — validating which detections evidence which controls, rather than trusting built-in framework tags.
• Integration — ticketing, on-call, identity, and whatever produces your evidence pack at audit time.

6. Operating it — the line that never ends

Two distinct roles, routinely conflated and separately costed:

Platform operations. Upgrades, index lifecycle management, cluster or indexer health, disk headroom, agent version drift, certificate rotation, and the 2am page when ingestion stops. Roughly a fraction of an engineer for a small estate, a named role for a large one.

Security operations. Alert triage, investigation, escalation and the documented daily review. This is what the frameworks are actually asking for. Twenty-four-hour coverage needs multiple people, which is the arithmetic that sends most mid-market organisations towards a managed service.

The failure mode here is specific and common: the platform gets budgeted and the reviewer does not. The result satisfies ISO/IEC 27001 A.8.15 on logging and fails A.8.16 on monitoring, or produces a SOC 2 finding under CC7.2 and CC7.3 — a fully funded SIEM that no auditor will pass.

7. The costs people forget

• Network egress — shipping logs out of a cloud provider to a SIEM elsewhere is charged per gigabyte, continuously.
• Retrieval from cold storage — fine until an incident or an audit needs eleven-month-old data.
• Non-production environments — frequently in scope and frequently forgotten in sizing.
• Growth — log volume tracks headcount, infrastructure and product surface. Size for the estate you will have, not the one you have.
• Exit — migrating detection logic, parsers and historical data off a platform is a project in itself. With a self-hosted open-source stack the configuration and the data are already yours, which is what makes the exit cheap.

A sizing checklist

Before anyone quotes anything, have these seven numbers:

1. Measured gigabytes per day, from two weeks of sampled real collection.
2. Retention required, split into immediately-searchable and retrievable, and the framework that sets each.
3. Any data-residency constraint (CERT-In in-India retention being the common one).
4. Count of hosts needing an agent, by operating system.
5. Count of distinct log source types.
6. Which frameworks are in scope, and whether a Type 2 observation window has already started.
7. Who reviews alerts tomorrow morning, by name and by shift.

Number seven is the one that decides the architecture, and it is the one most often left blank.

How we scope it

Praxis-Q sizes against the seven numbers above rather than a licence tier. Under build-and-hand-over we architect for your measured volume and retention, deploy, tune and map the controls, then hand you a stack you own outright — data, detection logic and configuration — with no ongoing dependency on us. Under managed, the same build is operated by our analysts under SOC-as-a-Service, covering the daily review and the audit evidence. The platform is the same either way, so the decision is about who staffs it, not what you buy.

Still choosing a platform? Start with the open-source SIEM comparison. Need the control-by-control detail? See Wazuh mapped to ISO 27001, SOC 2 and PCI DSS. Weighing in-house against outsourced operations? See SOC-as-a-Service vs an in-house SOC.

Pricing is scoped per engagement — request a proposal.

Frequently asked questions

Is open-source SIEM actually cheaper?

The licence goes away; compute, storage, implementation and operations do not. It is usually cheaper at scale and for long retention, because storage is the dominant cost and you control it directly. The stronger argument is ownership: the data, parsers and detection logic remain yours when a contract ends.

What is the biggest cost people underestimate?

Storage across the full retention window, followed immediately by the analyst time to review alerts. Both are recurring; the licence and the implementation are the parts organisations plan for.

How do we forecast ingest volume before we have a SIEM?

Sample. Collect from one representative host of each type for two weeks, measure, and extrapolate by host count with headroom for growth. It is a few days of work and it prevents sizing the architecture wrong in either direction.

Can we reduce volume rather than pay for it?

Yes, and it is usually the first optimisation: filter at the source, drop genuinely valueless events before ingest, and route high-volume low-value logs straight to cheap archival storage without indexing them. Do this deliberately, with the retention requirement in hand — dropping something a framework requires is a false economy.

Do we need twenty-four-hour coverage?

It depends on what your framework, your customers and your contracts require, and on whether an attack outside business hours is a risk you accept. Most frameworks require daily review rather than continuous monitoring by name — but detection at 2am on Sunday is only useful if someone is there.