Splunk EU Alternative: GDPR and CLOUD Act Exposure After the Cisco Acquisition — What EU Teams Use Instead

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

Splunk is one of the most widely deployed SIEM and log management platforms in enterprise IT. EU organisations use Splunk for security operations, compliance reporting, incident detection, and operational monitoring. Splunk offers a GDPR-compliant data processing addendum, EU-region infrastructure through Splunk Cloud, and extensive certification documentation.

None of that addresses the structural problem introduced by Splunk's 2023 acquisition.

Cisco Systems acquired Splunk in September 2023 for approximately $28 billion. Cisco Systems, Inc. is a Delaware-incorporated US corporation headquartered in San Jose, California. As a Cisco business unit, Splunk is now subject to the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713), which requires US-incorporated companies to produce data stored anywhere in the world when presented with a valid US law enforcement order — regardless of whether that data sits in EU servers, is protected by EU-specific contractual commitments, or belongs to EU data subjects.

This creates a direct tension with GDPR for any EU organisation using Splunk to process personal data — which, in practice, means virtually every EU organisation that deploys Splunk.

The Cisco Acquisition and What Changed

Before the Cisco acquisition, Splunk Inc. was an independent US company (NASDAQ: SPLK) incorporated in Delaware. The CLOUD Act applied then too. But the acquisition matters for a different reason: it moved Splunk deeper into a US enterprise infrastructure stack with substantially greater CLOUD Act surface area.

Cisco itself operates large-scale network infrastructure globally. The combined Cisco-Splunk entity has broader US intelligence community relationships, deeper US federal government contracts, and more extensive interoperability with US infrastructure than Splunk had as an independent company. For EU organisations concerned about sovereign exposure, the Cisco acquisition represents an increased risk profile, not a neutral corporate event.

Splunk's EU infrastructure is operated through subsidiaries and EU-region data centres. The same analysis that applies to AWS, Microsoft Azure, and Datadog applies here: the geographic location of the data centre is not the determining factor for CLOUD Act jurisdiction. The corporate nationality of the ultimate parent — Cisco Systems, Inc. — is what matters. A valid US law enforcement order directed at Cisco-Splunk can compel production of data held anywhere in the Cisco-Splunk infrastructure, including EU servers.

SCCs and DPAs address EU-to-US data transfer compliance. They do not change what Cisco-Splunk must do when US law enforcement demands access under the CLOUD Act. GDPR Article 48 explains why EU DPAs treat this as a distinct legal problem: "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 such international agreement currently covers CLOUD Act demands to EU-based data processors.

Why SIEM Data Is Highly GDPR-Relevant

Many security teams assume that log and SIEM data is "operational" rather than personal data. This assumption is incorrect and creates specific GDPR compliance exposure for organisations using Splunk.

GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." Under consistent EU DPA guidance, security log data routinely qualifies:

Authentication and access logs. Every login event, failed authentication attempt, and session establishment captures at minimum an IP address, a user identifier, and a timestamp. IP addresses are personal data under GDPR Recital 30. User identifiers link the record to a specific individual. Authentication logs are among the highest-density personal data sources in enterprise IT.

Network traffic logs. Splunk ingests NetFlow, firewall logs, proxy logs, and DNS query logs. These capture source and destination IP addresses, user-associated connection patterns, browsing behaviour (via DNS), and communication metadata. Communication metadata under GDPR is treated as personal data — the CJEU has been consistent on this point, and the European Electronic Communications Code reinforces it.

Application security events. Splunk Enterprise Security (ES) correlates application logs that include session tokens, user IDs, request paths, and error messages. If your application logs include paths like /api/users/12345/orders or error messages containing email addresses, that data is personal data in Splunk.

Endpoint telemetry. Splunk UBA (User Behaviour Analytics) collects detailed endpoint activity including which users accessed which files at what times, application usage patterns, and anomaly scores tied to individual employees. This is personal data under Articles 4 and 9, and may qualify as sensitive data (Article 9) when the behavioural patterns reveal health conditions, religious practices, or trade union activity.

Incident response data. When Splunk ES surfaces an alert or generates an incident, the incident record captures the personal data that triggered the alert — including the implicated user accounts, IP addresses, and the sequence of their actions. Incident records are often retained for years for audit purposes. They are GDPR-governed personal data.

The EDPB Opinion 4/2023 on technical and organisational measures under GDPR Article 25 addressed the data minimisation obligations that apply to security monitoring specifically, noting that logging practices must be proportionate and that SIEM platforms should be configured to avoid excessive personal data collection. The Opinion does not suggest that SIEM data is exempt from GDPR — it assumes the opposite.

NIS2, DORA, and the Logging Requirement Tension

