title: "Datadog EU Alternative 2026: GDPR, CLOUD Act & NIS2-Compliant Observability for European SaaS Teams" date: "2026-05-07" description: "Datadog routes application logs, distributed traces, and APM metrics containing PII to US-controlled infrastructure — a GDPR Article 44 transfer risk most European SaaS teams haven't assessed. This guide covers what Datadog actually collects, why it violates GDPR, and how to migrate to an EU-sovereign observability stack in 2026." tags: ["datadog", "eu-alternative", "gdpr", "cloud-act", "nis2", "observability", "apm", "grafana", "opentelemetry", "developer-guide", "2026"]

Datadog EU Alternative 2026: GDPR, CLOUD Act & NIS2-Compliant Observability for European SaaS Teams

If your European SaaS product is instrumented with Datadog, your application logs, distributed traces, and APM metrics are flowing continuously to a US-controlled data processor under US jurisdiction.

This is not a theoretical GDPR risk. It is an ongoing Article 44 transfer of personal data to a third country. Every log line containing a user ID, email address, IP address, or session token is personal data under GDPR. Every distributed trace that includes a customer identifier or request payload is personal data. Datadog — a publicly traded US corporation headquartered in New York — stores all of this data under a legal framework that includes the CLOUD Act.

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) allows US law enforcement and intelligence agencies to compel US cloud providers — including Datadog — to produce stored data regardless of where the data is physically stored. Datadog's EU data centers do not insulate European companies from this legal exposure.

This guide explains what Datadog actually collects, which GDPR obligations it triggers, why NIS2 and DORA make this a compliance priority in 2026, and how to migrate to an EU-sovereign observability stack.

What Datadog Actually Collects and Why It Is Personal Data

Most engineering teams think of observability data as purely technical — metrics, error counts, latency histograms. In practice, the data Datadog ingests from a typical SaaS application is saturated with personal data.

Application Logs

Log lines routinely contain personal data depending on what your application logs at INFO or DEBUG level:

• HTTP access logs: client IP addresses (personal data under GDPR), user agent strings, referrer URLs
• Authentication events: usernames, email addresses, login attempt details, session identifiers
• API request logs: URL parameters and request bodies that may include customer IDs, order numbers, or filter terms containing names
• Error traces: stack traces that surface internal data structures containing customer identifiers
• Audit logs: user actions, resource names, modification history

If you use structured logging with context propagation — which is the modern best practice — your log lines likely include user IDs or customer IDs as fields on every log line emitted during a request. These propagated context fields mean that every log line emitted while processing a user request carries that user's identifier.

Distributed Traces (APM)

Distributed tracing captures the complete request lifecycle across services. A single trace for a typical API request may include:

• The authenticated user's identifier (propagated through the trace context)
• The specific database queries executed (which may include PII in WHERE clauses)
• The downstream services called with their parameters
• The response codes and latencies (indirectly revealing whether users hit errors)
• Custom span attributes that your developers added for debugging (frequently containing customer context)

Infrastructure Metrics

Host-level metrics are generally not personal data — CPU usage, disk I/O, and network throughput do not identify individuals. However, application-level metrics with high-cardinality dimensions often are:

• Request counts tagged by user_id or customer_id
• Error rates broken down by user_tier or account_id
• API usage metrics labeled with authentication context

The moment you add customer-identifying tags to your metrics, those metrics become personal data under GDPR's broad definition in Article 4(1).

GDPR Obligations Triggered by Datadog

Article 44 — Transfers to Third Countries

GDPR Article 44 prohibits transfers of personal data to third countries (countries outside the EEA) without an adequate level of protection. The EU-US Data Privacy Framework (DPF) provides a transfer mechanism for US companies that self-certify, and Datadog participates in the DPF.

However, the DPF remains under legal challenge following the Schrems I and Schrems II pattern. The DPF was adopted in July 2023 and a legal challenge (Schrems III) has been filed. If the CJEU invalidates the DPF — as it invalidated Privacy Shield in 2020 — companies relying solely on DPF for Datadog transfers would face immediate compliance failures.

Beyond DPF fragility, the fundamental problem is that EU DPF certification does not override the CLOUD Act. Datadog, as a US entity, remains subject to US government compulsion orders for data in its possession regardless of the transfer mechanism used. The DPF does not — and cannot — grant immunity from US surveillance law.

Article 28 — Data Processor Agreement

If Datadog processes personal data on your behalf (which it does when it ingests logs, traces, and metrics containing personal data), you must have a Data Processing Agreement (DPA) with Datadog that meets GDPR Article 28 requirements before sending any personal data.

Datadog offers a DPA through its Data Privacy page. Many engineering teams instrument their applications with Datadog before legal review of the DPA, meaning they have been transferring personal data without a compliant agreement in place.

The DPA requirement also means you must be able to document exactly what personal data Datadog processes for your RoPA (Records of Processing Activities, Article 30), and you must include Datadog in your sub-processor disclosure to data subjects.

Article 32 — Security of Processing

