Datadog Security Platform (SIEM)

Datadog Security is a security analytics and monitoring module built on the Datadog platform, a cloud-native observability and security ecosystem that unifies infrastructure monitoring, application performance, log management, and security analytics in a single SaaS environment. The company, founded in 2010, headquartered in New York City, and listed on NASDAQ (DDOG), is not a security company that added a SIEM. It is an observability company that added a security layer. This distinction is the single most important fact in this evaluation.

The practical consequence: a significant portion of the organizations running "Datadog SIEM" are already running Datadog for infrastructure monitoring, APM, and log management. The Security module was activated because the telemetry was already being ingested. The Datadog Agent is already on every server, container, and cloud resource. Adding the Security module means enabling detection rules, identity monitoring, and compliance dashboards on data that is already flowing. This is Tier 1 ecosystem capture: the security platform is not a deliberate SIEM procurement decision. It is a feature activation on an existing observability subscription.

For organizations that have not already adopted Datadog for observability, the Security platform is a genuine SIEM evaluation against Securonix, Microsoft Sentinel, Elastic Security, Splunk, and the others. In that context, the question is whether the unified observability-and-security architecture justifies adopting a new platform stack, or whether the existing SIEM with a security add-on is operationally simpler.

The Datadog Security platform comprises four modules: Cloud Security Management (CSM) for continuous cloud posture and misconfiguration monitoring, SIEM for log ingestion, detection, and correlation, Identity Security for user and entity behavioral analytics, and Runtime Security for workload and container threat detection. The SIEM module reached general availability in the 2023–2024 timeframe. It is younger than the core observability platform by a decade. It is younger than Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar, and Elastic Security by five to ten years of dedicated security R&D. A CISO evaluating this platform should weight that maturity differential.

The architectural advantage is real: security telemetry is correlated natively with infrastructure performance, application traces, and container runtime data in a single query context. A latency spike on a production API can be correlated with a security event on the same host, a configuration change in the same Kubernetes namespace, and a deployment event in the same CI/CD pipeline, without exporting data to a separate SIEM. In a DevOps-heavy environment where the SOC and SRE teams operate as one, this unified context reduces investigation time. In a traditional SOC where the security team and the infrastructure team are separate organizations with separate tooling, the unified context is less relevant.

The following lists represent the telemetry types ingested and analyzed in Datadog Security environments. Expanded to ten entries per category. Items marked with † are particularly relevant to Datadog's unified observability-and-security architecture.

Identity & Access Control Events

1. Login success and login failure (Okta, Entra ID, Ping, SAML/OIDC providers)
2. Account lockout, MFA push rejection, or FIDO2® authentication bypass
3. Password change, reset, and password policy violation
4. Role, permission, or group assignment and revocation (RBAC/IAM)
5. Privileged service account activation, JIT access grant, or elevation without change-management ticket
6. † OAuth 2.0 or SAML token creation, refresh, scope expansion, or anomaly (unusual client_id, unusual redirect_uri)
7. † Conditional access policy evaluation, enforcement, or bypass (Entra ID, Okta policy engine)
8. MFA registration, re-registration, recovery code reset, or authentication method change
9. Privileged session initiation via PAM, jumphost, bastion, or database admin tool
10. Service account used in an interactive session (terminal, browser, RDP) outside its expected automated context

File, Application & Cloud Storage Access Events

1. File or folder creation, modification, rename, or deletion (endpoint, SharePoint, S3, GCS, Azure Blob)
2. API key creation, rotation, scope expansion, or expiration
3. Cloud bucket or container policy change (S3 bucket policy, Azure Blob SAS, GCS IAM binding)
4. Database query execution on restricted or PII-classified tables; DLP policy block
5. Privileged session initiation (PAM, jumphost, bastion, or DBA tool login)
6. † Object storage access by an identity with no prior access history to that bucket or prefix
7. † Mass file download or API bulk-read exceeding baseline egress volume, correlated with a concurrent APM latency spike or error rate increase on the same service
8. Container image pull from non-approved registry; Kubernetes pod security context or RBAC change
9. Git repository permission elevation, branch protection bypass, or secret key commit
10. Shared link or external collaborator permission grant on SaaS document stores (SharePoint, Box, Google Drive)

