Datadog Cloud SIEM Guide: Rules, Signals, Log Tiers

Datadog Cloud SIEM only detects what reaches its index and only helps if its signals are tuned, owned and acted on. This guide explains how to operate Cloud SIEM as a security team: getting logs analysed, choosing and writing detection rules, triaging signals, controlling noise with suppressions, deciding which logs go to Standard indexing, Flex Logs or archives, and locking down who can change detections. It is for SOC leads, detection engineers and platform teams who already run Datadog or are taking over a Cloud SIEM tenant. For SIEM concepts in general see the SIEM Guide.

This is an independent guide from NHI Mgmt Group, based on Datadog's public documentation as of November 2026. It is not sponsored or reviewed by Datadog. Product features change, so confirm settings against Datadog's current documentation.

Key takeaways

Index order decides coverage. Activation creates a cloud-siem-xxxx index; Datadog routes each log to the first matching index, so an index above it that captures security logs keeps them out of Cloud SIEM analysis.
Seven detection methods, three rule types. Threshold, New Value, Anomaly, Content Anomaly, Impossible Travel, Third Party and Sequence, run as real-time, scheduled or historical job rules.
Clone, do not edit, out-of-the-box rules. Datadog recommends cloning a default rule, editing the copy and disabling the original, so imported rule updates and version history stay clean.
Lock down rule and suppression editing. By default all users can edit detection rules and suppressions; restrict editing to detection owners, and give Security Signals Write only to analysts.
Tier logs by query need. Standard indexing for frequently queried logs, Flex Logs for long retention with occasional urgent queries (monitors are not run on Flex), archives for rarely queried audit logs.

How Cloud SIEM is put together

Cloud SIEM ingests cloud and on-premises telemetry through the Datadog Agent and API integrations, applies detection rules to processed logs, and raises security signals that are correlated, triaged and escalated to cases or incidents. It sits on Datadog Log Management, so pipelines, indexes and retention are shared with observability use.

Component	What it does	What the security team owns
Content Packs	Curated bundles per source with detection rules, dashboards, parsers, OCSF pipelines and Workflow Automation, grouped into ten categories (Authentication, Cloud Audit, Cloud Developer Tools, Cloud Security, Collaboration, Email Security, Endpoint, Network, Threat Intel, Web Security)	Which packs are active and that each reports healthy
Entity Packs	Identify users across sources; required to detect risky users	Identity mapping quality
Detection rules	Conditional logic over logs that generates signals; out-of-the-box rules import automatically, some start in beta	Enabled set, custom rules, severity, notification routing
Signals	Alerts with states Open, Under Review and Archived; locked 30 days after creation	Triage, archive reasons, mean time to resolve
Suppressions	Conditions under which a signal is not generated, optionally excluding matching logs from analysis	Justification, expiry, review
Cases and Workflow Automation	Case tracking, incident declaration, actions such as blocking an IP or disabling a user	Escalation paths and approval for automated actions

Getting logs analysed

Activation: configure log ingestion, enable Cloud SIEM, choose Content Packs and sources, then Activate. This creates the cloud-siem-xxxx index.
Index position: keep cloud-siem-xxxx first, or above any index whose filter overlaps security logs. If a pack shows "Waiting for logs", check index order before anything else, then recheck pack and source status after reordering.
Priority sources: Datadog's getting-started guidance lists cloud audit logs, identity provider logs, SaaS and workspace logs and third-party security findings. Examples of packs include AWS CloudTrail, GCP Audit Logs, Okta, Microsoft 365, Google Workspace, GitHub and Microsoft Graph (which carries Entra ID, Defender and Purview data).
Normalisation: packs ship OCSF pipelines, which lets one rule cover several sources with the same schema. See the OCSF Guide.
Enrichment: rule queries can filter with Reference Tables (IN or NOT IN joins), for example a list of break-glass accounts or approved admin IP ranges. Tables over 1,000,000 rows cannot be used to filter events.

Detection rules: methods and settings

Method	Fires when	Good fit
Threshold	Activity occurs a set number of times in the window (1 for signature-style detections)	Known-bad events, password spraying counts
New Value	A tracked attribute takes a value not seen in the learning period; values can be forgotten after 1 to 30 days	First use of an API key from a new country or ASN, new admin role grant
Anomaly	Log volume spikes or shifts upward, allowing for daily and weekly seasonality	Bulk downloads, mass deletions
Content Anomaly	Field content is unusual compared with a learned baseline (encoded commands, long URLs, odd user agents)	Command lines and web requests
Impossible Travel	Implied travel speed between consecutive logins is impossible; first 24 hours baseline user locations	Human interactive logins
Third Party	Findings arrive from another security tool	Bringing existing alerts into one triage queue
Sequence	An ordered chain occurs, such as login, privilege grant, sensitive access; up to 24 hours in total	Multi-stage account takeover

