Will Datadog Cloud SIEM beat Splunk + Sentinel?

The security review that starts as a cost question

The scenario repeats across cloud-native companies with 500 to 5,000 employees. A security engineering lead inherits a stack that grew by accident: Splunk Enterprise Security for the SOC because that is what the previous CISO bought, Microsoft Sentinel running in parallel because the Microsoft 365 E5 license made it look free, and Datadog for infrastructure, APM, and log management because the platform team standardized on it three years ago. Three ingestion pipelines, three query languages, three sets of parsing rules, three retention policies, and three renewal dates spread across the fiscal year so nobody ever sees the total in one number.

Then finance asks for the total. The Splunk line is the obvious one — ingest-priced licensing, and every GB the cloud footprint adds shows up as a line item. But the Datadog log bill is comparable in size, and the two systems are ingesting substantially the same data. The CloudTrail stream feeds both. The Kubernetes audit log feeds both. The application logs from the payment service feed both, because the SOC needs them for detection and the platform team needs them for debugging. Somewhere between 30% and 60% of the security data volume is duplicated across tools that never talk to each other.

That duplication is what creates the opening for Datadog Cloud SIEM, and it is worth being precise about what the opening actually is. It is not a claim that Datadog's detection engineering is better than Splunk's — it is not, on breadth. It is not a claim that Datadog integrates with Microsoft's identity and endpoint estate better than Sentinel does — it does not, and it will not, because Microsoft controls both sides of that integration. The opening is that a company already paying to move logs into Datadog can turn on detection against those same logs without standing up a second pipeline, and for a specific class of buyer that arithmetic is decisive.

The buyer who finds it decisive has a recognizable profile. Small security team, often three to ten people, frequently with no dedicated detection engineer. Workloads concentrated on AWS or GCP rather than on-premise Windows estates. A platform engineering group that already owns the Datadog contract and has opinions about adding tools. Compliance obligations that are real but not FedRAMP-High — SOC 2, maybe PCI scope limited to a payment path, maybe HIPAA for a health-adjacent product. For that team, the question is not "which SIEM has the deepest detection content" but "which SIEM can three people actually operate."

The buyer who finds it irrelevant is equally recognizable. A Fortune 500 SOC with twenty-four analysts on shifts, a detection engineering team that writes its own content, an MSSP under contract, and a compliance auditor who wants to see the same tooling the auditor saw at the last five clients. That buyer is not evaluating Datadog Cloud SIEM as a Splunk replacement. At most that buyer is evaluating it as a cloud-workload feed into an existing Splunk deployment, which is a different and much smaller sale. Any RevOps team modeling this market needs both segments in the model, because a pipeline that treats them as one segment will forecast badly.

How the shared-pipeline advantage actually works

The mechanism is worth walking through concretely, because the marketing version ("unified platform") obscures what is technically different. In a conventional split-stack architecture, security logs and observability logs travel separate paths from the moment they leave the host. Splunk collects through universal forwarders that ship to heavy forwarders, which route to indexers, which are searched by search heads. Sentinel collects through the Azure Monitor Agent or through native connectors into a Log Analytics workspace. Datadog collects through the Datadog Agent into its own logs backend. Each path has its own parsing configuration, its own field extraction, its own storage, and its own cost meter.

Datadog Cloud SIEM does not add a path. It adds a detection layer that reads the log stream already flowing through the Datadog Agent and the existing log pipeline. The practical consequences are specific rather than abstract:

Parsing happens once. A custom application log format parsed into structured fields for observability dashboards is already parsed for detection rules. In the split-stack case that same format needs a Splunk props/transforms configuration and a Datadog pipeline processor, maintained by different teams, drifting apart over time. Field-name drift between the two is a recurring source of broken detections — a rename that ships in the observability pipeline silently breaks a correlation search nobody notices until an audit.

Retention and indexing decouple from detection. Datadog's log pipeline separates ingestion from indexing, so a security team can run detection rules against a stream while indexing only a subset for search. This matters most for high-volume, low-signal sources — VPC flow logs, load balancer access logs — where the detection value is real but the cost of indexing everything is not defensible.