Network Flow Records (Telemetry, Not Device Events)

1. Source/destination IP, port, protocol (TCP/UDP), duration, bytes transferred (NetFlow/IPFIX/sFlow)
2. DNS query and response: resolved domain, TTL, response time, NXDOMAIN frequency, subdomain entropy
3. TLS handshake: cipher suite, certificate validity, handshake failure, protocol version downgrade
4. HTTP transaction: method, URI path, status code, content-type, response size
5. VPC flow log telemetry (AWS, Azure NSG, GCP VPC), SD-WAN exporter data
6. † DNS tunneling indicators: high subdomain entropy, long query strings, repetitive patterns to a single domain
7. † Network flow correlated with APM: unusual egress from a service that is simultaneously showing elevated p99 latency (potential data exfiltration under load)
8. Connection to non-standard TLS ports (4443, 8443) from internal hosts (C2 beacon pattern)
9. Multi-connection fan-out: single source to 50+ destinations (botnet, DDoS staging, lateral movement)
10. † Cross-AZ or cross-region data transfer exceeding baseline, correlated with a recent deployment event or configuration change in the same namespace

Endpoint, Email & Gateway Threat Events

1. Executable or file hash detection and block by EDR/AV (CrowdStrike, SentinelOne, Defender, ClamAV)
2. Macro-enabled document delivered via email; sandbox detonation result
3. Payload download or C2 beacon from known-bad domain or IP (threat intel feed match)
4. Fileless or memory-only execution: PowerShell encoded command, WMI event subscription, .NET assembly injection
5. Sandbox or EML attachment rejection with telemetry capture
6. † New or modified cron job, scheduled task, or systemd service on a Linux host, correlated with a concurrent container image pull from a non-approved registry
7. † Unauthorized SUID/SGID binary creation, /etc/passwd modification, or kernel module load, correlated with an anomaly in the host's infrastructure metrics (CPU spike, memory pressure)
8. Registry modification: Run/RunOnce, Image File Execution Options, WMI persistence
9. Email gateway: SPF/DKIM/DMARC failure, malicious URL redirect chain, attachment MIME mismatch
10. Browser-based exploit: drive-by download, exploit kit hit, payload delivery via compromised CDN

Exploit & Attack Pattern Events

1. Buffer overflow or stack smash attempt (EDR syscall monitoring, Falco-style runtime detection)
2. SQL injection or XSS signature match in WAF logs (OWASP CRS 4.25 rule hit, rule IDs 941100+ / 942100+)
3. Exploit kit landing page hit followed by payload delivery (two-stage correlation)
4. Remote code execution via known CVE (CVE-to-asset mapping, patch status)
5. Lateral movement via SMB, WMI, PSExec, or RDP from a non-standard source host
6. † Cloud metadata service access (169.254.169.254) from a container or serverless function (credential theft), correlated with the function's APM trace showing an unusual external API call
7. † IAM privilege escalation chain: role assumption → policy modification → resource access, correlated with a CloudFormation/Terraform deploy event in the same account
8. Container escape: privileged container, host filesystem mount, /proc access from within a pod
9. DNS-based data exfiltration: encoded data in query names, high-volume TXT record queries
10. Ransomware precursor: mass file rename/encryption, shadow copy deletion, backup service termination, lateral spread within 15-minute window, correlated with a simultaneous drop in APM request volume (service disruption)

Behavioral & UEBA Anomaly Alerts

1. Impossible travel: authenticated session from geographically inconsistent locations within an impossible time window
2. Egress volume spike: data transfer rate exceeding 3σ above the user's 30-day baseline
3. Off-hours access to PII systems, financial databases, or privileged infrastructure
4. Privilege escalation without a corresponding change-management ticket in ITSM
5. Service account used in an interactive session outside its expected automated context
6. † New API consumer or OAuth app registered by a user with no prior API development activity, correlated with a new APM service appearing in the topology
7. † Cloud identity: IAM role assumed by an identity that has never assumed that role, correlated with a CloudTrail event showing a new resource creation in the same account
8. Authentication method change: user who exclusively uses MFA suddenly authenticates via password-only
9. Data access breadth expansion: user accessing 5+ resource types not accessed in the trailing 90 days
10. Session behavior deviation: command sequences inconsistent with the user's role, correlated with an anomaly in the host's process tree or network connections

