Elastic Observability EU Alternative 2026: Elasticsearch Inc. Delaware C-Corp, NYSE:ESTC, CLOUD Act Risk for Logs, Metrics and Traces

Post #997 in the sota.io EU Compliance Series — Post 3/6 in the EU Monitoring Tools Series

Elastic NV sounds European. The name includes a Dutch corporate suffix — NV stands for Naamloze vennootschap, the Netherlands equivalent of a public limited company. Elastic's registered office is in Amsterdam. For a European developer evaluating observability platforms under GDPR and NIS2, this sounds like good news.

It is not the whole story.

Elasticsearch Inc., the US subsidiary of Elastic NV, is a Delaware C-Corp headquartered in San Francisco, California. Elasticsearch Inc. employs most of the product engineering and cloud operations team. Elastic Cloud, the managed SaaS product that most organisations use for observability, is operated by Elasticsearch Inc. under US jurisdiction. That means 18 U.S.C. § 2713 — the CLOUD Act — applies directly to the logs, metrics, and traces you send to Elastic Cloud.

This is the third post in our EU Monitoring Tools series. Post 1 covered Datadog (NYSE:DDOG, Delaware C-Corp). Post 2 covered Grafana Cloud (Grafana Labs Inc., Delaware C-Corp). The pattern is consistent: the observability market is dominated by US-incorporated entities, and the EU alternatives require deliberate architecture choices.

Elastic NV vs. Elasticsearch Inc.: Two Different Legal Entities

Understanding the corporate structure is the foundation of the GDPR and CLOUD Act analysis.

Elastic NV (The Holding Company)

• Incorporated: Amsterdam, Netherlands, 2012
• Legal form: Naamloze vennootschap (NV) — Dutch public company
• Stock exchange: NYSE (ticker: ESTC) — listed in New York, not Amsterdam
• Registered address: Fred. Roeskestraat 115, Amsterdam, Netherlands
• Regulatory regime: Dutch Authority for the Financial Markets (AFM), but primarily regulated as a US foreign private issuer by the SEC

Critical point: Despite Dutch incorporation, Elastic NV is regulated primarily by the US Securities and Exchange Commission (SEC) because it is NYSE-listed. Its annual reports are filed as 20-F (foreign private issuer form) with the SEC. This creates a hybrid entity: Dutch corporate law, but US capital markets regulation.

Elasticsearch Inc. (The US Operating Entity)

• Incorporated: Delaware, USA
• Headquarters: San Francisco, California
• Role: US operating subsidiary — employs engineering, cloud operations, and support
• CLOUD Act status: Directly covered under 18 U.S.C. § 2713
• Products operated: Elastic Cloud (the managed SaaS), Elastic Cloud Enterprise (on-prem management)

The CLOUD Act Applies to Elasticsearch Inc., Not Elastic NV

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) requires US-based providers to comply with US government demands for data stored anywhere in the world, including servers in the EU. The key language: a provider must comply with "all preservation, backup, or disclosure orders" regardless of where data is stored.

Elasticsearch Inc. qualifies as a "provider of electronic communication service or remote computing service" under 18 U.S.C. § 2703. When you store your application logs, APM traces, or infrastructure metrics in Elastic Cloud — even in the EU region — Elasticsearch Inc. can be compelled to produce that data in response to a US court order.

Elastic NV's Dutch incorporation does not shield data stored in or managed by Elasticsearch Inc. The CLOUD Act reaches the data through the US subsidiary, not the Dutch holding company.

What Elastic Observability Contains

Before analysing the GDPR risk, it helps to understand exactly what data Elastic Observability collects and stores.

APM (Application Performance Monitoring)

Elastic APM instruments your application code to capture:

• Transaction traces: HTTP requests, database queries, external calls — with timing, status codes, and error messages
• Span data: Individual operations within a transaction (SQL queries with parameters, Redis commands, gRPC calls)
• Error events: Stack traces including file names, line numbers, function names, and local variable values
• User context: If configured, captures user IDs, usernames, IP addresses from request headers
• Session/correlation IDs: Values used to link traces to users or sessions

Under GDPR Art. 4(1), user IDs, IP addresses, session tokens, and usernames are personal data. Stack traces may contain personal data if variable values include user-provided input. Error messages often contain PII that developers did not intend to persist.

Log Management

Elastic Agent and Filebeat ship application and infrastructure logs to Elasticsearch indices. Log data commonly contains:

• IP addresses from HTTP access logs
• Usernames and session identifiers from application logs
• Email addresses from authentication error logs
• Database query fragments that may include user-provided search terms
• EU-regulated financial data if logs include payment amounts or account references

Elasticsearch stores this data with full-text searchability, which means every piece of PII in every log line is indexed and queryable.

Infrastructure Metrics

Metricbeat and Elastic Agent collect:

• Host metrics (CPU, memory, network I/O by process)
• Kubernetes pod metrics (including container names, namespaces, labels)
• Database performance metrics (query counts, slow query logs)

Metrics are generally lower GDPR risk, but Kubernetes labels frequently contain user-identifying information (e.g., user-id: 12345 as a pod label), and slow query logs may contain SQL with PII.

Synthetics and Uptime Monitoring

Elastic Synthetics runs synthetic browser sessions against your endpoints. These sessions may:

• Execute login flows (capturing credentials in transit monitoring)
• Navigate authenticated pages (session data visible to monitoring infrastructure)
• Generate HAR files with full request/response headers including Cookie: and Authorization: headers

Synthetic monitoring of authenticated endpoints is a significant GDPR risk point that is often overlooked in observability DPAs.

The GDPR Exposure Analysis

Art. 28 — Data Processor Requirements

When you send data to Elastic Cloud, Elasticsearch Inc. acts as a data processor under Art. 28 GDPR. Elastic provides a Data Processing Addendum (DPA) that includes Standard Contractual Clauses (SCCs) for transfers to the US.

The SCCs problem: The European Data Protection Board has consistently held that SCCs do not automatically legitimise transfers where the receiving entity is subject to surveillance laws that conflict with EU fundamental rights. The Schrems II judgment (Case C-311/18) established that the exporter must conduct a Transfer Impact Assessment (TIA) for every transfer protected only by SCCs.

For a US entity subject to CLOUD Act + FISA § 702, the TIA typically cannot reach "essentially equivalent" protection. Your legal team will need to either accept the residual risk or find an alternative.

Art. 5(1)(f) — Integrity and Confidentiality

GDPR Art. 5(1)(f) requires that personal data be processed in a manner that ensures appropriate security, including protection against unauthorised access. Elasticsearch Inc. employees with administrative access to Elastic Cloud — for support, debugging, and operations — can technically access customer data. This access is necessary for the service to function, but it means your data is not encrypted at rest in a way that prevents access by the processor.

Art. 32 — Security of Processing

Elastic Cloud encrypts data at rest using AWS or GCP KMS keys. The keys are managed by Elasticsearch Inc., not by the customer. This is the standard SaaS model, but it means:

1. Elasticsearch Inc. can access plaintext data
2. A CLOUD Act warrant served on Elasticsearch Inc. would yield plaintext data
3. AWS or GCP could be separately compelled to produce the same data under their own CLOUD Act obligations

Elastic does offer Bring Your Own Key (BYOK) encryption for Elastic Cloud Enterprise, the self-managed deployment option. BYOK would mean Elasticsearch Inc. cannot access the data without the customer's key, which provides some CLOUD Act mitigation. However, BYOK requires running your own Elastic Cloud Enterprise deployment — it is not available for the standard Elastic Cloud managed service.

DORA (Digital Operational Resilience Act) for Financial Services

If you are in financial services subject to DORA, Elastic Cloud is a critical ICT third-party service provider. DORA Art. 30 requires:

• Exit strategy: Documented plan to migrate away from Elastic Cloud without business disruption
• Audit rights: Right to inspect Elastic's security practices, including data access controls
• Sub-processor transparency: Full chain of cloud infrastructure providers (Elastic uses AWS and GCP)
• Concentration risk: If multiple firms in your sector use Elastic, the ECB may classify this as systemic ICT concentration risk

NIS2 for Critical Infrastructure

NIS2 Art. 21 requires essential and important entities to implement "state of the art" security measures. For observability infrastructure:

• APM traces and logs may include data about security controls (WAF rules, rate limits, authentication systems)
• A compromise of your observability platform is equivalent to a compromise of your monitoring infrastructure
• US-jurisdiction data access extends to security-sensitive operational data

EU Alternatives to Elastic Observability

The EU observability landscape divides into three categories: OSS self-hosted, managed services from EU-incorporated providers, and hybrid approaches.

Option 1: OpenSearch + Self-Hosted (Recommended for Data Sovereignty)