Enrichment is already present. Host tags, Kubernetes labels, service names, and deployment metadata are attached to logs for observability reasons. Detection rules and the analyst investigating an alert inherit them without a separate CMDB lookup or asset-inventory join.

The split-stack version of that diagram has two of everything on the left and a manual context switch in the middle. That context switch is the real cost. An analyst working a Splunk ES notable event has the log evidence but not the runtime context — to see whether the container that made the suspicious API call was also showing anomalous memory growth, or whether the user session that preceded it looked like a real browser, requires opening a different tool, re-establishing time bounds, and matching entities by hand. Each hop is minutes. Multiply by alert volume and the arithmetic gets uncomfortable.

The counter-argument deserves equal weight: a unified pipeline is also a unified failure domain. A Datadog outage takes observability and detection down together, where a split stack degrades gracefully. Security teams that have lived through a monitoring outage during an incident take this seriously, and it is a legitimate reason a mature SOC keeps its detection substrate separate from its ops tooling. The unified-pipeline argument is an efficiency argument, not a resilience argument, and vendors that conflate the two are selling.

What the numbers actually support

Precision matters here more than enthusiasm, because most of the comparison figures circulating in this market are directional rather than verified, and a RevOps or security team that builds a business case on unverified numbers gets embarrassed in the second budget meeting. Sorting them by confidence:

Firm facts. Cisco closed its acquisition of Splunk in March 2024 in a deal valued at approximately $28 billion — the largest acquisition in Cisco's history and one of the largest in enterprise software. Splunk was a multi-billion-dollar revenue business at the time of acquisition, with Enterprise Security as its flagship security product and Phantom, acquired in 2018, as its SOAR component. Microsoft Sentinel is a first-party Azure service built on Log Analytics, queried with KQL, and integrated with Defender XDR. Datadog is a public company (NASDAQ: DDOG) reporting revenue in the billions annually, with tens of thousands of customers, and Cloud SIEM is one of a security product family that also includes Cloud Security Management, Application Security Management, Workload Protection, and Sensitive Data Scanner. Datadog does not break out security-product revenue as a separate reported segment.

Directional but defensible. Security products are a small minority of Datadog's total revenue — a single-digit percentage share is the reasonable reading from what the company discloses about product-line adoption. Cloud SIEM customer counts are a fraction of Datadog's total customer base, since the product attaches to accounts that already run log management, itself a subset. Any specific customer number quoted for Cloud SIEM is an estimate, and should be labeled as one.

Model your own, do not borrow. The TCO comparison is where borrowed numbers do the most damage. The frequently repeated claim of a 30% to 50% saving versus a dual-tool stack is not a benchmark; it is a range that depends almost entirely on how much of your security data is already in your observability pipeline. The honest way to model it is a four-line calculation, run on your own volumes:

1. Duplicated volume. Measure GB/day flowing into both your SIEM and your observability tool. In cloud-native environments this is commonly 30% to 60% of security volume, but measure rather than assume — a Windows-heavy estate will be far lower.
2. Marginal cost of the duplicate. Price that duplicated volume at your actual contracted rate, not at list. Enterprise SIEM discounts at volume are substantial, and a business case built on list pricing will not survive contact with your own procurement team.
3. Pipeline labor. Estimate the engineering hours spent maintaining the second pipeline — parser upkeep, forwarder fleet management, index sizing, upgrade cycles. For a mid-size deployment this is frequently a meaningful fraction of one full-time engineer.
4. Migration drag. Subtract the transition cost, which is the line most business cases omit. Rewriting detection content from SPL or KQL into Datadog's query syntax is manual work; there is no reliable automatic translator between these languages, because the semantics of the correlation constructs do not map one-to-one. A mid-size migration of a few hundred active detections realistically runs three to six months, with a measurable productivity dip while analysts learn a new query language and new investigation workflow.

On pricing structure rather than specific rates: all three vendors publish list pricing that changes, so check the current pages rather than trusting any number in an article. What is structurally stable is the *shape* of each model. Splunk's heritage is volume-based licensing, which means cloud growth translates directly into license growth and creates the well-known incentive to filter data before it reaches the SIEM. Sentinel prices per GB analyzed with commitment tiers and offers a data-ingestion benefit for certain Microsoft 365 E5 sources, which is why Microsoft-heavy shops compute Sentinel as near-free at the margin — a real economic advantage that no competitor can answer with features. Datadog prices log ingestion separately from indexing and prices Cloud SIEM against analyzed volume, which is what makes the "already ingesting, just add detection" motion economically coherent.

