Elastic Cloud EU Alternative: GDPR, CLOUD Act, and the Elasticsearch Compliance Gap

Post #891 in the sota.io EU Cyber Compliance Series

Elastic is one of the most widely deployed search and observability stacks in enterprise software. EU organisations use Elasticsearch for full-text search, Kibana for dashboards, Logstash and Beats for log aggregation, and Elastic APM for application performance monitoring. Elastic Cloud is the managed version of this stack — and it is also where the jurisdictional problem begins.

Elastic NV, the corporate parent, is incorporated in the Netherlands and listed on NYSE (ESTC). Many EU legal and compliance teams assume this makes Elastic a European company for GDPR purposes. It does not. Elastic Cloud is operated by Elasticsearch Inc., a wholly-owned US subsidiary incorporated in Delaware. The operating entity for Elastic Cloud is US-incorporated. The CLOUD Act — the US statute that compels US companies to disclose data stored anywhere in the world on valid law enforcement demand — applies to Elasticsearch Inc., not to Elastic NV.

For EU organisations processing personal data through Elastic Cloud, this creates a structural compliance problem that EU data centre selection and standard contractual clauses cannot resolve.

Elastic's Corporate Structure and Why CLOUD Act Applies

Understanding the jurisdictional exposure requires understanding how Elastic is structured.

Elastic NV is the publicly traded holding company, incorporated in Amsterdam under Dutch law. It was incorporated in the Netherlands as a matter of corporate preference, not because Elastic's operations are primarily Dutch. Elastic NV's principal executive offices are in San Francisco, California. Its engineering leadership, commercial operations, and go-to-market functions are predominantly US-based.

Elasticsearch Inc. is a wholly-owned subsidiary of Elastic NV, incorporated in Delaware. Elasticsearch Inc. is the entity that employs the majority of Elastic's US workforce, holds key operating licences, and — critically — operates Elastic Cloud. When you sign up for Elastic Cloud, your data processing agreement is with Elasticsearch Inc. or one of its designees. The operating entity is US-incorporated.

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713) requires that US-incorporated companies produce data stored anywhere in the world when presented with a qualifying US law enforcement order. The statute does not care where the data physically sits. It does not care that the holding company is Dutch. It applies to the operating entity — Elasticsearch Inc. — because that entity is incorporated in the United States.

The contrast with a genuinely EU-incorporated operator is significant. When Elasticsearch Inc. receives a valid CLOUD Act demand, it must produce data from its Elastic Cloud infrastructure — including data stored in EU-region deployments — unless it successfully challenges the demand in US court. No such challenge has the effect of making Elasticsearch Inc. exempt from US law; it merely delays or limits disclosure. The existence of an EU subsidiary or a Dutch holding company does not change this.

SCCs and DPAs address lawful transfer mechanisms under GDPR Articles 44 to 49. They do not create a shield against US law enforcement demands under the CLOUD Act. GDPR Article 48 is explicit: "Any judgment of a court or tribunal and any decision of an administrative authority of a third country requiring a controller or processor to transfer or disclose personal data may only be recognised or enforceable in any manner if based on an international agreement." No EU-US international agreement currently covers CLOUD Act demands.

The Schrems II ruling reinforced this analysis. The CJEU held in July 2020 that transfer mechanisms must account for the legal framework governing access to data by US public authorities. The CLOUD Act is exactly the kind of US public authority access framework the CJEU had in mind. EU DPAs applying Schrems II in supervisory decisions have consistently treated CLOUD Act exposure as a risk factor that transfer impact assessments must address — and that SCCs alone do not cure.

Why Elasticsearch Data Is Highly GDPR-Relevant

Some engineering teams treat Elasticsearch as an "operational" database whose contents are technical rather than personal. For most production deployments, this characterisation is wrong, and it creates GDPR compliance risk that extends to the CLOUD Act exposure above.

Search indices containing customer data. If you use Elasticsearch to power search across your application, your search index contains whatever data you have indexed. In e-commerce, this is product catalogues plus customer purchase histories and wishlists. In SaaS applications, this is document content, user-generated data, and metadata associated with identified accounts. In HR tools, this is employee records. Any Elasticsearch index that includes names, email addresses, user identifiers, or account-linked content is a personal data store under GDPR Article 4(1).