OpenSearch is the community fork of Elasticsearch and Kibana, created by Amazon after Elastic changed its licence in 2021. It remains Apache 2.0 licensed.

Corporate structure:

• Maintained by AWS (Amazon Web Services) under the OpenSearch Software Foundation (Linux Foundation)
• Apache 2.0 licence: you own the binary, there is no vendor relationship
• Self-hosted on EU infrastructure eliminates all CLOUD Act exposure

What it includes:

• OpenSearch (Elasticsearch-compatible search and analytics engine)
• OpenSearch Dashboards (Kibana-compatible)
• OpenSearch Observability plugin (APM and trace analytics)
• Data Prepper (log and trace ingestion pipeline)
• Integration with OpenTelemetry for distributed tracing

EU-native deployment:

• Self-host on Hetzner, OVHcloud, Scaleway, Ionos — any EU cloud
• No US vendor relationship, no SaaS agreement with US entity
• Full control over encryption keys (your KMS)

Limitations:

• APM agent library (Elastic APM agent) uses Elastic's format natively; OpenSearch APM requires OpenTelemetry agents
• Kibana-to-OpenSearch Dashboards migration requires some UI adaptation
• AWS OpenSearch Service (managed) would reintroduce CLOUD Act via AWS — use only the OSS version self-hosted

Option 2: VictoriaMetrics (Bulgarian, EU-Native)

VictoriaMetrics LLC is incorporated in Bulgaria (EU member state). VictoriaMetrics is a high-performance time-series database with full Prometheus compatibility.

Corporate structure:

• Registered in Sofia, Bulgaria (EU member state)
• No US parent, no CLOUD Act exposure
• Available as OSS (Apache 2.0) and Enterprise

What it includes:

• VictoriaMetrics (time-series DB, Prometheus-compatible)
• VMAgent (metrics collection, Prometheus drop-in)
• VMAlert (alerting)
• VictoriaLogs (log storage, experimental but production-ready)
• Grafana datasource plugin

GDPR position:

• Bulgarian CPDP (Commission for Personal Data Protection) as supervising authority
• No cross-Atlantic data transfer when self-hosted or using VictoriaMetrics Cloud EU

Limitation: VictoriaMetrics focuses on metrics, not full APM tracing. For distributed traces, combine with Jaeger (CNCF OSS) or Tempo (Grafana Labs, but self-hosted OSS is CLOUD Act-free).

Option 3: OpenTelemetry + Jaeger + Loki + Prometheus (Full CNCF Stack)

The Cloud Native Computing Foundation (CNCF) hosts a complete observability stack that is vendor-neutral and fully open-source:

GDPR position: The CNCF is a Linux Foundation project based in San Francisco, but the software itself is open-source. Self-hosted deployments have no vendor relationship — there is no data processor, no DPA, no CLOUD Act exposure. You are both data controller and operator.

Architecture note: This stack requires more operational expertise than Elastic Cloud. You need to manage:

• Separate storage backends (object storage for traces, time-series DB for metrics, log storage)
• Retention policies for each component
• Cross-component correlation (trace IDs in logs, exemplars in metrics)

Helm charts and Kubernetes operators are available for each component, making deployment manageable.

Option 4: Signoz (Open-Source, OpenTelemetry-Native)

SigNoz Inc. is a US-incorporated startup (Y Combinator 2021), but SigNoz is Apache 2.0 licensed and self-hosted. Like OpenSearch, the key is deployment model: self-hosted on EU infrastructure eliminates the CLOUD Act risk.

What it includes:

• OpenTelemetry-native instrumentation
• Unified logs, metrics, and traces in a single UI
• ClickHouse as storage backend (efficient columnar storage for high-cardinality trace data)
• Alerting and dashboard builder

GDPR position when self-hosted:

• No vendor relationship, no US data processor
• You control ClickHouse storage on your EU infrastructure

Limitation: SigNoz Inc. offers a managed cloud service (SigNoz Cloud). Using the managed service would reintroduce SigNoz Inc. as a US data processor. Only the self-hosted option is CLOUD Act-free.

Option 5: Wazuh + OpenSearch (SIEM/XDR Focus)

For organisations where observability overlaps with security monitoring, Wazuh is a Madrid-based open-source SIEM/XDR platform built on top of OpenSearch.

Corporate structure:

• Wazuh Inc. registered in the United States (Nevada), but Wazuh S.L. (the original entity) is Spanish
• Apache 2.0 licensed — self-hosted eliminates vendor relationship
• Active CNCF integration