GDPR Article 32 requires appropriate technical and organizational measures to ensure security appropriate to the risk. Sending personal data to a third-party observability vendor introduces an additional attack surface:

• Datadog's infrastructure has been a breach target — any compromise of your Datadog account exposes all logs, traces, and metrics, including personal data
• API keys with write access to Datadog, if exposed, can be used to ingest forged log data
• Datadog's access control model must be managed to prevent unauthorized access to logs containing personal data

Article 5(1)(c) — Data Minimisation

Application logging frequently violates the data minimisation principle. If your application logs full request bodies in DEBUG mode, or if structured logging propagates user context broadly, you are likely collecting far more personal data in your observability pipeline than necessary for the stated purpose (application monitoring).

Datadog's powerful filtering and exclusion rules can mitigate this, but they require explicit configuration. Default instrumentation typically over-collects.

CLOUD Act Exposure: Why EU Data Centers Are Not Enough

Datadog operates data centres in Europe (Ireland, Frankfurt). A common misconception is that EU data residency eliminates CLOUD Act exposure.

It does not.

The CLOUD Act applies to US service providers regardless of where the data is stored. When a US court or executive authority serves Datadog with a CLOUD Act order, Datadog is legally compelled to produce the data — including data stored in its EU data centers. The CLOUD Act explicitly supersedes data residency arrangements with its text: "A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States."

EU data residency is a useful feature for data sovereignty marketing. It is not a legal shield against US government data demands.

The legal shield is having your data stored with a provider that is not subject to US law — meaning a provider incorporated and operating entirely under EU law, without US parent company ownership.

NIS2 and DORA: Why Observability Vendor Risk Is Now a Compliance Requirement

NIS2 Article 21 — Cybersecurity Risk Management Measures

NIS2 Article 21 requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage risks to network and information systems. Sub-clause (2)(d) specifically covers supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.

Your observability vendor is a supplier to your network and information systems. For a NIS2 in-scope entity, this means you must assess Datadog as a supply chain risk — including the risk that the US government compels Datadog to produce your production logs during a law enforcement investigation.

DORA Article 28 — ICT Third-Party Risk Management

DORA Article 28 requires financial entities in scope to maintain a Register of Information for all ICT third-party service arrangements and conduct due diligence on critical or important ICT third-party service providers. An observability platform with access to production application logs, traces, and metrics is a strong candidate for classification as a critical ICT third-party service provider.

Financial entities under DORA cannot delegate away the obligation to audit their ICT supply chain. Using a US-controlled observability vendor without documented risk assessment and mitigation is a DORA compliance gap.

EU-Native Alternatives to Datadog

1. Self-Hosted Grafana Stack (Grafana + Victoria Metrics + Loki + Tempo)

The gold standard for EU-sovereign observability. All four components are open-source and can be deployed entirely on EU infrastructure under your direct control.

Components:

• Grafana — dashboards and alerting (Apache 2.0 license, AGPL for cloud features, self-hostable)
• Victoria Metrics — high-performance time-series database, drop-in Prometheus replacement with superior storage efficiency, developed by VictoriaMetrics Ltd (Cyprus/EU)
• Grafana Loki — log aggregation, horizontally scalable, S3-compatible object storage backends including Hetzner Object Storage
• Grafana Tempo — distributed tracing backend, OpenTelemetry-native

GDPR status: You control all data. No third-country transfers. Your processing activities are limited to your own EU infrastructure.

Deployment: Deployable via Docker Compose on a single Hetzner VPS for smaller teams, or via Kubernetes with Helm charts for production-grade setups.

Migration from Datadog: Replace the Datadog Agent with the OpenTelemetry Collector using the OTLP exporter to send traces and metrics to your Tempo/Victoria Metrics endpoints. Replace Datadog log forwarding with Grafana Alloy (formerly Grafana Agent) or Promtail for log shipping to Loki.

# OpenTelemetry Collector config (excerpt)
exporters:
  otlp/tempo:
    endpoint: "http://tempo:4317"
    tls:
      insecure: true
  prometheusremotewrite:
    endpoint: "http://victoriametrics:8428/api/v1/write"
  loki:
    endpoint: "http://loki:3100/loki/api/v1/push"

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp, prometheus]
      exporters: [prometheusremotewrite]
    logs:
      receivers: [otlp, filelog]
      exporters: [loki]

2. SigNoz — Open-Source APM

SigNoz is an open-source observability platform built natively on OpenTelemetry. It provides a Datadog-like unified interface for logs, traces, and metrics without vendor lock-in.

GDPR status: Self-hosted on your own EU infrastructure. SigNoz Cloud is available with EU region option, but self-hosted provides maximum sovereignty.

Key advantage: Datadog APM migration is straightforward — SigNoz's trace query language and correlation features are designed as a drop-in replacement.

GitHub: github.com/SigNoz/signoz (17k+ stars, Apache 2.0)

3. Uptrace — OpenTelemetry-Native APM

Uptrace is an OpenTelemetry-based APM solution that supports traces, metrics, and logs from a single deployment. It uses ClickHouse for storage, which provides excellent query performance for log and trace data.