Rule types: real-time rules analyse incoming logs; scheduled rules run at intervals on indexed data and can use DDSQL with datasets; historical jobs backtest a rule once over past logs, producing lightweight signals you can convert.
Cases and severity: each case is a condition on a query label (for example a > 3), evaluated in order with the first match winning, at INFO, LOW, MEDIUM, HIGH or CRITICAL.
Timing: evaluation window must be less than or equal to keep alive and maximum signal duration. Short keep-alive values split one attack into many signals; long ones merge separate attacks.
Environment handling: "Decrease severity for non-production" lowers severity one level for staging, test or dev tags, so tag environments consistently before relying on it.
Testing: use Unit Test against a sample log (copy a real event and change the field that should trigger) and a historical job before enabling notifications.
Lifecycle: rules can be exported to JSON or Terraform, and Rule Version History shows who changed what with diffs. Deprecated out-of-the-box rules stay for 15 months and can be cloned during that window. Managing custom rules as code is covered in the Detection as Code Guide.

Triage, suppressions and response

States: move a signal to Under Review when investigation starts and to Archived with a reason when done; archived signals can be reopened. Changing state needs Security Signals Write.
Cases: creating a case sets the signal to Under Review and assigns it to the creator by default; cases can be escalated with Declare Incident.
Investigation panel: the Entities tab lists related users and IP addresses with links to related signals and the Investigator for cloud entities; Logs shows matched events; Suppressions shows the rule's suppressions.
Suppressions: signal-attribute suppressions apply when a signal is created; log or event attribute suppressions also apply to updated signals, and Datadog recommends them for reliable exclusion. An optional log exclusion query stops matching logs being analysed at all. Always add a description and, for temporary cases, an expiration date.
Notifications: notification rules route signals to people or teams through channels such as Slack, Jira, email and webhooks. Route by severity and source rather than notifying on every signal.
Automation: Workflow Automation can block an IP, disable a user or look up threat intelligence, and can trigger automatically on signals. Start with enrichment-only workflows and require a human for containment until false positive rates are known. See the Alert Fatigue Reduction Guide.

Log tiers and cost control

Cloud SIEM shares storage choices with Log Management. Datadog positions three tiers by query pattern, and logs can sit in Standard first and then extend into Flex.

Tier	Use for	Security considerations
Standard indexing	Frequently queried, short-term logs	Needed where monitors and fast interactive search matter
Flex Logs	Long retention with occasional urgent queries; Datadog names CloudTrail, Okta, VPC Flow Logs, WAF and load balancer logs as candidates	Monitors and Watchdog are not run on Flex; retention 3 to 15 months on Starter or 30 to 450 days on scalable compute sizes; enable with `flex_logs_config_write`; search with "Include Flex Logs"
Log Archives	Rarely queried audit and configuration logs	Rehydration needed before search; plan for incident lookback periods

Size Flex compute deliberately: compute sizes run Starter, XS, XS+, S, M and L, chosen mainly by stored log volume; dashboard queries count against capacity, and at capacity queries retry and may fail, which matters mid-incident.
Exclude with care: a suppression's log exclusion query removes logs from analysis, so use it for proven noise only, never to cut cost on identity or audit sources.
Retention by obligation: set tiers from your retention duties rather than defaults; see the Log Retention Requirements Map and the Security Log Cost Optimisation Guide.

Access control for the SIEM itself

Permission	Identifier	Default role	Grant to
Security Rules Read	`security_monitoring_rules_read`	Read Only	All security staff
Security Rules Write	`security_monitoring_rules_write`	Standard	Detection engineers only
Security Signals Read	`security_monitoring_signals_read`	Read Only	Analysts, responders
Security Signals Write	`security_monitoring_signals_write`	Standard	Analysts who triage
Security Suppressions Write	`security_monitoring_suppressions_write`	Standard	Detection engineers, with review
Security Notification Rules Write	`security_monitoring_notification_profiles_write`	Standard	SOC leads
Security Filters Write	`security_monitoring_filters_write`	Admin	Platform owners

