A cloud SIEM is a security information and event management service that runs in a provider's cloud instead of on servers you operate. It collects logs from your systems, normalizes them, correlates events and raises alerts. It is only as good as the logs you send it and the detections you write or enable.
What does a SIEM do, in standard terms?
NIST SP 800-92, the guide to computer security log management, describes SIEM software as centralized logging software with log servers that perform analysis and database servers that store logs. The collection step performs event filtering and aggregation, then log normalization and analysis. Normalization means translating each source's format into a common one so events from different systems can be compared.
NIST also explains why supported log sources matter. For each supported source type, the product knows which logged field holds the source address, for example, which is what makes correlation across a firewall, an operating system and a web server possible. A source the product does not understand arrives as raw text and is far less useful.
What changes when it is in the cloud?
The processing and storage move to a provider, so you trade hardware and upgrades for questions about data location and cost. Collection gets more varied too. NIST describes two collection methods: agentless, where the SIEM pulls logs from hosts or hosts push them, and agent-based, where a program on the host filters, aggregates and normalizes before sending. Its trade-off still holds in a cloud setting. Agentless is easier to deploy but moves more raw data over the network and may need credentials to each source. Agents reduce volume but must be installed and maintained.
What are the questions that matter?
Start with the sources. Make a list of what you need to see: identity provider sign-ins, cloud control plane audit logs, endpoint telemetry, firewall and DNS logs, email security events, and key application logs. Then ask the provider which of those it supports natively and which need custom parsing.
Next, retention and access. Know how long hot data stays searchable, how long archived data is kept, and how you retrieve it during an investigation. NIST notes organizations may need specific retention periods to meet requirements, and that log rotation and archival need monitoring.
Then cost mechanics. Cloud SIEMs commonly meter by volume ingested or stored, though models vary, so ask exactly what is billed and what happens when a noisy source doubles its output. Do not rely on a quote built from a quiet week.
What does a poor fit look like?
Constructed example: a company buys a cloud SIEM and connects the sources that are easy to connect. Cloud audit logs and endpoint alerts flow in. The identity provider's sign-in logs, where most account takeovers show, are left for later because the connector needs an admin approval. Six months on, the dashboards look healthy and the one source that mattered is missing. Nobody tested a detection against it.
What about detection content and tuning?
A SIEM is not a detection set. Vendor rules give a start, but you need rules for your environment, a place to record why alerts were suppressed, and a person responsible for the queue. NIST's log guide says log management is often treated as a low priority task, and that organizations should prioritize it based on risk reduction. Treat the SIEM as an operating process.
How to check or apply this
- List your top ten log sources by security value, and mark which the SIEM supports natively.
- Set a time sync standard across all sources so events line up. Correlation fails when clocks disagree.
- Pick the collection method per source and record the credentials each one uses.
- Define retention in writing: searchable period, archive period, legal holds.
- Model cost against peak volume, not average, and set alerts on ingestion spikes.
- Test with at least five realistic scenarios, such as impossible travel sign-in or a new admin role, and confirm each alert reaches a person.
- Confirm you can export your data and detection rules in a usable format if you leave.
- Check where data is stored and processed against your legal obligations.
Quick check
Is a cloud SIEM the same as a log management tool?
A log tool collects and stores logs. A SIEM also normalizes them, correlates events across sources and raises alerts. Many products do both.
What is the most common reason a SIEM disappoints?
Missing or poorly parsed log sources. If the logs that show the attack never arrive, no rule can fire.
Sources
- NIST SP 800-92, Guide to Computer Security Log Management
- NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems
Last reviewed: 18 October 2026.