Logging pipelines. Elastic Stack is widely used as a logging backend via Logstash, Filebeat, and the Elastic Common Schema. Logs ingested into Elasticsearch routinely include IP addresses (personal data under GDPR Recital 30), authenticated session identifiers, user IDs embedded in request paths, email addresses appearing in error messages, and geographic location data derived from IP resolution. Authentication logs, access logs, and application error logs are among the most personal-data-dense artefacts in any software system.

APM and distributed tracing. Elastic APM captures transaction traces, spans, and error events. Traces include request headers (which can contain session tokens and authentication credentials), URL paths (which often include user IDs or resource identifiers), database query strings (which can include parameterised personal data that appears in slow query logs), and user context fields explicitly attached by your application. APM data is personal data in any deployment where traces are associated with authenticated users.

Kibana dashboards and Kibana Lens. Kibana is the visualisation and exploration layer for Elastic data. When Kibana dashboards display user behaviour data, support ticket metrics, or customer engagement analytics, the underlying Elasticsearch queries and the result sets transmitted to Kibana sessions may contain personal data. Kibana's per-user saved objects can also associate dashboard configurations with user identities.

Fleet and endpoint agents. Elastic Agent, the unified data collection agent, can collect endpoint telemetry including process execution logs, file system events, and network connection metadata. When deployed on employee workstations or servers, Fleet-managed agents generate highly personal data — what processes each user ran, which files they accessed, and when. This data flows into Elasticsearch and is subject to GDPR's employee data provisions as well as the general personal data framework.

EDPB guidance on data minimisation and Article 25 (data protection by design) is directly relevant to Elastic deployments. The EDPB has emphasised that logging and monitoring must be proportionate and that data subjects retain rights over personal data in operational systems, including right of access and right of erasure. These rights do not disappear because data lives in an Elasticsearch index rather than a relational database.

NIS2 and DORA: The Logging Obligation Tension

Elastic's GDPR exposure matters especially for organisations subject to NIS2 and DORA, because both frameworks impose mandatory logging and monitoring obligations — which means more personal data in Elastic, not less.

NIS2 Article 21(2)(b) requires essential and important entities to implement incident handling measures including logging sufficient to detect, analyse, and report incidents within the mandatory notification windows. NIS2 Article 23 requires notification to CSIRTs within 24 hours of a significant incident, with a comprehensive report within 72 hours. Meeting these timelines requires robust log retention and searchability — exactly what Elastic Stack provides.

The regulatory tension is direct: NIS2 requires you to log extensively to meet incident response obligations. The same logs contain personal data. That personal data sits in Elastic Cloud, operated by a US-incorporated entity subject to CLOUD Act. GDPR Article 5(1)(e) (storage limitation) requires that personal data not be retained longer than necessary. NIS2 incident response obligations require retention long enough to support post-incident analysis and regulatory reporting.

DORA Articles 9 and 10 impose specific ICT risk management and logging requirements on financial entities. DORA Annex I (referenced in the implementing technical standards under Articles 15 and 16) specifies that ICT logging must cover access events, privileged user actions, and security-relevant configuration changes. For banks, investment firms, and insurance undertakings using Elastic Stack as their logging infrastructure, the CLOUD Act exposure of Elasticsearch Inc. becomes a direct ICT third-party risk under DORA Article 28.

DORA Article 28(4) requires financial entities to assess whether ICT third-party service providers are subject to laws of third countries that could conflict with EU law. A CLOUD Act demand against Elasticsearch Inc. is precisely the kind of third-country law conflict DORA Article 28(4) anticipates. Regulators under DORA (the ESAs and national competent authorities) will expect financial entities to have documented this risk in their ICT third-party risk registers and to have a mitigation strategy.

The NIS2 competent authority perspective. EU member state cybersecurity authorities implementing NIS2 have begun requesting documentation of the security measures and third-party risk assessments behind logging infrastructure. An organisation that can demonstrate its logging infrastructure is operated by an EU-incorporated entity, subject only to EU law enforcement procedures, is in a substantially stronger position than one that relies on SCCs with a US-operated cloud provider.

Self-Hosted Elasticsearch: A Partial Solution

