The question is almost always framed as an infrastructure question: cloud SIEM or on-premises? As in: Does the box sit in your data center or at a provider? In practice, server location is the least interesting part of the decision. What actually changes when you switch are three other things: how capacity scales, how the licence bills, and who owns day-to-day operations.
And one thing doesn’t change at all: more on that at the end, because it routinely gets lost in selection processes.
What a SIEM actually does
A Security Information and Event Management platform collects log data from across the organization (endpoints, identity systems, network, cloud platforms, applications) normalizes it into a common format, and correlates it through rules into events a human should care about.
The value isn’t in the collecting. It’s in the correlation: one failed login is noise. Fifty failed logins, followed by a successful one from another country, followed by a newly created mailbox forwarding rule: that’s an incident. No single system sees that chain. The SIEM does.
The real difference is the operating model
An on-premises SIEM is a software product you buy, size, install, patch and maintain for years. You plan storage up front, you plan compute up front, and you carry the risk when the plan doesn’t hold.
A cloud SIEM is a service. Capacity is elastic, updates arrive without maintenance windows, and the vendor’s detection content lands in your environment continuously without anyone rebuilding it by hand.
That sounds like a settled argument. It only is if you understand the consequences.
Where cloud SIEM clearly wins
Log volume cannot be forecast honestly. A new cloud tenant, a migration, one additional application with chatty debug logging and daily volume doubles. On-premises that means: buy storage, procurement process, weeks. In the cloud it means: do nothing.
Cloud sources speak cloud natively. Telemetry from Microsoft 365, Entra ID, AWS CloudTrail or Kubernetes audit logs arrives through maintained connectors instead of home-grown parsers that break every time the vendor changes an API. Anyone who has repaired a parser at night after a schema update knows the difference.
Time-to-value is shorter. No hardware procurement cycle, no capacity planning before the first log line. The first meaningful detections typically run weeks earlier.
Capacity limits hit you at the worst possible moment. An incident produces a multiple of normal log volume: precisely when you need every detail. An on-prem cluster at its capacity ceiling starts dropping data in exactly that situation. That is the most expensive conceivable moment for data loss.
Where on-premises is still the right answer
We’re not selling a cloud doctrine here. There are cases where on-premises is simply the better call:
- Hard data residency or classified-handling requirements that rule out processing outside a defined environment, a documented requirement, not a feeling that one exists.
- OT and production networks deliberately run air-gapped. What must not have outbound connectivity cannot log outbound either.
- A depreciated investment with a team that knows it. A well-tuned on-prem SIEM with analysts who have mastered it beats a freshly deployed, untuned cloud SIEM by a wide margin. Migration is not an end in itself.
- Extreme volumes against a bandwidth ceiling. If the site can’t ship the raw data upstream at all, the most elegant cloud platform won’t help.
A realistic middle path is often hybrid: detection-relevant telemetry goes to the cloud, while particularly sensitive or particularly high-volume sources stay local and only send results upstream.
The cost trap: you pay for ingest, not for security
This is where most cloud SIEM projects run off the financial rails and it only relates to cloud vs. on-prem indirectly.
Cloud SIEM licences bill almost universally by ingested data volume, usually in gigabytes per day. The intuitive reflex is: collect everything first, filter later. The result is a bill that grows with log volume while detection quality does not.
Because most log lines carry no detection value. Verbose application logs, health checks, load balancer lines every second: that’s forensic material, not detection material.
What actually helps:
- Log routing before ingest. Decide which source goes into the expensive detection tier and which goes straight to cheap archive storage.
- Tiering. Hot data for correlation and alerting, cold data for investigation and evidentiary obligations. Both are necessary. Both do not have to cost the same.
- Prioritize sources by detection value, not by availability. Identity and endpoint telemetry almost always contributes more to detection than application debug logs.
Making these decisions before rollout, rather than after the first surprising invoice, routinely saves a substantial share of running licence cost, without losing detection coverage.
What the operating model does not solve
And here is the thing that doesn’t change when you switch.
A SIEM (in the cloud or in the basement) is a machine that produces alerts. A SIEM without analysts is a very expensive alarm nobody answers. The platform decision changes nothing about the three jobs that separate a working SIEM from a decorative one:
- Detection engineering. Shipped default rules are a starting point, not a result. Effective detection is written against your own environment and checked for coverage gaps against a framework like MITRE ATT&CK.
- Continuous tuning. An untuned SIEM produces so many false positives that the team stops looking. Alert fatigue isn’t a comfort problem: it’s a detection failure you can see coming.
- Round-the-clock response. Attacks run at night, on weekends and on public holidays. An alert at 03:14 that nobody reads is functionally identical to no alert.
That exact dividing line is how our Managed SIEM / SOC tiers are cut: platform operations and detection engineering on one side, human triage and response around the clock on the other. Where your team ends, we start.
Five questions to answer before you select
- What is our log volume today and what will it be after the next planned migration?
- Which sources genuinely contribute to detection, and which only to the invoice?
- How long must we retain data: for investigation, and for evidentiary purposes?
- Who writes and maintains the detection rules after go-live?
- Who works the alert at 03:14?
Questions 4 and 5 decide whether the project succeeds. Questions 1 to 3 only decide what it costs.
What NIS2 and DORA change
For regulated organizations, a hard time factor comes on top. NIS2 requires, under Art. 23, an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month. Those clocks start on awareness and awareness requires detection.
A reporting process is only as fast as the detection underneath it. If it takes weeks to notice that something happened, you didn’t narrowly miss the 24-hour deadline. You never entered it. On top of that, notifications have to hold up, and holding up means evidence from log data that still existed at the time of the incident.
Which NIS2 and DORA requirements are covered by which service (and which deliberately are not) is broken down in detail on our NIS2 & DORA page.
Bottom line
Cloud or on-premises is an operations decision, not a security decision. Cloud wins on elasticity, cloud-native sources and time-to-value; on-premises keeps its place for hard residency requirements, air-gapped environments and working existing installations.
What determines actual security outcomes in both models is unchanged: clean source selection, maintained detection rules, and people who respond to alarms. The platform is the prerequisite. It is not the result.