Note on Wazuh Inc.: Wazuh has a US entity, similar to the Elastic NV/Elasticsearch Inc. structure. For maximum GDPR compliance, use the self-hosted OSS version without a subscription agreement with Wazuh Inc.

Managed EU Alternatives (Lower Operational Overhead)

If self-hosting is not an option, some managed services have cleaner EU corporate structures:

Better Stack (Logtail / Uptime)

Better Stack s.r.o. is incorporated in Prague, Czech Republic (EU member state). It offers:

• Log management (Logtail)
• Uptime monitoring
• Status pages

GDPR position: Czech DPA (ÚOOÚ) as supervising authority. No US parent. EU-incorporated operator.

Limitation: Better Stack does not offer APM or distributed tracing. For a full observability suite, it is log + uptime only.

Grafana Cloud EU (With Caveats)

Covered in detail in Post 2/6 of this series. Short version: Grafana Labs Inc. is a Delaware C-Corp, so the same CLOUD Act analysis applies. Self-hosted Grafana OSS is a different matter — no vendor relationship.

Migration Path from Elastic Cloud

For organisations currently using Elastic Cloud, migration involves three phases:

Phase 1: OpenTelemetry Instrumentation

Replace Elastic APM agents with OpenTelemetry SDKs. OpenTelemetry is instrumentation-vendor-neutral and supported by all target platforms:

# Remove Elastic APM agent
# pip uninstall elastic-apm

# Install OpenTelemetry
pip install opentelemetry-distro opentelemetry-exporter-otlp

# Configure OTLP exporter to your target (Jaeger, SigNoz, etc.)
export OTEL_EXPORTER_OTLP_ENDPOINT=https://your-eu-collector:4317

Phase 2: Log Pipeline Migration

Replace Filebeat/Elastic Agent with:

• Fluent Bit (CNCF, Apache 2.0) for log collection
• Grafana Loki or OpenSearch as log backend
• Fluentd for complex log transformation pipelines

Phase 3: Metrics Migration

Replace Metricbeat with Prometheus scraping + remote_write to VictoriaMetrics or your chosen TSDB. The Prometheus exposition format is the de facto standard — all Elastic Metricbeat dashboards can be reproduced in Grafana with equivalent PromQL queries.

GDPR Article 28 Checklist for Elastic Cloud

Before deciding to continue using Elastic Cloud for GDPR-covered data, verify:

• Transfer Impact Assessment (TIA) completed for Elasticsearch Inc. as US recipient
• Data Processing Addendum signed with current SCCs (2021 EU SCCs, not older versions)
• Sub-processor list obtained and assessed (AWS, GCP — both US entities)
• Data minimisation review: Are you sending personal data to Elastic that could be excluded?
• Retention periods configured in Elasticsearch ILM (Index Lifecycle Management) policies
• BYOK encryption evaluated if operating under DORA or NIS2
• Right to erasure workflow documented for Elasticsearch indices
• Incident notification SLA verified (GDPR requires 72-hour notification to DPA)

Verdict: When Elastic Cloud Is (and Is Not) Acceptable

Elastic Cloud may be acceptable if:

• Your data does not contain personal data of EU data subjects (pure infrastructure metrics with no user context)
• You have completed a TIA and your DPO accepts the residual CLOUD Act risk
• You are in a jurisdiction where US data access is an accepted risk (outside EU/EEA)
• You require Elastic's specific APM features that no EU alternative matches

Elastic Cloud is not acceptable if:

• You are subject to NIS2 Art. 21 or DORA Art. 30 with strict concentration risk requirements
• Your observability data includes GDPR-classified personal data (user IDs, IPs, session tokens) and your TIA cannot reach essential equivalence
• Your customers require contractual guarantees of EU-only data processing
• You are a public authority in an EU member state subject to national public procurement rules requiring EU-only processing

Best EU alternative for full observability: OpenSearch (self-hosted on Hetzner/OVHcloud) + OpenTelemetry Collector + Jaeger for traces + VictoriaMetrics for metrics + Loki for logs, deployed on Kubernetes with Helm. This stack delivers feature parity with Elastic Observability at zero vendor cost, with complete EU data sovereignty.

Part of the EU Monitoring Tools Series: a six-post guide to observability platform GDPR compliance. Next post: Splunk EU Alternative 2026 (Cisco acquisition, NASDAQ:CSCO, Delaware).

View all EU compliance guides on sota.io →