GDPR status: Self-hosted option available. EU deployment on Hetzner or other EU providers.

Key advantage: Native ClickHouse storage means you can run complex SQL queries over your trace and log data — useful for custom compliance reporting.

4. Elastic Stack (Elasticsearch + Kibana + APM)

The Elastic Stack (self-hosted) provides enterprise-grade log analysis, APM tracing, and infrastructure metrics comparable to Datadog's feature set.

GDPR status: Self-hosted on EU infrastructure under your control. Elasticsearch requires more infrastructure resources than alternatives like Loki, but delivers powerful full-text search over logs.

Caveat: Elasticsearch requires a valid Elastic license for production features. The basic tier is free but limits some security and monitoring features. Consider OpenSearch (Amazon's Apache-licensed fork) as an alternative.

5. Netdata — Real-Time Monitoring

Netdata provides real-time, per-second infrastructure metrics with 1-second resolution and built-in anomaly detection. Simpler scope than full APM, but excellent for infrastructure-layer observability.

GDPR status: Netdata Community (self-hosted) is 100% EU-sovereign. Netdata Cloud adds a managed layer but can be configured to not send any metric data to Netdata's servers — only connectivity metadata.

EU Alternative Comparison

Migration Checklist: Datadog to EU-Sovereign Observability

Assessment (Week 1)

• Audit which Datadog features your team actively uses: APM, logs, metrics, dashboards, monitors/alerts, synthetics
• Identify which log pipelines contain personal data (user IDs, emails, IPs in log fields)
• Export existing Datadog dashboards as JSON for import into Grafana
• Document current Datadog monitors and alert configurations
• Check your Datadog DPA status — is one in place? Is Datadog in your sub-processor list?

Infrastructure Setup (Week 2)

• Provision EU VPS or Kubernetes cluster (Hetzner, Scaleway, OVHcloud, Exoscale)
• Deploy chosen stack (Docker Compose for simplicity, Helm for Kubernetes)
• Configure object storage backend for Loki and Tempo (Hetzner Object Storage compatible with S3 API)
• Set up Grafana with existing dashboard imports
• Configure alerting channels (PagerDuty replacement: OpsGenie EU / Grafana OnCall self-hosted)

Instrumentation Migration (Week 3)

• Replace Datadog Agent with OpenTelemetry Collector on all hosts/containers
• Update application SDKs: replace dd-trace libraries with OpenTelemetry SDK
• Configure OTLP exporters pointing to your EU endpoints
• Validate trace correlation between services (trace IDs flowing through distributed systems)
• Verify log-trace correlation (structured logs with trace_id field linking to Tempo)

Cutover (Week 4)

• Run both Datadog and EU stack in parallel for one week to validate parity
• Recreate all critical monitors/alerts in Grafana
• Update runbooks referencing Datadog URLs to new Grafana URLs
• Remove Datadog Agent from all hosts
• Terminate Datadog subscription
• Delete Datadog account and confirm data deletion under GDPR Article 17

GDPR Documentation Update

• Remove Datadog from sub-processor list
• Update RoPA (Records of Processing Activities) entries for observability processing
• Update privacy policy sub-processor section
• Document new internal processing activities (self-hosted observability stack)

What About Datadog's EU Data Residency Option?

Datadog offers EU data residency as a paid add-on that stores ingested data in AWS eu-west-1 (Ireland) or eu-central-1 (Frankfurt).

As explained in the CLOUD Act section above: EU data residency does not eliminate CLOUD Act exposure. Datadog, as a US entity, is subject to US legal process regardless of where its data resides.

EU data residency does reduce latency for EU teams and ensures data does not cross the Atlantic for performance reasons. It does not address the fundamental jurisdictional issue.

The sota.io Path: EU-Sovereign Observability in Minutes

Deploying a full Grafana observability stack (Grafana + VictoriaMetrics + Loki + Tempo) requires EU-based infrastructure and Docker/Kubernetes deployment capability.

sota.io is a European PaaS that lets you deploy containerized applications to EU infrastructure without managing servers. You can deploy the complete Grafana observability stack via Docker Compose directly from your sota.yaml configuration — no Kubernetes expertise required.

Your application metrics, logs, and traces stay in the EU. Your Datadog subscription becomes a line item you can cut. And your GDPR Article 44 transfer risk for observability data is eliminated.

Summary

European SaaS teams using Datadog are running an ongoing Article 44 transfer of personal data (logs, traces, APM metrics) to a US-controlled processor without always having completed the required compliance documentation — and with CLOUD Act exposure that no DPA or data residency option can eliminate.

The 2026 NIS2 and DORA enforcement landscape means this is no longer a theoretical compliance discussion. Regulators are actively auditing ICT third-party risk. Datadog is a material supply chain risk that needs to be on your risk register.

The migration path to EU-sovereign observability is well-documented, OpenTelemetry-standardized, and achievable in four weeks. The tools (Grafana, VictoriaMetrics, Loki, Tempo, SigNoz) are mature, production-ready, and cost less than a Datadog subscription at scale.