Source Collectors and Forwarders. The Datadog Agent is the primary collection mechanism. It is a single binary that installs as a Windows Service, Linux daemon, or container and collects logs, metrics, traces, and security telemetry simultaneously. For organizations already running Datadog for observability, the agent is already deployed on every monitored host. Enabling the Security module does not require a new agent, a new forwarder, or a new collection pipeline. The agent is already there.

For high-velocity log streams, the Log Forwarder architecture uses AWS Lambda or Azure Functions as intermediary processors, handling batched, compressed log delivery without agent-side parsing. Organizations can also pipe data via syslog, HTTP API, Kafka, or S3/GCS/Azure Blob. No vendor-specific central forwarder (SNARE®, Spl UF) is required.

Agent-Level Filtering and Exclusion. The Datadog Agent supports source-side filtering through log_processing_rules (include_at_match, exclude_at_match, scrub, mask). Administrators can exclude specific log levels, keywords, source paths, application names, and event categories before data leaves the host. In practice, this means Windows Event Log channels can be scoped to Security, System, and Application while dropping Service Control Manager debug noise. Linux syslog facilities can be filtered to auth, authpriv, kernel, and daemon. The operational effect is reduced bandwidth and lower $/GB ingestion cost.

Deduplication Strategy. Datadog does not perform pre-ingest semantic or string-based deduplication. The rationale is identical to every other platform on this list: a brute-force attack is 500 rapid authentication failures, not one. Deduplication destroys the attack signature. Repetition is handled at the analytics layer:

• Rate and threshold rules apply sliding time windows and frequency baselines. 500 login failures from one source in 90 seconds triggers a threshold breach and anomaly score.
• Behavioral baselining (Identity Security module) dynamically models legitimate high-frequency patterns and deprioritizes them without altering stored telemetry.
• Alert aggregation groups related events by source, destination, user, and context for SOC workflow efficiency. Raw events remain individually queryable.

Storage and Compute. Ingested logs flow through Datadog's proprietary, auto-scaling analytics pipeline. Storage is managed SaaS. Compute scales independently of ingestion velocity. Retention is governed by configured short-term and long-term archive policies. There are no indexer licenses, no shard management, no hot/warm/cold index tiers to configure.

Scale: >10K EPS Handling. The Datadog Agent uses threaded writers, TLS multiplexing, and configurable flush intervals. The Log Forwarder architecture (Lambda/Functions) handles 10K–50K+ EPS through async batching and auto-scaling. The SaaS backend auto-scales compute and storage independently of ingest velocity. In managed deployments, the ingestion pipeline is not the scaling bottleneck. The scaling constraint is the $/GB invoice at high volumes, not the pipeline throughput.

Failure Modes at Scale. The primary operational risk is cost escalation at extreme volumes (>5 TB/day) without enterprise volume commitments. The secondary risk is the SIEM module's relative maturity: detection rule depth, UEBA baseline accuracy, and SOAR playbook breadth are still maturing compared to platforms with a decade of dedicated security R&D. The observability platform is mature. The security layer on top of it is younger.

Parser Framework. Dynamic regex extraction, JSON/XML unmarshalling, category auto-detection, and pipeline processors (splitter, classifier, scrubber, mask). The log source determines the format: Palo Alto PAN-OS syslog, Cisco ASA logging, Windows Event Log XML, Okta JSON, CloudTrail JSON. The Datadog Agent and ingestion pipeline adapt to the source format. The delimiter (tab, semicolon, pipe, space) is a property of the log source, not the SIEM.

Normalization Engine. Translates vendor-specific fields into Datadog's internal log model: host, service, source, status, message, @timestamp, tags. Network flows normalize to connection metadata. Device events retain security outcomes. Identity and cloud logs preserve session and context tags.