Detection content breadth is the number most often stated too confidently. Datadog ships hundreds of out-of-the-box detection rules weighted heavily toward cloud control planes: AWS CloudTrail, GCP Cloud Audit, Azure Activity, Kubernetes audit events, and SaaS identity and developer platforms. Splunk's ecosystem — Enterprise Security Content Update, Splunkbase apps, community and Sigma-derived content — is larger by an order of magnitude and spans decades of on-premise threat patterns. Any claim of "80-90% coverage out of the box" for either product is unverifiable, because coverage is meaningless without a stated threat model. The defensible version: if your risk surface is cloud control plane and identity, Datadog's default content covers a high share of what matters to you. If your risk surface includes Windows domain compromise, legacy authentication, and OT networks, it does not, and Splunk's does.

Where each product actually wins, and what else to consider

The three-way comparison resolves cleanly once you stop asking which is best and start asking which fits a given estate.

Splunk Enterprise Security wins when the SOC is staffed and mature, when detection engineering is an in-house function that writes custom correlation content, when the environment is hybrid with substantial on-premise Windows and network infrastructure, when SOAR playbooks are already built in Phantom, when an MSSP is under contract and staffs analysts trained on SPL, and when auditors and cyber-insurance underwriters expect to see recognized tooling. The Cisco acquisition adds a further dimension: bundling Splunk with Cisco networking, ThousandEyes, and AppDynamics gives Cisco a platform story it did not previously have, and for accounts already deep in Cisco's estate that bundle can be priced aggressively. Large platform integrations historically move slowly, but a competitor betting on Cisco moving slowly is betting on an execution failure rather than a structural advantage — which is a weak position.

Microsoft Sentinel wins when the estate is Microsoft-centric: Entra ID as the identity provider, Defender for Endpoint on the fleet, Microsoft 365 as the collaboration layer, and Azure as the primary cloud. The bundle economics are the decisive factor and they are not really contestable — when the marginal cost of ingesting your highest-value security telemetry approaches zero and the identity, endpoint, and email signals arrive natively enriched, competing feature-by-feature misses the point. Sentinel's weakness is symmetric: multi-cloud parity. AWS and GCP telemetry reaches Sentinel through connectors that work but do not carry the same native fidelity as Azure sources, and teams running primarily outside Azure end up paying a translation tax.

Datadog Cloud SIEM wins when the estate is cloud-native, the security team is small, Datadog log management is already deployed at scale, the threats that matter are control-plane and identity threats rather than endpoint and domain threats, and the buyer is a security-minded platform engineer or a small security team rather than a traditional SOC. It also wins on a second-order motion that gets underweighted: the security-product family cross-sells to each other. A team that adopts Cloud SIEM frequently adds Cloud Security Management for posture and Workload Protection for runtime, and that bundle competes against a different set of vendors than Splunk does.

Alternatives outside the three-way frame deserve mention because serious evaluations include them. Google Security Operations, built on the Chronicle acquisition, competes on a flat-rate-by-employee-count pricing model that decouples cost from data volume — attractive to teams whose SIEM bill grows faster than their headcount. Elastic Security offers an open-source-rooted stack with detection rules published publicly, appealing to teams that want to self-host or avoid per-GB pricing. Panther and Matano address the detection-as-code segment directly, aimed at engineering-led security teams that would rather write Python detections against a data lake than click through a rules UI. CrowdStrike's Falcon LogScale competes on ingest economics from an endpoint-first position. A team that evaluates only Datadog, Splunk, and Sentinel has narrowed the field before doing the work.

The pitfalls that sink these migrations

Underestimating the query-language transition. SPL and KQL both encode years of institutional knowledge in saved searches, dashboards, and analyst muscle memory. Migration plans routinely budget for rewriting detection rules and forget the rest: hunt queries, compliance reports, executive dashboards, on-call runbooks that reference specific search strings. The avoidance is to inventory everything that contains a query before committing to a timeline, then rank by actual use — a substantial share of saved content in any long-lived SIEM has not been run in a year and should be retired rather than migrated.