Elasticsearch is open source under the SSPL licence (with some features under the Elastic licence). EU organisations can deploy Elasticsearch on their own infrastructure — on-premises, in EU-region cloud VMs, or on an EU-sovereign PaaS — without using Elastic Cloud. Self-hosted Elasticsearch eliminates the direct exposure to Elasticsearch Inc. as a data processor.

Self-hosted Elasticsearch addresses the CLOUD Act problem in its strongest form: Elasticsearch Inc. is not a processor of your data, does not hold data you process, and therefore cannot be subject to a CLOUD Act demand for your data. Your data sits in infrastructure you control, operated by EU-incorporated entities (your cloud provider, your own legal entity).

Self-hosted Elasticsearch has operational costs. Managing cluster upgrades, index lifecycle management, snapshot policies, security configuration, and scalability planning requires Elasticsearch operational expertise. For organisations that have this expertise, self-hosting is a straightforward path. For those that do not, it creates a resource and risk burden that managed services are designed to avoid.

The middle path is deploying Elasticsearch on an EU-native PaaS that abstracts the operational complexity while keeping the data under EU-controlled infrastructure. Platforms incorporated and operated entirely within the EU — without US parent company relationships — can offer managed Elasticsearch deployment without CLOUD Act exposure. The SLA, monitoring, and upgrade responsibilities remain with the PaaS operator; the data and infrastructure control remain within EU jurisdiction.

There is also a licence question. Elasticsearch was relicensed from Apache 2.0 to SSPL in 2021. SSPL is not considered open source by the OSI. For organisations with open source licence policies or for those using Elasticsearch in software they distribute, SSPL may create licence obligations. This is one of the reasons OpenSearch was forked from Elasticsearch — to maintain an Apache 2.0 licensed alternative.

EU-Native Alternatives to Elastic Cloud

Several alternatives to Elastic Cloud are available that either eliminate the CLOUD Act exposure through EU incorporation or are open source and self-hostable without Elasticsearch Inc. involvement.

OpenSearch. OpenSearch is a community-driven, Apache 2.0 licensed fork of Elasticsearch and Kibana, maintained by the OpenSearch project (originally initiated by Amazon Web Services after the Elastic relicensing). OpenSearch is functionally equivalent to Elasticsearch for most enterprise use cases — full-text search, log aggregation, dashboards (OpenSearch Dashboards, equivalent to Kibana), and anomaly detection. Because OpenSearch is Apache 2.0 licensed, it can be deployed and used without licence obligations to Elasticsearch Inc. Self-hosted OpenSearch on EU infrastructure eliminates the CLOUD Act exposure entirely.

Managed OpenSearch offerings exist from EU-incorporated cloud providers. These providers operate OpenSearch clusters on EU infrastructure under EU law. For organisations that need a managed experience without the operational burden of self-hosting, managed OpenSearch from an EU-sovereign PaaS is the closest functional substitute for Elastic Cloud.

Quickwit. Quickwit is a cloud-native search engine built on Apache Parquet and object storage, designed for log analytics and distributed search at scale. Quickwit is open source (Apache 2.0) and was developed by a French company (Quickwit SAS, founded in Paris). Quickwit is designed to be significantly more cost-efficient than Elasticsearch for log retention use cases, as it stores index data in object storage (S3-compatible) rather than block storage. For NIS2 and DORA log retention requirements, Quickwit deployed on EU object storage infrastructure is a strong candidate.

Meilisearch. Meilisearch is an open source search engine (MIT licence) founded in France. It is optimised for relevance-tuned, developer-friendly search — the kind of search you implement in a SaaS product for in-app content search, document retrieval, or product catalogues. Meilisearch is not a log aggregation platform; it is a replacement for Elasticsearch in search-specific use cases. For EU SaaS products that use Elastic Stack primarily for user-facing search rather than logging, Meilisearch hosted on EU infrastructure is a clean, licence-free, EU-incorporated-vendor option.

Typesense. Typesense is an open source, typo-tolerant search engine (GPL-3.0 and commercial licence). It is self-hostable and optimised for low-latency search on structured data. Typesense Inc. is a US company, but self-hosted Typesense eliminates the data processor relationship with Typesense Inc. entirely. For EU developers deploying Typesense on their own EU infrastructure, the CLOUD Act exposure does not arise.