Schema Model. Datadog does not natively enforce the Splunk CIM™, the Elastic Universal Data Model (UDM), or the Open Cybersecurity Schema Framework (OCSF). It maintains its own field dictionary with cross-product alignment via ingest-time processors. Custom field mappings are handled through pipeline processing rules and tag extraction. For organizations that have standardized on CIM or UDM across multiple tools, Datadog introduces a parallel schema. Field aliasing (src_ip → @source.ip, uid → user.id) mitigates the mismatch but is a manual configuration step, not an automatic crosswalk.

Practical Implication. In a multi-tool SOC where the same analyst queries Datadog, Splunk, and Sentinel, maintaining three parallel field models and query syntaxes is a cognitive and operational cost. The Datadog field model is not harder than the others. It is different. In a single-platform environment, it is not a concern.

Query Language. Datadog uses its own log search syntax: status:error, @http.status_code:401, service:authd, source:okta. Full-text search, tag filtering, saved queries, time-series aggregations, and cross-log correlation. The syntax is not SQL, not SPL, not KQL, not ESQL. It is Datadog-native. For an analyst coming from Splunk (SPL) or Microsoft (KQL), the adjustment period is one to two weeks. The syntax is less expressive than SPL or KQL for complex multi-join forensic queries, but adequate for standard SOC investigation workflows.

The differentiator is the unified query context: a security query can join with APM metrics, infrastructure logs, container events, and deployment events in the same search. service:payments-api status:error can be correlated with @security.event_type:brute_force host:web-014 and a Kubernetes deployment event in the same time window, without exporting data to a separate SIEM. This is not available in any other platform on this list.

Hunting Workflows. Template-driven searches, baseline deviation tracking, saved anomaly queries, manual hypothesis building with native timeline visualizers. The hunting model is analyst-led, with ML-assisted anomaly scoring providing suggested investigation paths.

Dashboard Builder. Drag-and-drop widget layout (time series, geo map, pie, heatmap, query value, histogram). Role-based templates for CISO, SOC, Cloud Admin, and Compliance. Real-time streaming, alert-linked auto-refresh, executive security posture widgets. The dashboard ecosystem is mature because it is shared with the observability platform, which has been refined over a longer period.

BI and Reporting Integration. Webhook/API export, scheduled PDF/email reports, Notebook integration for investigation runbooks. Direct connectors to Tableau® and Power BI. For a CISO presenting to the board, the unified dashboard that shows both security posture and infrastructure health in a single view is operationally cleaner than maintaining separate SIEM and monitoring dashboards.

Where Detection Actually Comes From. The same architectural reality applies to Datadog as to every other platform. The detection signals are generated upstream:

• WAF and network security devices running OWASP CRS 4.25 or vendor-proprietary rulesets. The WAF detects the SQL injection. The WAF blocks the request. The WAF generates an alert. Datadog ingests that alert, correlates it with APM data (was the request hitting a production API? what was the response time? was there a concurrent deployment?), enriches it with IP reputation and asset criticality, and routes it to the SOC.
• EDR and endpoint protection platforms. Process-level behavioral detection is performed by the EDR agent (CrowdStrike, SentinelOne, Defender, Falco, or Wazuh FIM). Datadog ingests the EDR alert and correlates it with infrastructure context.
• Cloud audit logs. IAM privilege escalation, anomalous sign-in, resource misconfiguration — detected by pattern-matching against expected cloud identity behavior. The Identity Security module adds statistical anomaly scoring.
• CSM (Cloud Security Management). Continuous misconfiguration monitoring against AWS/Azure/GCP security baselines. This is a genuine Datadog-native detection capability, not dependent on an external tool. CSM scans cloud configurations continuously and generates findings.

The ML/AI Layer. Datadog's ML performs behavioral baselining (Identity Security), anomaly scoring, alert prioritization, and automated workflow triggering. It does not generate original threat signatures. It does not perform inline packet inspection. It does not detect novel zero-day exploits without a known indicator or behavioral deviation. It is the enrichment, correlation, and routing layer. The detection is upstream.