EU organisations in critical sectors face a specific compliance tension that Splunk Cloud does not resolve: NIS2 and DORA both mandate security logging, and both apply to organisations that are simultaneously subject to GDPR's jurisdictional obligations.

NIS2 Article 21 requires essential and important entities to implement "policies and procedures for the use of cryptography and encryption" and "appropriate policies and procedures regarding the use of... logging." The NIS2 Directive does not specify which log management platform to use, but it creates a baseline obligation for comprehensive audit trails covering security events, access patterns, and incident detection.

DORA Article 9 (for financial sector entities) requires ICT-related incident management with systematic log collection and retention. DORA Article 10 requires monitoring and logging of ICT-related anomalies. The EBA, ESMA, and EIOPA regulatory technical standards under DORA specify retention periods (typically three to seven years for critical logs) and access controls.

The compliance gap is this: NIS2 and DORA require you to collect security logs. GDPR requires you to protect personal data in those logs from unjustified third-country disclosure. Using Splunk Cloud satisfies the first obligation while creating structural risk for the second. An EU-based SIEM platform resolves both obligations simultaneously.

The German BSI's technical guidance on SIEM architecture (BSI C5 cloud criteria) explicitly addresses the jurisdiction question for security log data, recommending that security log retention should occur in EU-incorporated infrastructure where possible when the logs contain personal data subject to GDPR. The BSI guidance predates the Cisco acquisition; the Cisco acquisition makes its recommendations more relevant, not less.

Splunk Enterprise vs. Splunk Cloud: Does Self-Hosting Fix the Problem?

A common response from EU security teams is that Splunk Enterprise deployed on EU infrastructure (rather than Splunk Cloud) eliminates the CLOUD Act risk. This is partially correct, partially incorrect, and depends on how the self-hosted deployment is structured.

What self-hosted Splunk Enterprise removes: You control the infrastructure. If you run Splunk Enterprise on EU-incorporated infrastructure (Hetzner, OVH, IONOS, or an EU PaaS layer like sota.io), the data does not reside in Cisco's cloud infrastructure. A CLOUD Act demand directed at Cisco-Splunk would not give law enforcement direct access to your data.

What self-hosted Splunk Enterprise does not remove: Splunk Enterprise is licensed and maintained by Cisco-Splunk. Your Splunk instance communicates with Splunk licensing servers, sends telemetry data to Splunk infrastructure (unless explicitly disabled), and receives software updates from Splunk. These communication channels are under US jurisdiction. More significantly, Splunk Enterprise licenses typically require periodic check-ins with Splunk's US-operated licensing infrastructure. The degree of actual data exposure through these channels is typically low, but the dependency relationship is real.

The correct approach for EU sovereignty: Run a fully EU-native SIEM alternative rather than attempting to sanitise a US-licensed product's US infrastructure dependencies. The open-source and EU-native SIEM alternatives have no equivalent licensing relationships with US-incorporated entities.

EU-Native SIEM and Log Management Alternatives

The following alternatives are either EU-incorporated, fully open source under permissive licences, or both. All can be self-hosted on EU infrastructure without US vendor dependencies.

OpenSearch (Self-Hosted)

OpenSearch is the AWS-forked open source continuation of Elasticsearch and Kibana, maintained by the OpenSearch community under the Apache 2.0 licence. When self-hosted on EU infrastructure, OpenSearch has no US cloud vendor dependency. OpenSearch provides full-text log search, analytics dashboards (OpenSearch Dashboards), and alerting capabilities comparable to Splunk's core log management functions.

The EU-sovereignty advantage of self-hosted OpenSearch is complete: there is no US vendor relationship, no licensing check-ins, no telemetry to US servers, and no CLOUD Act surface area beyond your own EU-based infrastructure provider.

Gaps compared to Splunk: OpenSearch does not include a native UEBA (User and Entity Behaviour Analytics) equivalent to Splunk UBA. Correlation rules and detection logic require manual configuration rather than Splunk's marketplace of pre-built content. Security Operations Centres that rely heavily on Splunk ES correlation searches will find OpenSearch a capable but less turnkey replacement.

Wazuh

Wazuh is an open source security platform offering SIEM, XDR (Extended Detection and Response), and compliance management. Wazuh SRL is a Spanish company (EU-incorporated). Wazuh Cloud is operated from EU infrastructure.

Wazuh provides agent-based endpoint monitoring, log collection, file integrity monitoring, vulnerability detection, and compliance reporting out of the box — covering NIS2 Article 21 and DORA Article 10 requirements. Wazuh's built-in compliance modules include GDPR, HIPAA, PCI DSS, and CIS controls.