Grafana Loki for log aggregation. For organisations that use Elastic primarily for log aggregation and dashboarding rather than full-text search, Grafana Loki is a compelling alternative. Loki is open source (Apache 2.0), horizontally scalable, and designed to work with Grafana dashboards (a near-exact Kibana substitute for log query and visualisation). Grafana Labs is a US company, so managed Grafana Cloud has similar CLOUD Act considerations to Elastic Cloud. Self-hosted Loki on EU infrastructure, or managed Loki from an EU-incorporated PaaS, avoids this. For NIS2 logging, the Loki-Promtail-Grafana stack running on EU-sovereign infrastructure is increasingly common in EU security-conscious deployments.

ZincObserve (OpenObserve). ZincObserve (rebranded OpenObserve) is an open source observability platform (Apache 2.0) that offers log aggregation, metrics, and tracing in a single platform with a Kibana-compatible query interface. It is designed to be substantially cheaper than Elastic Stack for high-volume log retention by using object storage. For DORA Article 9 logging requirements in financial entities, ZincObserve self-hosted on EU infrastructure covers the technical obligations without Elasticsearch Inc. involvement.

The Migration Checklist: 15 Steps from Elastic Cloud to EU-Sovereign Infrastructure

Moving from Elastic Cloud to an EU-native alternative requires planning across three dimensions: data, applications, and operations.

Data assessment.

1. Audit your Elastic indices for personal data. Use Kibana Dev Tools or the Elasticsearch Index APIs to review your current indices. Identify which contain personal data under GDPR Article 4(1). This drives your DPIA update requirements.

2. Classify indices by use case. Separate search indices from log indices from APM indices. Different use cases map to different EU-native alternatives. Log indices may suit Quickwit or Loki; search indices may suit OpenSearch or Meilisearch; APM may suit self-hosted Elastic Stack or Grafana Tempo.

3. Document retention periods. Each index type has a different legal retention requirement: NIS2 incident logs (typically 3–7 years depending on member state), DORA ICT event logs (5 years minimum for financial entities), application logs (90–365 days in most GDPR-compliant policies), APM traces (7–30 days in typical configurations). Map these before migrating.

4. Export Kibana dashboards and saved objects. Kibana's saved objects can be exported via the Kibana Saved Objects API. If your migration target is OpenSearch, most Kibana dashboards translate directly to OpenSearch Dashboards with minimal adjustment.

Migration execution.

1. Deploy your EU-native alternative in parallel. Do not migrate by shutting down Elastic Cloud. Run your EU infrastructure in parallel and route traffic incrementally. For OpenSearch, deploy on EU infrastructure or an EU-sovereign PaaS. Verify connectivity, authentication, and index mapping compatibility before routing production workloads.

2. Reindex historical data selectively. For most organisations, migrating all historical Elastic data is neither necessary nor efficient. Freeze historical Elastic indices, set ILM policies to transition cold data to lower-cost storage, and start your EU-native deployment with current data. Historical data in Elastic Cloud can be exported in Elasticsearch Snapshot format and archived in EU object storage if needed for compliance holds.

3. Test your ingestion pipelines. Logstash pipelines, Filebeat configurations, and custom Elasticsearch ingest nodes must be reconfigured to point to your new cluster. Audit all data sources — application servers, Kubernetes clusters, firewalls, network devices — before cutover.

4. Migrate Kibana dashboards. Export all Kibana saved objects (dashboards, visualisations, index patterns, alerts) via the Kibana Saved Objects API. Import to OpenSearch Dashboards using the OpenSearch Dashboards Saved Objects API. Most objects are compatible; visualisation types added in recent Kibana versions may require recreation.

5. Reconfigure APM agents. Elastic APM agents send traces to the Elastic APM Server. In your EU deployment, run a self-hosted APM Server (or equivalent — Jaeger, Grafana Tempo, OpenTelemetry Collector) and reconfigure your APM agents to the new endpoint. APM agent reconfiguration is application-level — it typically requires updating a configuration variable, not code changes.

Legal and compliance steps.