SOAR Depth. Datadog Workflows support condition-based triggers, conditional branching, API/webhook actions, and ITSM synchronization (ServiceNow®, Jira®, Slack®, PagerDuty®). The depth is functional for standard containment: block an IP, disable a user, isolate a host, open a ticket, notify the on-call engineer. For complex multi-system orchestration (coordinated containment across 200 endpoints, a cloud VPC, and an on-prem AD domain in a single sequence), the workflow engine may require external SOAR integration. The playbook library is smaller than Cortex SOAR, Splunk SOAR, or Sentinel SOAR.

A Note on the Unified Context as a Detection Multiplier. The Datadog-specific capability that no other platform on this list replicates is the native correlation of security events with application performance data. A SQL injection attempt (CRS rule hit) on a production API endpoint, correlated with a 40% p99 latency increase on that same endpoint in the preceding 10 minutes, correlated with a Kubernetes deployment event 15 minutes before the injection attempt, is a three-source correlation that would require data export and manual joining in a pure SIEM. In Datadog, it is a single query. For a DevOps-heavy organization where the SOC and SRE are the same team, this is a genuine operational advantage. For a traditional SOC where security and infrastructure are separate organizations, the advantage is less pronounced.

The SIEM Administrator Question. Same transformation as every SaaS platform on this list. The traditional SIEM infrastructure role (indexer sizing, shard tuning, forwarder patching, storage node management) is eliminated. The remaining role is security data architecture: ingestion policy design, detection rule tuning, UEBA baseline validation, compliance evidence management, integration architecture, and vendor management. For a CISO building the 2026 SOC org chart, the headcount model shifts from "SIEM administrators" to "security data engineers" and "detection engineers."

Pricing Model. Consumption-based. Costs are driven by log ingestion volume ($/GB), security module activation (CSM, SIEM, Identity Security, Runtime Security), user seat tiers (Standard, Pro), and long-term archive storage. The base log ingestion rate is publicly referenced at approximately $5.00/GB for log ingestion, with security modules adding 15–30% to the base telemetry cost. Volume discounts apply at enterprise tiers (>2 TB/day).

This is the highest publicly quoted $/GB rate among the twelve platforms in this review. For a 1 TB/day ingestion environment, the base log cost alone is approximately $15,000/month before security modules, seats, and archive storage. The total platform cost is higher.

Estimated Monthly Platform Costs. Projections based on Datadog's published $/GB rates and Security module tiering. Actual pricing requires a custom Datadog sales quote.

The effective cost differential versus the $3.00–$4.20/GB range seen in Securonix, Sentinel, or Elastic is material at scale. For a 3 TB/day environment, Datadog's total monthly platform cost is approximately 50–100% higher than the mid-range of the other platforms. The offsetting argument is the unified observability context: if the organization is already paying for Datadog APM, infrastructure monitoring, and log management, the incremental cost of the Security module is lower than the total cost of a separate SIEM plus the existing observability stack. For an organization that is not already in the Datadog ecosystem, the $5.00/GB base rate is a significant line item.

Search Economics. Search is not metered within retained log volume. There is no per-query charge, no per-result-set fee, and no per-GB-scanned penalty. A 12-month cross-source hunt incurs the same search cost as a 30-day search. Compute auto-scales for high-concurrency queries; these costs are absorbed into the platform subscription.

Storage Tiers

Both tiers are searchable without extra fees. Hot storage is not free; it is bundled in the base subscription. Archive storage is not free; it is priced at standard object storage rates. Storage costs scale linearly with retention duration.

User Seat Tiers

Seats are billed monthly per user. Enterprise contracts bundle seats at ingestion tiers with progressive discounts. All licensed roles have equal search access within the platform. Seat pricing covers platform capability, not query volume.

Volume and Commitment Scaling. Annual or multi-year subscriptions. Volume discounts at >2 TB/day. Multi-year commitments unlock additional reductions. No perpetual licenses.

Ecosystem Context. The 3,000+ integration count is the platform total. For a security-specific evaluation, the relevant number is the subset of integrations that ingest security telemetry (WAF logs, EDR alerts, identity logs, cloud audit logs). This subset is smaller than the 3,000+ figure implies. Verify coverage of your specific security log sources. The open-source detection and hardening layer (Falco, Wazuh FIM, Lynis, CrowdSec, Coraza/CRS, ClamAV, Chkrootkit) is not natively integrated. Alerts and telemetry from those tools are forwarded via syslog, HTTP API, or the Datadog Agent's log collection. The pipeline is straightforward but is an additional integration to maintain.