Treating detection-rule counts as a coverage metric. A vendor claiming a thousand rules and one claiming three hundred may have identical coverage of your threat model. The avoidance is to map your top twenty threat scenarios — using MITRE ATT&CK technique IDs so the mapping is portable across vendors — and test each candidate against those specific scenarios in a proof of concept with your own data. This is a two-to-four-week exercise and it is the single highest-value step in the evaluation.

Assuming the observability team will absorb the security workload. The unified-pipeline argument implies shared ownership, and shared ownership without an explicit RACI produces gaps. The platform team owns the pipeline; the security team owns the detections; nobody owns the parser change that broke three detections. The avoidance is to write down which team owns pipeline configuration, which owns detection content, and what the change-review process is for pipeline edits that affect security fields — before the migration, not after the first missed alert.

Ignoring the retention and compliance floor. Many frameworks and contracts require security log retention measured in months or years, and the cost profile of long-tail retention differs sharply across these products. A TCO model built on ingest and analysis costs while omitting a year of cold retention will be wrong in a direction that is expensive to discover at renewal. The avoidance is to price the full retention obligation across all candidates, including retrieval cost for archived data, since some models make storage cheap and retrieval expensive.

Running both tools indefinitely. The most common failure mode is not choosing wrong; it is not choosing. A team adds Datadog Cloud SIEM for cloud workloads intending to retire Splunk, then never retires it because a handful of legacy detections have no clean home. The result is the dual-tool cost the migration was supposed to eliminate, plus a new tool. The avoidance is a decommission date written into the migration plan with a named owner and an explicit list of what happens to the orphan detections — rewrite, retire, or accept the risk with sign-off.

Buying on the platform story when the SOC is the constraint. Unified context genuinely speeds investigation, but it does not substitute for analyst capacity, an on-call rotation, or a documented incident response process. A team without those does not have a tooling problem. The avoidance is honest: if alerts currently go unreviewed, no SIEM fixes that, and the budget is better spent on staffing or a managed detection and response partner than on a migration.

Forecasting the market as one segment. For anyone modeling this competitively — vendor RevOps teams especially — the cloud-native mid-market and the regulated enterprise SOC behave like different markets with different sales cycles, different champions, and different win rates. Blending them produces a pipeline forecast that is wrong in both directions at once: too optimistic on enterprise displacement, too pessimistic on the land-and-expand motion inside existing observability accounts.

Related questions

Can Datadog Cloud SIEM fully replace Splunk Enterprise Security?

For a cloud-native company with a small security team and workloads concentrated on AWS or GCP, frequently yes. For a hybrid enterprise with on-premise Windows infrastructure, mature SOAR playbooks, and an MSSP contract, no — the detection content breadth and analyst workflow depth are not equivalent.

Is Microsoft Sentinel really free with an E5 license?

Not free, but heavily subsidized. Microsoft offers a data-ingestion benefit for certain Microsoft 365 sources, which substantially lowers the marginal cost of the highest-value telemetry in a Microsoft estate. Non-Microsoft and third-party data still bills at standard rates. Check current terms directly.

How long does a Splunk-to-Datadog SIEM migration take?

Realistically three to six months for a mid-size deployment, driven by manual detection-rule rewriting rather than data onboarding. Expect a measurable analyst productivity dip during transition as teams learn a new query language and investigation workflow. Inventory all saved content first.

Does the Cisco acquisition make Splunk stronger or weaker?

Structurally stronger on distribution and bundle economics — Cisco can package Splunk with networking, AppDynamics, and ThousandEyes into accounts Splunk could not reach alone. The risk is integration execution, which is historically slow at this deal size, but betting against it is a weak strategy.

Should we evaluate anything beyond these three?

Yes. Google Security Operations prices by employee count rather than data volume, Elastic Security offers a self-hostable stack with public detection rules, and Panther and Matano serve detection-as-code teams. Narrowing to three vendors before scoping your threat model skips the actual work.

FAQ

