What a SIEM costs you in people, not licenses

A SIEM quote tells you what the platform costs to buy. It does not tell you what it costs to keep useful: the parser that breaks when a firewall vendor changes its log format, the rule that fires thousands of times after a Monday patch window, the major upgrade that rewrites a detection macro. That work is paid in engineering hours, and it is the main reason SIEM projects fail quietly — the platform runs, alerts flow, and nobody trusts them.

This is the companion to Choosing a SIEM by what you already run. That article filters platforms by infrastructure and organization size. This one goes through the five platforms and asks where the operational work lands, based on each vendor’s documentation as of October 17, 2026.

The work every SIEM needs

Before the differences, the common ground. Whatever you buy, someone owns these five jobs:

Onboarding and parsing. Getting a source in is easy; getting its fields extracted and normalized so that rules work across sources is the real effort.
Detection tuning. Prebuilt rules are a starting point. Every environment has service accounts, scanners and admin scripts that look like attacks.
Capacity and retention. Disk, cluster nodes or a monthly bill — something grows with volume, and someone has to watch it.
Upgrades. Platform versions, agent versions, content packs and the rules that depend on them.
Health monitoring. A log source that silently stops sending is a detection that silently stops working.

Software as a service (SaaS) removes most of job 3 and part of job 4. It does not touch jobs 1, 2 and 5.

Wazuh

What you run: the Wazuh server, the Wazuh indexer and the Wazuh dashboard, plus an agent on each endpoint (quickstart). At small scale all three central components fit on one host. Beyond roughly 100 agents, the documentation points to a distributed deployment: a Wazuh server cluster with a load balancer in front of it, and a multi-node indexer cluster (server cluster).

Where the work lands:

Rules and decoders are XML. Parsing a new log format means writing a decoder; changing detection behavior means writing rules that reference existing rule IDs. Custom rules belong in the 100000–120000 ID range that Wazuh reserves for them (custom rules). The tooling is plain — wazuh-logtest replays a log line through decoders and rules — and that plainness is both the strength and the cost. There is no visual rule builder.
Tuning is mandatory. The default ruleset is broad by design. Expect to write exclusion rules for your own service accounts, scanners and admin tooling in the first weeks.
Capacity is predictable. The indexer documentation sizes storage by alerts per second per endpoint type: about 3.7 GB per 90 days for a server at 0.25 alerts per second, 1.5 GB for a workstation at 0.1 (indexer requirements). The indexer needs at least 4 GB of RAM and two cores per node; the recommendation is 16 GB and eight cores.
Upgrades touch everything you run. The server, indexer and dashboard must run the same version down to the patch level, and agents must not be newer than the server (compatibility matrix). Central components go first, agents follow.

Skills you need: Linux administration, XML, regular expressions, and enough OpenSearch knowledge to keep the indexer healthy. Wazuh Cloud exists if you want to hand off the infrastructure part.

Elastic Security

What you run: on Serverless, nothing. Self-managed, an Elasticsearch cluster, Kibana, and Fleet Server to manage Elastic Agents. Elastic Cloud Hosted sits in between: Elastic runs the cluster, you still size it.

Where the work lands:

Data onboarding is integration-driven. Elastic Agent integrations, managed from Fleet, cover common sources and map them to the Elastic Common Schema (ECS). Sources without an integration need an ingest pipeline that you write and maintain.
Detection content is large and public. Elastic publishes its prebuilt rules in an open repository and ships updates through Kibana. Rules are written in KQL, EQL (useful for sequences) or ES|QL. Some tuning features sit behind licenses: alert suppression requires Platinum or higher (Elastic blog), and so does alerting on machine-learning anomaly detection.
Capacity is where self-managed Elastic gets expensive in time. Shard sizing, index lifecycle policies, hot-warm-cold-frozen tiering and node roles are real engineering. The cheapest long-retention tier depends on searchable snapshots, which require an Enterprise license (Elasticsearch reference).
On Serverless, the work moves to the bill. You pay per GB ingested and per GB retained per month (pricing), so the cost-control job looks like Sentinel’s: decide what to keep and for how long.

Skills you need: Elasticsearch operations for self-managed; one or more of Elastic’s query languages; ingest pipeline development for non-standard sources.

Microsoft Sentinel

What you run: no SIEM infrastructure. For sources outside Azure you run log forwarders: a Linux machine with rsyslog or syslog-ng and the Azure Monitor Agent, plus the Azure Arc Connected Machine agent if it is not an Azure virtual machine (Syslog and CEF via AMA). Some connectors run on Azure Functions, and automation runs on Logic Apps — both billed separately from Sentinel (billing).

Where the work lands:

Cost governance is a standing job. Every table needs a decision: analytics tier (90 days of interactive retention by default, up to two years) or data lake tier for high-volume, lower-value logs (log retention tiers). Data collection rules can filter and transform data at ingestion, which is often the biggest single saving. Commitment tiers start at 100 GB per day and can be lowered only every 31 days.
Detection is KQL. Content hub solutions bundle connectors, analytics rules, workbooks and playbooks per product. KQL is well documented and widely taught, which makes hiring easier than for the proprietary languages below.
The portal is moving. After March 31, 2027, Sentinel is supported only in the Microsoft Defender portal. If your runbooks, automation and analysts still work in the Azure portal, the migration is a project with a deadline.
Forwarders are yours. A full disk on a syslog forwarder stops the agent; Microsoft’s own documentation warns about it. Monitor forwarders as you would any other production server.