Named Enterprise Customers (Datadog-Specific):

• Coinbase
• DoorDash
• Shopify
• Instacart
• Uber
• Netflix
• Spotify
• Slack
• Twilio
• Zoom Video Communications
• Atlassian
• Discord
• Roblox

Public customer lists are restricted by NDA. The above represents a subset of the full deployment base. Order does not indicate deployment scale or revenue impact. A significant portion of these organizations are Datadog observability customers who activated the Security module, not organizations that selected Datadog as a primary SIEM through a competitive procurement process.

MSSP and Managed-Services Note. Firms including Accenture, Cognizant, Wipro, DXC Technology, CGI, Leidos, Booz Allen Hamilton, Genpact, HCLTech, Capgemini, Infosys, Deloitte, EY, PwC, KPMG, and NTT DATA deploy multiple security platforms across their client portfolio. Their presence in any single vendor's customer list reflects multi-tenant managed-service delivery, not a primary SIEM selection. They are excluded from the named-customer list above.

Deployment Context Note. For Datadog specifically, the CISO evaluating this platform should ask a direct question of the vendor: of your named security customers, how many are also Datadog observability customers, and what percentage selected the Security module as a feature activation versus a standalone SIEM procurement? The answer to that question determines whether the customer base validates the platform as a SIEM or as a security add-on to an observability stack.

Analyst Positioning. Datadog appears in Gartner® and Forrester® observability and cloud security market guides. The Security platform is positioned as a strong cloud security and identity monitoring offering. As a dedicated SIEM, it is positioned as an emerging player, not a market leader. PeerSpot reviews reflect strong satisfaction with unified observability-and-security correlation and weaker depth in dedicated SIEM features (detection rule library, SOAR breadth, UEBA depth) compared to Splunk, Sentinel, or Elastic.

Where Datadog Competes Effectively:

• Unified observability-and-security context. The native correlation of security events with APM traces, infrastructure metrics, container events, and deployment pipelines in a single query context is a genuine differentiator. No other platform on this list replicates this. For a DevOps-heavy organization where the SOC and SRE operate as one team, the operational advantage in investigation speed is material.
• Zero new infrastructure for security. For organizations already running the Datadog Agent for observability, activating the Security module requires no new agent deployment, no new forwarder, no new collection pipeline. The telemetry is already flowing. The security layer is a feature toggle, not a new integration project.
• CSM maturity. Cloud Security Management is a mature, well-regarded capability for continuous cloud posture monitoring across AWS, Azure, and GCP. It is deeper and more refined than the CSPM modules in several competing platforms.
• Developer and SRE workflow alignment. The query syntax, dashboard ecosystem, and alerting model are familiar to engineering teams. The security team does not operate in a separate tooling paradigm from the infrastructure team.

Where Datadog Is at a Disadvantage or Requires Diligence:

• Cost. At approximately $5.00/GB base ingestion with 15–30% security module surcharge, Datadog is the highest-cost platform in this review at equivalent ingestion volumes. For a 3 TB/day environment, the total monthly platform cost is $42,000–$60,000, compared to $23,000–$31,000 for Securonix or $24,000–$32,500 for Microsoft Sentinel. The cost differential is $10,000–$25,000/month. Over a 3-year contract, that is a $360,000–$900,000 difference. The unified observability context must justify that premium, or the organization should evaluate whether a separate SIEM plus the existing observability stack is more cost-effective.
• SIEM module maturity. The SIEM module reached GA in 2023–2024. The detection rule library, UEBA depth, and SOAR playbook breadth are younger than Splunk ES (2013), Microsoft Sentinel (2019), IBM QRadar (2009), or Elastic Security (2018). A CISO evaluating detection depth for a high-threat environment should weight this maturity differential.
• UEBA depth. The Identity Security module covers standard identity threat patterns (impossible travel, privilege abuse, anomalous sign-in). It is not as deep as purpose-built UEBA platforms (Securonix, Exabeam, Microsoft Identity Protection) in behavioral baselining granularity, cross-system correlation, and insider threat modeling.
• SOAR depth. Datadog Workflows are functional for standard containment. They are not as deep as Cortex SOAR, Splunk SOAR/Phantom, or Sentinel SOAR for complex multi-system orchestration.
• Query language expressiveness. Datadog's log search syntax is adequate for standard SOC workflows but less expressive than SPL or KQL for complex multi-join forensic queries. In a large-scale incident investigation requiring deep cross-source correlation, the query language may hit expressiveness limits.
• Ecosystem lock-in. The unified platform is the advantage and the risk. Advanced features, the unified query context, and the 3,000+ integrations are locked to the Datadog stack. Cross-platform data export incurs archival and egress costs. Exiting Datadog means rebuilding the observability stack, not just the SIEM.
• Vendor concentration. Datadog is a public company (NASDAQ: DDOG). Financial stability is verifiable through earnings reports. However, the company's strategic focus has historically been observability and APM. The security platform is a growth vector, not the core business. A CISO signing a 5-year contract should assess the company's long-term strategic commitment to the security vertical.