What exactly is the difference between Datadog Cloud SIEM and Datadog's other security products?

Cloud SIEM handles threat detection against log data — rules that fire signals when log patterns match known attack behavior. Cloud Security Management covers posture: misconfigurations, compliance drift, and infrastructure risk. Application Security Management detects attacks against running applications via the APM instrumentation. Workload Protection covers runtime threats on hosts and containers. They share the same agent and data platform, which is why they cross-sell to each other, but they answer different questions and are priced separately.

If our data is already in Datadog for observability, is enabling Cloud SIEM genuinely cheap?

Cheaper than standing up a separate pipeline, but not free. Cloud SIEM prices against analyzed volume, so the security-relevant data still meters. The saving is structural rather than promotional: you skip the second ingestion path, the second set of parsers, and the engineering time to maintain them. Model it against your own contracted rates and your own measured duplication percentage — the widely quoted savings ranges are not benchmarks and should not appear in your business case as if they were.

Does the shared observability graph actually reduce investigation time, or is that marketing?

The mechanism is real and the magnitude is unmeasured. Having the alert, the container metrics, the trace, and the user session in one view with consistent entity tagging removes context-switching that split stacks require. Whether that saves five minutes or fifteen per investigation depends entirely on your alert mix and your analysts' familiarity with the tooling. Treat it as a genuine architectural difference, not a quantified benefit, and measure it in a proof of concept against your own alerts.

Why does Splunk still win Fortune 500 deals if its licensing is expensive?

Because at that scale the license is not the dominant cost — analyst headcount, detection engineering, and the risk of a missed incident are. Splunk brings the deepest content library, mature SOAR, an MSSP bench of trained analysts, and audit familiarity that shortens compliance conversations. Switching costs compound this: years of custom SPL content, tuned playbooks, and trained staff represent an investment that a licensing delta rarely justifies abandoning.

What is the strongest argument against consolidating security and observability on one vendor?

Shared failure domain and concentrated commercial leverage. A platform outage takes down monitoring and detection together, where a split stack degrades gracefully — and security teams who have worked an incident during a monitoring outage weigh that heavily. Commercially, putting observability and security on one contract removes your ability to negotiate one against the other at renewal. Both are legitimate reasons mature organizations keep the substrates separate, and neither is answerable with features.

How should a RevOps team model this competitive market?

As two distinct segments, not one. The cloud-native land-and-expand motion inside existing Datadog observability accounts has a short cycle, a platform-engineering champion, and high attach rates. Displacing Splunk in a regulated enterprise SOC has a long cycle, a CISO champion, security-review gates, and a low win rate. Blending them into one pipeline model produces a forecast that overstates enterprise displacement and understates the expansion motion simultaneously.

Sources

• Datadog Cloud SIEM product page: https://www.datadoghq.com/product/cloud-siem/
• Datadog security documentation: https://docs.datadoghq.com/security/
• Cisco completes acquisition of Splunk (March 2024): https://newsroom.cisco.com/c/r/newsroom/en/us/a/y2024/m03/cisco-completes-acquisition-of-splunk.html
• Splunk Enterprise Security: https://www.splunk.com/en_us/products/enterprise-security.html
• Microsoft Sentinel overview documentation: https://learn.microsoft.com/en-us/azure/sentinel/overview
• Microsoft Sentinel pricing: https://azure.microsoft.com/en-us/pricing/details/microsoft-sentinel/
• Datadog investor relations and SEC filings: https://investors.datadoghq.com/
• MITRE ATT&CK framework: https://attack.mitre.org/
• Google Security Operations: https://cloud.google.com/security/products/security-operations
• Elastic Security: https://www.elastic.co/security

Related on PULSE

• [How does Datadog defend against Microsoft Sentinel + Azure Monitor?](/knowledge/q1680)
• [Will Datadog beat Splunk in observability by 2027?](/knowledge/q1670)
• [Datadog vs Splunk — which should you buy?](/knowledge/q1679)
• [Should I learn Datadog or Splunk in 2027?](/knowledge/q1702)
• [What is Datadog enterprise win-rate vs Splunk in 2026?](/knowledge/q1708)
• [How does Datadog onboarding compare to Splunk?](/knowledge/q1722)