Google Meet EU Alternative 2026: Why Google Workspace CMEK Doesn't Solve the CLOUD Act Problem

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

Google Meet is embedded into the working day of hundreds of millions of people. As the video conferencing layer of Google Workspace — and as a standalone product available to any Google account holder — Meet handles video and audio calls, meeting recordings, AI-generated captions, and, increasingly, Gemini-powered meeting summaries and action items. Its adoption extends from individual knowledge workers to global enterprises and EU public sector bodies.

Alphabet Inc., Google's parent company, is incorporated in Delaware and listed on Nasdaq. Google LLC, the operating subsidiary that runs Google Workspace and Meet, is a US entity subject to the Clarifying Lawful Overseas Use of Data Act (CLOUD Act). Google Workspace offers two features that are sometimes cited as privacy safeguards: Customer-Managed Encryption Keys (CMEK) and Data Regions (the ability to store data in EU-only data centres). Both are meaningful operational controls. Neither removes Google's legal obligation to respond to lawful US government demands for data — including communications metadata, meeting recordings, and transcript content held in Google Meet.

For EU organisations operating under GDPR — especially those in financial services under DORA, healthcare, legal, the public sector, or sectors designated critical under NIS2 — the difference between data residency and legal jurisdiction is precisely the gap that these Workspace controls cannot close.

Google's Legal Architecture: Delaware Incorporation and CLOUD Act Exposure

Google LLC was founded in 1998 and restructured under Alphabet Inc. in 2015. Alphabet is incorporated in Delaware; Google LLC operates as a wholly-owned subsidiary. Both are US legal entities. The CLOUD Act, enacted in 2018, requires US companies to comply with lawful US government demands for data regardless of where that data is stored. The Clarifying Lawful Overseas Use of Data Act amended the Stored Communications Act specifically to resolve the extraterritorial application question: a US company must produce data it possesses, controls, or has the practical ability to access, even if the data is stored on servers outside the United States.

Google Workspace's Data Regions feature can restrict where data at rest is stored — European data can be stored exclusively in European data centres. This is a genuine operational commitment and differs meaningfully from configurations where data might freely transit US infrastructure. However, data residency does not change Google's legal status. US federal authorities — the FBI, and agencies operating under the Foreign Intelligence Surveillance Act — can serve legal process on Google LLC in California requiring production of any data Google can access. Google may resist such demands through legal challenge, and has a published transparency report documenting the requests it receives and its response rates. But the legal exposure exists regardless of where the data physically sits.

This is the compliance gap that CMEK and Data Regions do not address: not where the data is stored, but who controls the legal entity that holds it.

Customer-Managed Encryption Keys (CMEK): What It Does and Does Not Protect

Google Workspace CMEK — available to Enterprise Plus and Education Plus customers — allows organisations to manage their own encryption keys using Google Cloud Key Management Service (Cloud KMS) or an external key manager. When CMEK is enabled, Google cannot decrypt customer data without access to the customer's keys. In theory, this means that if Google receives a government demand for encrypted data, it cannot comply because it cannot read the content.

This is a significant technical control and is stronger than standard Workspace encryption. However, it has limitations that compliance officers should understand:

CMEK does not apply to all Workspace products uniformly. As of 2026, CMEK covers Gmail, Drive, Docs, Sheets, Slides, Meet recordings stored in Drive, and a defined set of other services. It does not cover all metadata, all administrative logs, or all services in the Workspace suite. Meeting recordings stored in Drive can be covered; the real-time audio and video stream during a meeting, the signalling data, and the presence and participation metadata are not subject to CMEK.

CMEK does not cover Google Meet in real time. During an active meeting, audio, video, and screen-share content are processed in real time on Google's infrastructure. Real-time streams are not encrypted with customer-managed keys — they cannot be, because Google's servers must process them to route, mix, and transmit them to other participants. CMEK protects stored artefacts, not live communications.

CMEK does not protect metadata. Who joined a meeting, when, from which IP address, for how long, who shared their screen — this operational and usage metadata is generated and retained by Google regardless of CMEK configuration. In GDPR terms, this metadata may be as sensitive as content: it reveals working patterns, relationships, and organisational dynamics.

Key escrow is a risk surface. Cloud KMS key material, even when customer-managed, is ultimately hosted in Google Cloud infrastructure. An external key manager reduces but does not eliminate this dependency. Under a sufficiently broad legal demand, a US court could compel Google to produce metadata about key access events, or could seek legal process directed at the key management infrastructure itself.

CMEK does not address government access to Google's administrative infrastructure. National Security Letters, FISA orders, and other legal instruments can compel disclosure of administrative data — account information, usage patterns, subscriber information — that exists entirely outside the scope of CMEK encryption.

CMEK is a valuable control for reducing insider threat risk and limiting Google's ability to comply with routine law enforcement demands for content. It is not a solution to the structural CLOUD Act exposure that arises from Alphabet's US incorporation.

What Google Meet Actually Processes

The data Google Meet collects and retains is broader than the video call itself:

Real-time audio and video: The primary product — unencrypted (from Google's perspective) during transit through Google's infrastructure for routing purposes.

Meeting recordings: When recording is enabled, Meet stores recordings in the host's Google Drive. These can be CMEK-protected if the Workspace deployment uses CMEK, but require the host to enable recording and the organisation to have configured Drive CMEK.

AI-generated captions and transcripts: Meet generates live captions and, for Workspace Enterprise users, can produce meeting transcripts. With Google Gemini integration, meetings can generate AI summaries, action items, and follow-up notes. These AI-generated artefacts are processed through Google's Gemini infrastructure — US-routed, separate from Data Regions configuration.

Meeting metadata: Participant list, join/leave timestamps, duration, IP addresses, device types, network quality metrics. This data is retained for operational and billing purposes and is not covered by CMEK.

Calendar and scheduling data: Google Meet is deeply integrated with Google Calendar. Meeting invitations, attendee responses, and scheduling patterns are all accessible through Workspace administrative data.

Chat messages: In-meeting chat (messages sent during a Google Meet session) can be retained in Google Chat logs depending on configuration. This content is subject to Vault retention policies.

Third-party integrations and add-ons: Meet integrations (note-taking tools, transcription services, CRM connectors) may route data to additional subprocessors. Google's subprocessor list for Workspace runs to dozens of companies, many of which are US entities.

Google Workspace Data Regions: What It Covers

Google Workspace Data Regions allows enterprise administrators to configure their Workspace tenant so that covered data at rest is stored in EU data centres. This applies to Gmail, Drive, Calendar, Meet recordings, and a defined set of other primary data types.

Data Regions does not cover:

Temporary processing data: Data processed in transit and not stored — including real-time Meet streams — is not covered by regional storage commitments.

Google's global infrastructure for reliability and security: Certain functions — spam filtering, abuse detection, service reliability — may require Google to process data outside the designated region. Google's documentation reserves the right to process data globally for these operational purposes.

Gemini and AI features: The Gemini AI Assistant in Workspace, including Meet's AI summarisation features, processes data through AI infrastructure that is not subject to Data Regions configuration. Google's documentation notes that AI features have separate data handling commitments.

Support and professional services data: Data exchanged with Google support and professional services teams may be processed in the United States.

Metadata and telemetry: Administrative logs, usage analytics, and service telemetry are not covered by Data Regions storage restrictions.

The combination of CMEK plus Data Regions addresses data residency and some content access risks. It does not change the fundamental legal position: Alphabet Inc. is a US entity, and US legal process served on Google LLC in California can compel production of data Google has the practical ability to access.

GDPR Obligations for Google Meet Users in the EU

Using Google Meet under Google Workspace does not make EU organisations automatically non-compliant, but it creates obligations that require active management:

Article 28 — Data Processing Agreement: EU organisations are data controllers; Google is the processor. Google Workspace's Data Processing Amendment (DPA) — incorporated into the Google Workspace Customer Agreement — is Google's Article 28 compliance mechanism. Organisations should verify their DPA version and ensure it covers their specific use cases, including Gemini AI features if enabled.

Article 46 — Transfer Mechanisms: Where Google processes EU personal data outside the EU (AI features, support data, operational telemetry), an appropriate transfer mechanism must exist. Google relies on Standard Contractual Clauses for cross-border transfers. Post-Schrems II, SCCs for US transfers require a Transfer Impact Assessment. A TIA for Google Workspace must address the CLOUD Act exposure and assess whether the practical risk of US government access undermines the protection SCCs are intended to provide. For high-risk categories — public sector data, regulated financial data, healthcare communications — this TIA analysis is particularly demanding.

Article 35 — Data Protection Impact Assessment: Large-scale processing, processing of special category data, and systematic monitoring activities using Meet may require a DPIA. The introduction of Gemini AI features in Meet — which processes speech and video to generate summaries and action items — materially expands the data processing footprint and likely triggers DPIA obligations where they did not previously exist for a standard video conferencing deployment.

Article 5(1)(e) — Storage Limitation: Meet recordings and transcripts in Drive are retained indefinitely by default unless Google Vault retention policies are explicitly configured. Storage limitation requires active policy configuration, not just reliance on default Workspace settings.

Article 25 — Data Protection by Design: Enabling AI features by default in Meet — auto-captions, Gemini summaries — without active consent mechanisms may conflict with data-by-design principles for EU deployments handling personal data beyond purely internal business use.

NIS2 and DORA Considerations

For EU organisations subject to NIS2 or DORA, the CLOUD Act exposure of a US-incorporated video conferencing provider raises sector-specific concerns:

NIS2 (Directive 2022/2555): Essential and important entities under NIS2 must manage supply chain risks. Using Google Meet means Alphabet/Google is a critical ICT service provider. NIS2 entities must assess and document risks from third-party ICT dependencies, including the risk that US legal process could compel disclosure of sensitive communications or — in a more disruptive scenario — result in service suspension affecting business continuity. The NIS2 incident reporting framework requires notification of significant incidents affecting network and information systems; a CLOUD Act compelled access order that results in data disclosure could constitute a reportable event.

DORA (Regulation 2022/2554): Financial entities under DORA — banks, investment firms, insurance companies, payment institutions — must assess whether Google Workspace and Google Meet qualify as critical ICT third-party providers. Where an entity's reliance on Meet for internal and client-facing communications is operationally significant, DORA Articles 28-44 impose contractual requirements, including audit rights, termination provisions, and incident notification obligations. The standard Google Workspace contract does not satisfy all DORA CTPP contractual requirements; financial entities would need to negotiate additional terms or, where Google declines, document this as a concentration risk and consider alternatives.

EU-Native Alternatives to Google Meet

Several European video conferencing platforms eliminate the CLOUD Act exposure entirely by operating without any US-incorporated parent company:

Nextcloud Talk — Open source, self-hosted or managed hosting available from European providers. Nextcloud GmbH is incorporated in Stuttgart, Germany. Offers video conferencing, screen sharing, and chat. Self-hosted deployments give organisations complete control over data. Managed hosting available from Hetzner, Contabo, and other EU-based providers. Integrates with Nextcloud Files, Calendar, and collaboration suite for a Google Workspace-equivalent stack entirely under EU legal architecture.

OpenTalk — Developed by Heinlein Hosting GmbH (Berlin, Germany) and open-sourced under the EUPL. Designed explicitly for public sector and regulated industries with GDPR-compliance as a design principle. Supports video conferencing, screen sharing, and meeting management. Available as hosted service or self-deployment. Used by several German government bodies and regulated organisations.

Infomaniak kMeet — Video conferencing service from Infomaniak Network AG, incorporated in Geneva, Switzerland. Switzerland is not EU-member but applies equivalent data protection law under the Swiss nFADP, and Infomaniak's infrastructure is entirely Swiss-domiciled with no US parent. No CLOUD Act exposure. Free tier available; paid plans for enterprise use. Suitable for organisations that accept Swiss jurisdiction as equivalent to EU.

Jitsi Meet — Open source video conferencing platform (Apache 2.0 licence), developed by 8x8 (a US company), but designed to be self-hosted. Self-hosted Jitsi deployments on EU-domiciled infrastructure by EU entities carry no CLOUD Act exposure — the hosting entity is the legal controller. Jitsi's hosted service (meet.jit.si) is operated by 8x8, a US company, and would have the same CLOUD Act exposure as Google Meet. For EU sovereignty, the relevant deployment model is self-hosted on EU infrastructure.

Whereby — Video conferencing service operated by Whereby AS, incorporated in Oslo, Norway. Norway is not EU-member but is EEA, applying GDPR directly. No US parent, no CLOUD Act exposure. GDPR compliance built into the product design. Offers browser-based meetings without required downloads. Plans from free through enterprise.

STACKFIELD — German collaboration platform (Munich-based Stackfield GmbH) offering video conferencing, chat, tasks, and file management. End-to-end encrypted by design. BSI-evaluated security. Targeted at regulated industries and German government clients. Explicitly designed to comply with GDPR, BDSG (German Federal Data Protection Act), and NIS2. Higher cost than commodity alternatives; appropriate for high-sensitivity environments.

Wire — Swiss-incorporated Wire Swiss GmbH offers end-to-end encrypted communications including video conferencing, messaging, and file sharing. Acquired by Symphony in 2019 (US entity), which creates a corporate ownership consideration. Wire's legal entity remains Swiss; enterprise contracts should specify Swiss jurisdiction. Strong encryption guarantees and open source client code. Used by government and regulated enterprise clients across Europe.

Decision Framework: When Google Meet Poses Unacceptable Risk

Not every EU organisation using Google Meet faces equal compliance exposure. Risk depends on data categories processed, regulatory framework, and contractual relationships:

Conclusion

Google Meet is a capable, widely-used video conferencing platform. For many EU commercial organisations, the combination of CMEK, Data Regions, and a well-drafted TIA may represent an acceptable risk posture — particularly where AI features are disabled and meeting content is not classified as high-risk personal data.

For EU public sector bodies, NIS2 essential entities, DORA-subject financial firms, and any organisation where the content of meetings is sensitive — M&A discussions, patient consultations, legal advice, personnel decisions — the CLOUD Act exposure of a Delaware-incorporated platform is a compliance risk that CMEK and Data Regions cannot eliminate. The exposure exists at the level of the legal entity, not the data centre.

EU-native alternatives — Nextcloud Talk, OpenTalk, kMeet, self-hosted Jitsi, Whereby, STACKFIELD — provide genuine legal sovereignty by removing US corporate parentage from the processing chain. The trade-off is operational: integration depth, feature completeness, and support infrastructure differ from the Google Workspace ecosystem. For organisations where the compliance requirement is clear, that trade-off is well-defined and increasingly manageable as EU alternatives mature.

The question is not whether to trust Google's security engineering — it is substantially strong — but whether an EU organisation is comfortable that a US court in California could compel production of data from that platform, and whether that risk has been documented, assessed, and accepted by the organisation's data protection officer and management.

Running sota.io infrastructure? As an EU-native managed PaaS on Hetzner Germany, sota.io eliminates US-parent CLOUD Act exposure at the infrastructure layer — your applications run under EU legal jurisdiction with no Alphabet, no AWS, no Azure. Start building →