Datadog Security is a strong cloud security and unified observability-and-security platform for organizations that are already in the Datadog ecosystem or that operate in a DevOps-heavy environment where the correlation between application performance and security events is a primary operational concern. The unified query context, zero-new-infrastructure security activation for existing Datadog customers, and mature CSM capability are genuine differentiators.

As a standalone SIEM evaluated against Splunk, Microsoft Sentinel, Elastic Security, and Securonix in a competitive procurement, the SIEM module's relative maturity, the $5.00/GB base ingestion cost, the shallower UEBA and SOAR depth, and the younger detection rule library place it behind the purpose-built SIEM platforms. The question for the CISO is not "is Datadog Security a good SIEM?" The question is "is the unified observability-and-security context worth a 50–100% cost premium over a purpose-built SIEM, and is the security module's maturity sufficient for my threat environment?"

For an organization with 500–5,000 endpoints, a DevOps-heavy culture, a unified SOC/SRE team, and an existing Datadog observability deployment: the Security module is a natural, low-friction addition. For an organization with 10,000+ endpoints, a traditional SOC structure, a high-threat environment (financial services, healthcare, government), and no existing Datadog deployment: the cost premium and maturity gap are difficult to justify against a purpose-built SIEM.

Ideal buyer profile: DevOps-heavy organization (500–5,000 endpoints), already running Datadog for observability, with a unified SOC/SRE team, moderate threat environment, seeking to consolidate security monitoring into the existing platform without a new procurement cycle. Ingestion volume typically 0.5–3 TB/day.

Key RFP questions for the Datadog evaluation:

1. Of your named security customers, what percentage are also Datadog observability customers, and what percentage selected the Security module through a standalone SIEM procurement?
2. Provide a detection rule count and MITRE ATT&CK® coverage comparison against your top two competitive SIEM alternatives.
3. Demonstrate the UEBA baselining period in a 30-day proof-of-concept. Measure false-positive rate at day 1, 7, 14, and 30.
4. Execute the organization's top-10 incident response scenarios in Datadog Workflows. Identify which require external SOAR.
5. Provide the total 3-year TCO model including ingestion, security modules, seats, archive storage, and support at the organization's actual ingestion volume.
6. Confirm FedRAMP authorization scope, region, and level. Obtain the authorization letter.
7. Detail the data export and egress costs for a multi-year compliance retention requirement.
8. Provide the 2-year product roadmap for the Security vertical with specific feature commitments.
9. Confirm the support model, SLA, and escalation path for each geographic region.
10. Provide 3–5 referenceable enterprise customers in the organization's industry vertical at comparable ingestion scale, with the deployment context (primary SIEM vs. security add-on).

Red flags to watch for:

• Inability to separate the security platform's capabilities from the observability platform's capabilities in a feature comparison. If the sales team presents 3,000+ integrations as security-specific, push back. The number is platform-wide.
• Reluctance to provide the detection rule count or MITRE ATT&CK coverage mapping. A mature SIEM vendor publishes this.
• Bundling pressure: attempts to lock security, observability, APM, and infrastructure monitoring into a single non-modular contract.