The NIS2/DORA alignment is a specific Wazuh advantage over general-purpose log management tools: Wazuh's compliance dashboards map security events to regulatory frameworks directly, reducing the configuration work for EU compliance reporting. As an EU-incorporated entity, Wazuh is not subject to CLOUD Act jurisdiction.

Grafana Loki

Grafana Loki is a horizontally scalable log aggregation system developed by Grafana Labs. Grafana Labs is a US company (incorporated in Delaware), which means self-hosted Loki deployments should use the fully open-source loki package rather than Grafana Cloud to avoid the US vendor dependency.

Self-hosted Grafana Loki on EU infrastructure provides cost-efficient log storage with label-based indexing (storing only metadata, not full-text log content, by default). Loki integrates natively with Grafana dashboards and Prometheus metrics, making it a natural fit for organisations already running the Grafana observability stack.

Limitation: Loki is a log aggregation system, not a full SIEM. It lacks native correlation rules, security-specific detection logic, and incident management workflows. For NIS2-grade security monitoring, Loki is typically paired with Grafana Alerting and custom PromQL/LogQL rules rather than used as a standalone Splunk replacement.

Graylog

Graylog is a log management platform with an open-source community edition and a commercial Graylog Operations tier. The company is US-incorporated (Graylog, Inc., Houston TX), which means the same CLOUD Act analysis applies to Graylog Cloud as to Splunk Cloud. However, the self-hosted open-source edition can be deployed on EU infrastructure with no US vendor relationship for operational data.

Graylog's self-hosted edition provides full-text log search, stream-based alerting, pipeline processing, and dashboards. Its architecture (Java-based with MongoDB and OpenSearch/Elasticsearch storage) is well-understood by EU infrastructure teams.

OSSIM and AlienVault Open Source

AT&T Cybersecurity (formerly AlienVault) open-sourced OSSIM (Open Source Security Information Management) years before the AT&T acquisition. OSSIM is now maintained as a community project under an open licence. As a fully open-source project with no US vendor dependency, self-hosted OSSIM on EU infrastructure has no CLOUD Act surface area for operational data.

OSSIM includes built-in asset discovery, vulnerability assessment, intrusion detection (Suricata integration), and SIEM correlation. It is less polished than modern commercial platforms but suitable for cost-conscious EU organisations needing NIS2-grade log management.

Migration Strategy: From Splunk to EU-Native SIEM

Migrating from Splunk is a multi-month project for any organisation with substantial Splunk deployment. The following phased approach reduces risk while moving progressively to EU-native infrastructure.

Phase 1 — Audit (Weeks 1-4). Enumerate all Splunk data sources, ingested log volumes, active correlation searches, and Splunk ES security content in use. Identify which log sources contain personal data under GDPR Article 4(1). This audit has dual value: it satisfies the GDPR Article 30 Records of Processing Activity requirement and produces the functional specification for your replacement platform.

Phase 2 — EU-Native Parallel Deployment (Months 2-3). Deploy the target EU-native SIEM (Wazuh or OpenSearch) on EU infrastructure in parallel with existing Splunk. Route a subset of log sources to the new platform. Begin validating detection coverage for your top-priority use cases. sota.io provides one-command deployment for both Wazuh and OpenSearch on EU-incorporated infrastructure, with managed persistent storage and no DevOps overhead.

Phase 3 — Detection Content Migration (Months 3-6). Convert Splunk SPL correlation searches to the equivalent detection logic in your target platform. The Elastic Common Schema and the Sigma format provide translation layers for many common detection rules. Sigma rules can be converted to OpenSearch, Wazuh, and other target platforms programmatically using the pySigma toolchain.

Phase 4 — Cutover and Splunk Decommission. Once detection coverage is validated in the EU-native platform, route all log sources to the new SIEM, stop Splunk ingestion, and decommission the Splunk deployment. Terminate Splunk licensing.

The critical decision point is Phase 2 infrastructure selection. Running Wazuh or OpenSearch on AWS, Azure, or GCP in EU regions reproduces the CLOUD Act problem with a different US vendor. EU-native infrastructure is required to achieve the intended outcome.

sota.io as EU PaaS Infrastructure for SIEM Deployment

Deploying self-hosted SIEM infrastructure raises operational questions that EU security teams often underestimate: storage capacity management for high-volume log ingestion, high availability for security-critical services, certificate rotation, backup, and upgrade management.

sota.io is an EU-native Platform-as-a-Service (PaaS) designed to remove this operational overhead. One-command deployment of Wazuh, OpenSearch, or Grafana Loki on EU-incorporated infrastructure means your SIEM runs on servers with no US parent company, no CLOUD Act exposure for your operational data, and no DevOps engineering requirement.

