Cloud SIEM

Run threat detection on the platform that already collects your logs

Cloud SIEM is a product that analyzes logs ingested into Datadog to detect threats and lets the security operations team carry investigation and response through in one place. Ingestion is handled by the Datadog Agent and API-based integrations, and telemetry from both cloud and on-premises is in scope (as of September 2026; source: Cloud SIEM). SIEM (Security Information and Event Management) is the general term for a mechanism that gathers logs from many places, correlates them, and finds suspicious events. If you already gather logs for monitoring, the first benefit is that you no longer need the effort and cost of forwarding the same logs a second time to a separate SIEM product for storage. The official documentation also positions it as making collaboration easier when both the DevOps and security teams sit on the same platform. The log collection paths and the details of the two-tier billing are left to the explanation of Log Management; this article follows only what the SIEM adds.

A log that matches a detection rule becomes a security signal

A detection rule is a conditional expression applied to all ingested logs and cloud configuration. When any of the conditions defined in the rule is met within a set period, one security signal is generated and appears in the Signals Explorer (as of September 2026; source: Detection Rules). For the out-of-the-box rules Datadog provides, the pricing page states more than 800, and newly published rules are automatically ingested into each account (as of September 2026; source: Datadog Pricing). Conditions the out-of-the-box rules do not cover can be added in two ways: clone and rewrite an existing rule, or create one from scratch. The cloning example Datadog officially gives is changing a Threshold-type log detection rule into an Anomaly type to add a different perspective on the same query. Version history and diffs are kept, and rules can be exported to JSON or Terraform, so they can also be put on an operation that manages detection logic as code.

What to do after opening a signal - from triage to cases and Workflows

In the Signals Explorer, filter signals by severity, detection rule, and MITRE ATT&CK tactic, and change their state in the side panel. The default triage state is OPEN; you can move a signal to Under Review while investigating and to Archived once resolved, leaving a reason (as of September 2026; source: Investigate Security Signals). When one signal is not enough to decide, create a case and bundle multiple signals to investigate them together. Creating a case automatically sets the triage state to Under Review, and for a serious event you can proceed to declaring an incident from the same panel. Automated response is the domain of Workflow Automation, and the Workflows that best match the signal's tags are proposed as Suggested Workflows, up to the top 3. Investigation by generative AI (Bits AI Security Analyst) is left to the explanation of Bits AI.

The seven sections to look at first on the Cloud SIEM Overview page

Once Cloud SIEM is enabled, the Overview page becomes the starting point of operations. Seven sections are laid out here, and they can be reordered or hidden from Customize Page (as of September 2026; source: Cloud SIEM). The key to reading it is to check from the top down: "is ingestion healthy," "which signals need attention right now," "which entities are at risk," "where is it coming from," and finally to look back at "the performance of detection itself." The Detection rules performance section in particular gains meaning the more you triage signals within Cloud SIEM, and you can read the false-positive rate per rule and which rules produced more signals than the previous week. Simply tightening conditions starting with the rules with the highest false-positive rate visibly changes the on-call load the following week.

The MITRE ATT&CK map is a tool for finding missing rules

MITRE ATT&CK is a framework that organizes attacker behavior; the official documentation explains Tactics as the attacker's objectives and Techniques as the concrete means of achieving them. Detection rules are mapped to these tactics and techniques, and opening the MITRE ATT&CK map from the detection rules screen of SIEM or Workload Protection shows at a glance how many rules exist for each technique (as of September 2026; source: Detection Rules). The three uses Datadog officially lists are understanding uncovered techniques, prioritizing rule additions for thinly covered techniques, and organizing rules. The MITRE ATT&CK coverage section of the Overview page lists as KPIs the number of techniques with high / medium / low / zero rule density. What matters in practice is the techniques at zero: places where you are ingesting the relevant logs yet have not a single rule are the highest-priority spots for adding rules.

What comes with enabling a Content Pack

A Content Pack is a bundle of integrations selected for security teams. The official documentation explains that each Content Pack includes, in addition to setup instructions, detection rules, out-of-the-box dashboards, parsers, and SOAR Workflows (as of September 2026; source: Cloud SIEM). Getting started takes three steps: open the Cloud SIEM screen, press Enable Cloud SIEM, and follow the onboarding steps. What makes the difference is "are you already sending those logs to Datadog"; if so, simply enabling the Content Pack sets the out-of-the-box rules running, and the additional unit price is mainly Cloud SIEM's analyzed GB. Because parsers are bundled too, you do not have to start building the pipeline that shapes logs into a form detection rules can read. Whether a Content Pack exists is the fork between "it works right away" and "you start with preparation."

Does analyzed-GB billing overlap with log indexing charges?

Cloud SIEM's unit price is counted in analyzed GB. The plan on the pricing page includes 12 months of analysis and retention and shows a monthly price per analyzed GB in three contract forms, annual commitment, monthly commitment, and on-demand, with the unit price rising in that order (source: Datadog Pricing). The cost of storing logs, on the other hand, is decided by choices on the Log Management side; the official documentation explains that you can use standard indexes for logs you search frequently, Flex Logs for logs you retain long-term but sometimes need to search urgently, and Log Archives for logs you rarely search (source: Cloud SIEM). In an estimate, two ways of counting sit side by side, "the GB the SIEM analyzes" and "ingestion and indexing on the log side," and the latter can be changed by how you choose storage destinations. The overall picture of pricing is covered in the pricing guide.

This article explains how billing works. For current unit prices and plans, refer to Datadog's official pricing page.

How to bring in logs that are not yet reaching Datadog

The official documentation lists the Datadog Agent and API-based integrations as ingestion paths, and includes not only cloud but also on-premises systems in scope (as of September 2026; source: Cloud SIEM). When adding logs from servers without the Agent or from internal appliances, check whether a relevant integration exists, and if not, ingest them through the Agent's log collection. Pre-processing that drops unneeded lines and routes to destinations before sending is the role of Observability Pipelines, which lets you shape the volume routed to the SIEM upstream of ingestion. Records of operations within Datadog itself are the domain of the Audit Trail. For comparing cost items when migrating from another SIEM product, see the comparison article with Splunk. The adoption order that minimizes rework is: enable the Content Packs for the logs already arriving, triage for a few weeks and tighten the rules with high false-positive rates, then add the missing log sources.