1. Update your ROPA. Your Record of Processing Activities under GDPR Article 30 currently lists Elasticsearch Inc. as a processor for search, log, and APM workloads. After migration, update the ROPA to reflect the EU-sovereign operator. This is a legal obligation, not optional cleanup.

2. Terminate the Elastic DPA. Your DPA with Elasticsearch Inc. is a GDPR processing agreement that creates legal obligations. After migrating and deleting your data from Elastic Cloud, formally terminate the DPA per its termination provisions. Retain a copy of the terminated DPA for your compliance records.

3. Conduct a DPIA delta review. If you conducted a DPIA for your Elastic deployment (required under GDPR Article 35 if the processing was high-risk), update it to reflect the EU-sovereign deployment. The DPIA update should document the elimination of the CLOUD Act transfer risk.

4. Update your ICT third-party risk register. For financial entities under DORA, remove Elasticsearch Inc. from the critical ICT third-party register once migration is complete. Add your EU-sovereign PaaS or self-hosted operator as the replacement.

Operations.

1. Configure EU-sovereign snapshot policies. Elasticsearch and OpenSearch snapshots are your backup and disaster recovery mechanism. Ensure snapshot repositories point to EU-region object storage operated by EU-incorporated providers. This preserves the sovereignty of your backup chain.

2. Verify your deployment with a transfer impact assessment. After cutover, document the TIA for the EU-sovereign deployment. The TIA should confirm: the operator is incorporated in the EU, no US parent company relationship exists, the applicable law is EU member state law, and no international data transfer mechanism is required because data does not leave the EEA.

What EU Developers Need From a Search and Observability Platform

EU developers building SaaS products face a specific set of constraints that Elastic Cloud does not fully resolve:

• GDPR compliance across the data lifecycle, including personal data in search indices and logs
• NIS2 logging obligations that require long-term retention of security-relevant events
• DORA ICT third-party risk management that requires assessment of third-country law exposure
• The ability to demonstrate to enterprise customers that your observability infrastructure does not route their data through US-incorporated entities

An EU-native PaaS that hosts OpenSearch, Loki, or Quickwit on EU infrastructure — and is itself incorporated in the EU without US parent company relationships — satisfies all four constraints. The PaaS operator is subject to EU law enforcement procedures only. CLOUD Act demands directed at a US-incorporated entity do not reach an EU-incorporated operator.

sota.io is a European PaaS for developers. You can deploy OpenSearch, Grafana Loki, Quickwit, Meilisearch, or any other containerised search and observability workload on EU infrastructure under EU jurisdiction. sota.io is incorporated and operated within the EU — there is no US parent company and no CLOUD Act exposure. GDPR, NIS2, and DORA compliance starts with infrastructure that is governed by EU law.

Summary

Elastic NV's Netherlands incorporation does not make Elastic Cloud an EU-sovereign service. Elastic Cloud is operated by Elasticsearch Inc., a US-incorporated Delaware company that is subject to the CLOUD Act. For EU organisations processing personal data in Elastic Cloud — which includes virtually all production deployments using Elasticsearch for search, logging, or APM — the structural CLOUD Act exposure cannot be resolved through SCCs, EU region selection, or DPA commitments.

The practical paths are self-hosted Elasticsearch on EU infrastructure, migration to OpenSearch on EU-sovereign infrastructure, or use case-specific alternatives (Quickwit for logs, Meilisearch for search, Grafana Loki for log aggregation). Each path eliminates the Elasticsearch Inc. data processor relationship and the associated CLOUD Act exposure.

NIS2 and DORA compliance timelines make this migration more urgent, not less: both frameworks impose logging and monitoring obligations that increase the personal data density in your observability infrastructure. The more log data you retain for NIS2 incident response, the more personal data sits in Elasticsearch — and the more consequential the CLOUD Act exposure becomes.

EU-sovereign infrastructure for search and observability is available today. The compliance argument for migration is straightforward, and the technical path is well-documented.

This article is part of the sota.io EU Cyber Compliance Series. Related posts: Splunk EU Alternative: GDPR and CLOUD Act Exposure After the Cisco Acquisition, Datadog EU Alternative for GDPR, CLOUD Act, NIS2, New Relic EU Alternative: GDPR, CLOUD Act, and Observability Data.