Skills you need: KQL, Azure resource management (role-based access, data collection rules, Arc), and someone who reads the bill every month.

IBM QRadar SIEM

What you run: a Console for the user interface and administration, and as volume grows, Event Collectors, Event Processors, Flow Collectors, Flow Processors and Data Nodes. A smaller deployment can run on a single All-in-One appliance and add processors later (IBM deployment guide). Appliances can be physical or virtual.

Where the work lands:

Parsing is handled by Device Support Modules (DSMs) for supported products, which is a real advantage for common enterprise devices. Unsupported or custom log formats need custom properties and log source extensions. QRadar 7.6.0 added multi-value and DSM-driven custom properties and explicit parsing-order management (7.6.0 announcement) — a sign of how much effort parsing used to take.
Detection runs in the Custom Rules Engine, which turns matching events and flows into offenses. Rules are built in the rule wizard and searches are written in the Ariel Query Language (AQL).
Licensing is an operational task. EPS and FPM capacity is allocated per host from a license pool. IBM documents that over-allocating EPS or FPM to hosts beyond the Console’s total license can block access to the Log Activity and Network Activity tabs (IBM Support). Somebody has to manage that pool as sources grow.
Version planning matters more than usual. QRadar Incident Forensics is not available in 7.6.x; customers who use it are told to stay on, or upgrade to, 7.5.0 Update Package 15. Read the release notes for removed features before every major upgrade.

Skills you need: QRadar administration and AQL — a narrower talent pool than KQL or SPL — and network knowledge if you use flows.

Splunk Enterprise Security

What you run: self-managed, a Splunk Enterprise deployment — forwarders, indexers and search heads — with Enterprise Security on the search head. ES 8.x documents minimums of 16 physical CPU cores and 32 GB of RAM for each search head and each indexer, and the same minimums apply to search head cluster peers (ES 8.3 planning). On Splunk Cloud Platform, Splunk runs the indexers and search heads; you still manage forwarders and other data inputs.

Where the work lands:

Data has to fit the Common Information Model. ES content relies on normalized data models, so every source needs a technology add-on that maps it, and someone has to check that the mapping actually populates the fields the detections use.
Detection is SPL. It is expressive and has the largest body of community content of any language here. Correlation searches are scheduled searches, which means detection load and search performance are the same capacity problem.
Upgrades carry content changes. The ES 8.4 release notes warn that finding-based detections created before 8.4 might stop working or need updates to use new macros, and that ES 8.x on on-premises Splunk Enterprise 10.x must be installed from the command line (ES release notes). Test every ES upgrade against your own detections, not just the vendor’s.
Pricing shapes architecture. Under ingest pricing, every GB counts; under workload pricing, expensive searches cost more than data volume (pricing models). The model you choose decides whether your engineers spend their effort filtering data or optimizing searches.

Skills you need: a dedicated Splunk administrator for any self-managed production deployment, SPL for detection engineers, and data onboarding skills for CIM mapping.

Putting it side by side

Job	Least effort	Most effort
Infrastructure	Sentinel, Elastic Serverless	Self-managed Splunk ES, QRadar distributed
Parsing common enterprise sources	QRadar (DSMs), Sentinel and Elastic (integrations)	Wazuh (custom decoders)
Cost governance	Self-managed platforms (capacity is fixed)	Sentinel, Elastic Serverless, Splunk ingest pricing
Hiring	KQL (Sentinel), SPL (Splunk)	AQL (QRadar), Wazuh XML
Upgrade risk to detections	SaaS platforms	Self-managed Splunk ES and QRadar majors

There is no column where one platform wins every row. The useful question is which rows your team can afford to carry.

How to measure this for your own team

During a proof of concept, keep a simple log of hours, per job, per platform. After two weeks you will have a number no vendor will give you: engineering hours per week to keep the candidate useful on your data. Count at least:

time to onboard your three most important sources with fields parsed correctly;
time to bring alert volume down to something one analyst can triage in a shift;
time spent on the platform itself — disk, nodes, agents, forwarders, licenses.

Limitations

These observations come from vendor documentation, not from a controlled comparison on identical telemetry.
Effort varies enormously with team experience. A seasoned Splunk administrator will find Splunk easier than an untrained Sentinel team finds KQL.
Managed services — an MSSP running QRadar or Splunk, Wazuh Cloud, Elastic Cloud — move much of this work out of your team, at a price this article does not model.

Adapting this to your environment

ADAPT the job list: if you outsource monitoring to an MSSP, jobs 1 and 2 may be theirs; jobs 3 and 5 rarely are.
ADAPT the skills assessment to the people you have now, not the ones you plan to hire.
ADAPT the side-by-side table with your own measured hours once the proof of concept is done.

The decision matrix behind both articles, with every source link, is in the armory as siem-selection-matrix.yml (CC BY 4.0). Corrections and field experience are welcome at hello@entropywatch.dev.