sota.io provides managed PostgreSQL (for alert history and correlation data), persistent storage volumes, automatic TLS certificate management, and horizontal scaling for log ingestion peaks. For organisations that need NIS2-compliant SIEM without a dedicated infrastructure engineering team, sota.io reduces the barrier to EU-native security operations substantially.

The CLOUD Act exposure analysis that applies to Splunk Cloud — Cisco as US parent, EU data centres as operational detail rather than legal protection — does not apply to sota.io. sota.io is EU-incorporated with no US parent company. Its infrastructure is operated entirely in the EU. There is no US government access vector to operational data hosted on sota.io infrastructure.

Compliance Checklist: Moving SIEM Off Splunk Cloud

The following 15-item checklist covers the key compliance actions for EU organisations evaluating a move from Splunk to EU-native SIEM infrastructure.

1. Identify personal data in log sources. Document which log sources ingested by Splunk contain personal data under GDPR Article 4(1). Authentication logs, network logs, and application security events almost always qualify.

2. Update Article 30 Records of Processing. Add or update the Splunk entry in your ROPA to reflect the CLOUD Act risk and your migration timeline.

3. Assess NIS2/DORA coverage gaps. Document which NIS2 Article 21 or DORA Article 9-10 requirements your current Splunk deployment satisfies. This becomes your minimum feature requirement for the replacement platform.

4. Select EU-native target platform. Wazuh (EU-incorporated, compliance-focused), OpenSearch self-hosted (EU-infrastructure dependency only), or Grafana Loki self-hosted (log-only, requires SIEM overlay). Match to your organisation's detection needs.

5. Select EU-native infrastructure. EU-incorporated PaaS (sota.io), EU-incorporated IaaS (Hetzner, OVH, IONOS), or EU-incorporated cloud (Scaleway, Exoscale, UpCloud). Do not deploy on AWS, Azure, or GCP EU regions — this reproduces the CLOUD Act problem.

6. Export Splunk correlation searches. Export all active Splunk ES correlation searches in SPL. Convert to Sigma format for platform-neutral storage. Sigma is the standard detection rule format for multi-platform SIEM deployment.

7. Inventory Splunk apps and add-ons in use. Some Splunk apps (Splunk UBA, Splunk ITSI) have no direct open-source equivalent. Plan manual replacement or accept reduced functionality for these use cases.

8. Configure parallel ingestion. Route a subset of log sources to both Splunk and the new EU-native platform for validation. Do not cut over until detection coverage is verified.

9. Validate detection coverage. Test your top-10 detection use cases on the new platform using synthetic or historical events. Confirm that alert fidelity and false positive rates are comparable to Splunk.

10. Update data processing agreements. If Splunk is listed as a processor in your DPA, update your processor agreements to reflect the migration timeline and eventual decommission.

11. Notify data subjects if required. If your Splunk processing activities were disclosed in your privacy notices, update those notices to reflect the change to EU-native infrastructure.

12. Archive Splunk historical data to EU storage. Before decommissioning, export historical log data needed for compliance retention to EU-native storage. Do not leave long-term log archives in Splunk Cloud.

13. Terminate Splunk licensing. After cutover, terminate Cisco-Splunk licensing agreements. Review whether any Splunk-related telemetry channels remain active and disable them.

14. Document the migration in your Article 32 technical measures. GDPR Article 32 requires documentation of appropriate technical measures. Migrating from CLOUD-Act-exposed to EU-native SIEM is a risk reduction action worth documenting.

15. Plan for ongoing detection content maintenance. EU-native SIEM platforms require active maintenance of detection rules. Budget for quarterly detection content review to keep pace with evolving threat actor techniques relevant to your sector.

Summary

Splunk became a Cisco business in September 2023. Cisco is a US corporation subject to the CLOUD Act. SIEM and log management data — authentication events, network traffic, application security logs, endpoint telemetry — is personal data under GDPR for virtually every EU organisation that deploys Splunk in production.

The CLOUD Act problem cannot be solved by selecting EU-region infrastructure within Splunk Cloud. Geographic location does not determine CLOUD Act jurisdiction. Corporate nationality does.

EU-native alternatives — Wazuh (EU-incorporated), self-hosted OpenSearch, self-hosted Grafana Loki, OSSIM — deployed on EU-native infrastructure (sota.io, Hetzner, OVH, Scaleway) address the structural problem that Splunk Cloud cannot. NIS2 Article 21 and DORA Article 9-10 security logging requirements can be met by EU-native platforms without the CLOUD Act exposure that Splunk Cloud introduces.

The sota.io EU Cyber Compliance Series covers GDPR, CLOUD Act, NIS2, DORA, and EU AI Act obligations for development teams. Deploy your EU-native stack at sota.io.