Splunk has been the standard tool in enterprise SOCs for over twenty years, part of Cisco since March 2024, with an ecosystem of thousands of apps. Talk about SIEM and Splunk usually comes up first.
Mid-market organisations are nonetheless increasingly deciding against it. Not because the product is bad, but because the question is framed wrongly. It is not: which SIEM is better? It is: who operates it the day after deployment?
A correction to the original: the licensing model
The first version stated that Splunk's licensing is based on daily ingest volume. That is no longer the whole picture. Splunk now also offers a workload-based model that charges for compute rather than data ingested. For environments with high volume and few queries, that can be considerably cheaper.
The underlying point still stands, more precisely stated: under volume-based models, architecture decisions get made on licence cost rather than risk. The industry even has a term for it — the "Splunk tax", the practice of deliberately leaving log sources unconnected because the budget is exhausted. Firewall logs throttled, endpoint telemetry filtered, cloud audit logs never onboarded.
A SIEM that is blind for cost reasons exactly where it needs to see is more expensive than one that costs nothing.
On our own figures: six- to seven-figure annual costs are our experience from projects, not list prices. Splunk publishes none, and every environment computes differently. Take the order of magnitude, not the digit.
The real cost problem is not the licence
Splunk sells software. You provide the operation. In practice that means a team to administer it, build use cases, write detection rules, tune false positives and run the infrastructure. Two to three full-time roles is realistic, and those people have to be found and then kept. When the one who wrote the rules leaves, the knowledge stops with them.
Across the projects we have seen, staffing costs regularly exceed licence costs by a factor of two to three. That is the line item missing from the procurement calculation.
It also explains a finding that holds regardless of vendor: according to Tines research, a SOC analyst received an average of 4,484 alerts per day in 2025, of which 67 percent were never investigated. That is not a tooling problem. It is a capacity problem, and no licensing model solves it.
Where XIEM® takes a different approach
XIEM® is a managed service. We run the SIEM, develop the detection rules, tune the alerts and deliver assessed results rather than raw data. Billing is a flat rate per tier rather than by volume, so you can connect every relevant source without recalculating each time.
Four tiers cover the maturity range: Sentry, Orchestrate, Control and Control AI. Wazuh sits underneath as an open-source platform, which means no proprietary data formats, inspectable technology and no format lock-in.
But it is not lock-in-free either, and we should not claim that it is. You can take the data with you. The rule set, the tuning, the playbooks and the operation are work that sits with us. Migrate away and you take the logs and leave the operational maturity behind. The difference from a proprietary model is real, but it is a matter of degree rather than an absolute.
When Splunk is the right choice
For large enterprises with their own security engineering, complex multi-cloud estates and the budget for platform plus people, Splunk is a powerful tool. An organisation with an established Splunk team has no reason to switch — switching would destroy working operational maturity.
There are also cases where Splunk simply does more: if you want one platform for observability, IT operations and business analytics; if you analyse very large datasets beyond security; if you need the app ecosystem for unusual sources; or if your analysts know SPL and use it to ask questions no pre-built rule set answers.
When XIEM® is the wrong choice
This section was absent from the original, and that was a mistake.
XIEM® does not fit if you are building a data lake well beyond security. It does not fit if regulatory or organisational constraints require everything to run in-house — a managed service means a third party sees your security events, with everything that implies for contracts and data processing agreements. And it does not fit if you have a strong detection-engineering team that would rather write the rules itself; then you are paying for something you do better yourself.
Anyone in one of those three categories should not hire us. That belongs in an honest comparison.
NIS2: evidence rather than a database
NIS2 does not require a SIEM. It requires that you can detect security-relevant events, respond to them and document that. The deadlines — 24 hours for the early warning, 72 hours for the notification — presuppose that you know something happened at all.
A tool gives you the means to build that evidence. A service gives you the evidence. Our reporting is designed for use with the authorities: detection times, incident timelines, notification records — without weeks of preparation.
That is not an argument against Splunk. It is an argument against buying a tool when what you need is an outcome.
The comparison
| Splunk Enterprise | XIEM® |
|---|
| Licensing | volume- or workload-based, depending on contract | flat rate per tier |
| Operation | in-house, realistically 2–3 full-time roles | managed service |
| Detection | framework, rules built in-house | rules provided plus ongoing SOC analysis |
| NIS2 reporting | build it yourself | integrated |
| Technology | proprietary | open source (Wazuh) |
| Lock-in | data format and ecosystem | no format lock-in, but operational dependency |
| Audience | enterprise with its own security team | mid-market without a dedicated SOC |
| Time to value | months | days to weeks |
From practice
We have worked with Splunk environments and know the strengths. We also know the expression on an IT manager's face when the first annual invoice lands — or when they discover six months in that the detection rules are still at factory defaults because nobody had time.
The fairest comparison is not feature against feature. It is: what happens in your network the day after deployment? With a tool, that is when the work starts. With a service, that is when visibility starts.
If you want to do the work yourself and can — do it. That is a legitimate decision, and sometimes the better one.
Sources