Because the Standard role carries rule, suppression and notification write permissions, create a custom role for general engineering users without them, and use the per-rule Restrict Access option on high-value detections and suppressions. A suppression or a disabled notification rule is the quietest way to blind a SOC, so treat changes to them as security events.

Where identity fits

Cloud SIEM is itself driven by credentials. Agents and API integrations authenticate with API keys, and Terraform or detection-as-code pipelines use application keys or service accounts that can rewrite every rule. Scope those keys to the permissions above, store them in a secrets manager and rotate them; see the Datadog API and Application Keys Security Guide. On the detection side, identity provider and cloud audit logs carry most account takeover evidence, so New Value and Sequence rules keyed on service account and API key identifiers are worth custom effort.

How to implement

Plan sources and retention. List identity, cloud audit, SaaS and endpoint sources with their retention duty and expected query pattern, and decide Standard, Flex or archive for each.
Activate and fix index order. Activate Cloud SIEM with the chosen packs, move cloud-siem-xxxx to the top, and confirm every pack reports logs.
Set access before tuning. Create analyst, detection engineer and read-only roles; restrict editing on rules and suppressions.
Run out-of-the-box rules quietly. Enable them with notifications to a review channel only for two to four weeks; record false positive rates per rule.
Tune by cloning. Clone noisy rules, adjust queries, Reference Table filters or severity, disable originals, and add expiring suppressions for known benign activity.
Add custom rules from gaps. Use the MITRE ATT&CK coverage map to find uncovered techniques, write rules, unit test, backtest with a historical job, then enable.
Turn on routing and automation. Configure notification rules by severity and team, then add enrichment workflows; add containment workflows with approval last.
Roll back safely. Rule Version History and JSON or Terraform exports let you restore a previous rule; keep exports in version control.

Detection and measurement

Coverage: packs reporting healthy, logs analysed per source on the Overview page, and ATT&CK coverage trends.
Quality: the Overview shows rules by false positive rate; pair it with archive reasons recorded at triage.
Control changes: watch for rule disablement, new suppressions, notification rule edits and index reordering, and review them weekly.

Metric	Why it matters
Mean time to detect and mean time to resolve (tracked on the Overview)	Shows whether triage keeps pace with signal volume
Share of signals archived as false positive, per rule	Drives tuning priorities
Active suppressions without an expiry or description	Should trend to zero
Priority sources with no logs analysed in the last 24 hours	Silent pipeline failures blind detections
Open signals older than the 30-day lock period	Unowned signals lose their audit trail value

Common misconfigurations

Index placed below an overlapping index: security logs land in an observability index and are never analysed, while dashboards still look full.
Editing default rules in place: changes are hard to trace against imported updates; clone instead.
Broad, permanent suppressions: a suppression on a whole service account or subnet with no expiry hides the activity an attacker using that account would generate.
Everyone can edit detections: the default leaves rule and suppression editing open; restrict it.
Security logs only in archives: investigations stall waiting for rehydration; keep identity and cloud audit logs searchable for your typical lookback.
Automated containment without tuning: workflows that disable users on untuned rules lock out legitimate staff and erode trust in the SIEM.

Framework mapping

Framework	Reference	Cloud SIEM activity
NIST SP 800-53 Rev 5	AU-6, SI-4	Signal review and reporting; continuous monitoring through detection rules
NIST CSF 2.0	DE.CM-01, DE.AE-02, DE.AE-03, RS.AN-03	Monitoring; analysing signals; correlating sources; investigation through cases
CIS Controls v8.1	8.9, 8.11, 13.1	Centralise audit logs; review them; centralise security event alerting
ISO/IEC 27001:2022 Annex A	A.8.15, A.8.16	Logging; monitoring activities
MITRE ATT&CK	T1078.004, T1110	Examples of techniques addressed by identity-source rules (cloud account misuse, brute force)

Practitioner checklist

Confirm cloud-siem-xxxx sits above every index that overlaps security logs.
Verify each active Content Pack is receiving logs, and Entity Packs are active for risky user detection.
Restrict rule and suppression editing to detection engineers; remove write permissions from general Standard users.
Clone and tune noisy out-of-the-box rules rather than editing them; disable the originals.
Give every suppression a description and, where temporary, an expiration date.
Unit test and backtest each custom rule before enabling notifications.
Export rules to JSON or Terraform and keep them in version control.
Keep identity and cloud audit logs searchable in Standard or Flex for your incident lookback.
Scope and rotate the API and application keys used by agents and rule pipelines.

Datadog Cloud SIEM Guide: Running Detection Rules, Signals and Log Tiers Well